This is my attempt to tick all boxes. Small codebase, two languages (Go and SQL), easy deployment and no frameworks/ORMs, ActivityPub support and a lightweight text-based interface.
For me, the best small side projects involve some kind of porting (between protocols, OSs or CPUs), contribution of a fix for a visible but mysterious bug, or revival of codebases in bad shape, especially when they're unfamiliar and written by others. You can learn a lot from a software engineering culture that's different from yours or small, feasible projects that allow you to understand the bits and bytes of something unfamiliar in a fun and useful way. These projects are great to develop flexibility and general problem solving intuition. And getting familiar with the 20% of an idea, a protocol, a programming language, etc' that's used 80% of the time in real-world use cases, is often enough.
> You can do DNS over HTTPS through Firefox (sadly not on an OS level in Windows for example, but that's fine -- I'm sure OS level support works better on Linux
The payload executable is extracted to a temporary file. When running as root, this is done by mounting a tmpfs file system and lazily unmounting it before the extraction.
When not running as root, it doesn't use a tmpfs. Also, papaw replaces /proc/self/exe with an empty file. And it has some basic anti-debugging, like locking of the payload to RAM so it cannot be recovered by reading it from a swap partition.
Because the OS (getaddrinfo(), gethostbyname(), etc') doesn't implement DoH; it implements a /etc/hosts parser and a DNS (over UDP) client.
I wrote a glibc plugin that implements a caching DoH client for glibc, which can replace the DNS client or fall back to it - https://github.com/dimkr/nss-tls.
The criticism (which you seemed to
miss) is that everyone is rushing to implement this at the application-level(s), instead of contributing to get it implemented, once, at the OS level instead and have a fix in place for everyone.
> Not to mention that DNS over HTTP is one of the class of features where you might want to override sysadmin policy as a user.
I don’t buy that argument at all.
Why should we special case policies of one internet-protocol over all the others?
Also: implementing/marketing DoH as a way to bypass enterprise control and policies is a surefure way to find it permanently blocked at firewall level in said enterprises.
Ie your attempt at subverting control won’t gain you anything but deserved distrust.
Hi Dima - I'm assuming you're aware of dnscrypt-proxy and wrote nss-tls because you wanted a lighter weight implementation of a subset of dnscrypt-proxy's features on a specific platform (linux/glibc, for example this won't work on linux/musl afaik)? I use dnscrypt-proxy happily but was interested in nss-tls, yet couldn't find a rationale/comparison in the readme.
Or, you can use https://github.com/dimkr/nss-tls - everything that uses gethostbyname(), addrinfo(), etc', including Firefox with network.trr.mode set to DNS, will use DoH
I use this and it works great. Especially in combination with https://github.com/jedisct1/bitbar-dnscrypt-proxy-switcher (and its dependency Bitbar), which gives you a little icon in the taskbar to monitor and manage the dnscrypt settings. (mac os x)
That seems to be Linux-only. There should ideally be GUI applications for every platform that lay people can download, install and run with sane defaults. Cloudflare did that for mobile with the 1.1.1.1 app.
Raising the security bar of routers is indeed a priority of many ISPs, organizations and consumers. But IMHO, securing the router isn't enough, because once you close the huge security and privacy hole created by vulnerable and outdated home routers, IoT devices like IP cameras will take the router's place as the weakest link in terms of a home network's security, so the problem of malware targeting embedded devices with no security software is still there. (Also, if any guest who connects to a WiFi network can guess admin:admin or admin:12345678 and infect IoT devices, NAT is not enough to provide a reasonable level of security in many home networks. In addition, having open-source firmware or reputable open-source components is not enough to assert that a certain device is secure by design, because most home routers run outdated and vulnerable versions of Linux/uClibc/whatever, often with network stack patches and proprietary drivers from the SoC manufacturer's BSP that make it impossible to upgrade to recent, stable versions of everything; this also applies to the router manufacturers that fork OpenWRT and don't pull changes. Moreover, completely separate from the question of how to develop security updates, the problem of testing and deploying them in time on customer premises, without user intervention, still remains and detracts from the ISP's motivation to provide security: it's very expensive). A copy-paste-based software development lifecycle, unsafe C code, the cost of built-in security and the risks & costs of deploying updates in scale are here to stay for the foreseeable future. A more radical solution is needed to protect today's devices against today's and future threats: that's why in https://www.securingsam.com, we're putting a security-as-a-service umbrella on the existing, consumer-grade router which hardens and protects the router and all devices connected to it using DPI, traffic anomaly detection, auto-updated (independently of the router firmware) vulnerability mitigation patches and much much more.
Nope. The first token in a statement is treated the same way as those that come after it. This way, you can do stuff like this (i.e. imagine a dictionary that maps HTTP methods to hander functions):
I think it might be better to special case the first word in the command, just like sh and tcl do. The list.index case you mentioned is much rarer than just calling a command directly.
https://github.com/dimkr/tootik