I was a little surprised how often I ran into this issue when using libraries that started defining structures as generic containers.

For a concrete example, the fact you cannot define custom methods for external types in Go (a pre-1.0 design decision) means that you cannot write proper compile-time generic code to deal with some generic wrapping type (dumb example -- getting a sum of the perimeters of a generic set of shapes in an externally-defined collection type) -- you are forced to work around it with runtime type-switching. There are all sorts of arguments you can make about simplicity but this is an objective shortcoming of Go that is directly caused by generics being added to Go long post 1.0.

My take on this is that despite selfishly wanting more from Go for many years myself, adding more stuff to Go at this late stage is just slowly chipping away at Go's uniqueness with features that make a large number of people using them unhappy. (For example, while they make some APIs nicer, iterators turn a basic logic bug that is impossible with for loops -- forgetting to stop iterating when the loop has a "break" -- into a runtime panic. And they really suck to compose.)

[1]: https://youtu.be/esQyYGezS7c?t=226

To be clear, I think this whole story stinks but the issue here is not that OS installations have unique identifiers (machines have lots of unique identifiers -- hardware MAC addresses, peripheral composition and device IDs, screen resolution) -- it's that Windows has an auto-enabled spyware^Wtelemetry system that shares enough data for them to be able to provide that kind of data to law enforcement. This would be a privacy nightmare even in the absence of a unique OS installation identifier. Heck, they could even take regular screenshots of your screen but that would be too obvious[1].

[1]: https://en.wikipedia.org/wiki/Windows_Recall

If you want to completely remove the global information in /proc you can do so by mounting it with subset=pid (and extra points for hidepid=4). This was added to improve container runtime security but unfortunately a lot of programs still depend on reading global procfs files so we can't enable it by default.

As for why all this information exists in /proc, procfs has historically been a bit of a dumping ground. There is an argument for "everything is a file" and so on, but having had to deal with all sorts of insane bugs related to procfs I'm less sympathetic to that argument than I used to be.

> There is also a catch that the program can create a new unprivileged user namespace and mount /proc there thus bypassing my daemon completely. Anyone can create a user namespace nowadays.

There actually are some restrictions, if the process doesn't have access to an unmasked procfs mounting /proc will fail, though a recent patch[1] finally made it so that subset=pid works in this case. (And most sandboxes disallow unprivileged CLONE_NEWUSER with seccomp.)

[1]: https://lore.kernel.org/linux-fsdevel/cover.1626432185.git.l...

Whether everyone does that correctly, that's a different question. On the other hand, while developers should be more careful about how they use identifiers like this, if an application on your machine wants to track you they don't need /etc/machine-id.

If you want actual anonymity you need to use something like the Tor Browser (which does lots of tricks to try to block fingerprinting as well as using a unique Tor circuit for every website you access).

Ethically it's all completely bunk, but more people should be aware how insane modern copyright laws are so that we can reform them. And this is not new, folks like the FSF and EFF protested the signing of the 1996 WIPO Treaty too.

[1]: https://www.law.cornell.edu/uscode/text/17/1201

Fuzzers are another kind of stochastic generator but nobody would claim they don't do useful work in a way that is hard to replicate through deterministic methods. (I still find the code these models produce kind of awful, but advancements in harnesses do mean that they can finally produce code that works most of the time.)

Still, requesting the information from systemd-userdb would be a better way of doing this if it's really necessary.

EDIT: Yeah, some older comments confirm that was their reasoning. https://github.com/tailscale/tailscale/commit/1fc1077052dfa7...

If so, this is kind of an understandably ugly problem, though there is still a better option than shelling out -- systemd-userdb.

Tailscale can also just apply to be their own CNA and issue CVEs for their products themselves, eliminating any such issues entirely.

As others have said, a lot of the useful emails I get are still ones where the sender probably wouldn't have paid to send them. IM2000's fairly old-school-yet-elegant approach would probably lead to a better outcome too.

[1]: http://cr.yp.to/im2000.html

Lead acid batteries had a similar trajectory and modern lead acid batteries are effectively 100% recycled.

(I've been one of the maintainers of runc -- the most widely use used container runtime on Linux -- for more than a decade, so I'm at least somewhat well-informed on the topic.)

The duct tape criticisms are fair when talking about other vulnerabilities (such as when container runtimes have misconfiguration or other inatomicity bugs) but not really here in the context of a kernel arbitrary code execution gadget. It also seems quite unlikely that the illumos kernel doesn't contain any of these kinds of bugs.

There are many issues with the formulation of containers on Linux (though I think people overstate it whenever bugs like this happen) but ultimately this bug was a UAF that gave you arbitrary code execution in the kernel. Zone IDs are also just numbers in kernel memory... right?