Ted Unangst

Doesn't help that all of the major decentralized protocols have been very effectively undermined and pushed aside.

GTalk first de-federated (weakening XMPP as a whole), then killed XMPP support completely. Reader effectively killed RSS for casual users. Email has been swallowed whole by the oligopoly of GMail+Yahoo+Outlook+iCloud+etc; spam is a real problem, so if you're self-hosting your email, you kinda expect to be blocked by default by the large networks.

Existing, corporate-backed efforts are "open-washing" their services.

Signal is supposed to be using an open protocol, but IIRC won't even let you join their network if you use an alt client.

Following Twitter's demise, Bluesky popped up, and promised federation. I didn't check in a while - did it happen yet?

Actually open networks? Mastodon took off like crazy, but everyone tried to register on the "main", biggest instance - we got bamboozled so hard, we can't even comprehend what "decentralized" is actually supposed to mean.

ActivityPub as a protocol? Ted Unangst decided to build his own client from the spec, and was constantly running into Mastodonisms. <https://flak.tedunangst.com/search?q=activitypub>

Matrix? It has effectively one client (Element) that isn't a security disaster. <https://soatok.blog/2024/08/14/security-issues-in-matrixs-olm-library/>

Anything left, worth of anyone's attention?

OpenBSD does seem empty by comparison, but it's on purpose.

ZFS is large and complicated. http://www.tedunangst.com/flak/post/ZFS-on-OpenBSD

DTrace would be nice to have, but I believe there are CDDL license concerns.

Jails are a way of isolating services so that they cannot do (much) damage to the system in the event they are compromised. The closest alternative in OpenBSD is probably pledge(2), which allows a program to voluntarily renounce the ability to invoke a set of syscalls. There is also chroot if all you need is filesystem virtualization.

MAC can be complicated to implement. This comment explained things very well: https://news.ycombinator.com/item?id=8893749

> OpenBSD doesn't support a MAC framework because they believe the best approach to security is correctness, rather than trying to achieve security by adding features which results in more complexity, making it more difficult to ensure correctness. A common mistake people make is thinking that OpenBSD's primary goal is security; their primary goal is correctness. This just happens to result in better security more often than not.

Linux compat is a similar story. OpenBSD dropped it in the 6.0 release due to complexity and security concerns.

I don't know a whole lot about CloudABI.

I follow regularly these people, these are mostly slow-going blogs or websites:

1. Fabrice Bellard: https://bellard.org/ This is not really a blog, but a traditional website with links to the work of its author (who is probably one of the top programmers ever). It updates rarely, but when it does, it is to expose yet another monumental piece of computing work that will blow your universe.

2. Linus Akesson: https://www.linusakesson.net/ He's always onto some funny crazy things: obfuscated programming, underhanded programming, c64 emulation, chiptunes...

3. Uriel l'Étranger: http://cat-v.org/ The only self-described "philosopher of software" that I have ever seen. His website is of course not updated anymore, but you can re-read it many times and always learn something new.

4. Ted Unangst: https://flak.tedunangst.com/ Nice to follow some cool news about openbsd development

5. Andy Chu: http://www.oilshell.org/blog/ Who has embarked in an amazing quest to turn the unix shell into a cleaner tool

6. Jens Gustedt: https://gustedt.wordpress.com/ If you really want to be up to date about the evolution of the C language

Sure, but OpenBSD has a very specific project goal and use cases (which is absolutely as it should be!) and their stance thus makes sense in context. But it doesn't mean their stance is universally applicable either, anymore then best practices for IaaS all apply everywhere. For an alternate feature example: some OpenBSD committers for years have reasonably rejected OpenZFS [1] requests because it was considered to be just plain too big, and in turn presented more threat surface and higher system resource consumption (big issue for embedded/firewall appliance applications) then was desirable for them. All of which is true and makes total sense there. But not for a lot of big servers and end user systems where I think automatic full data consistency/checks/regeneration, easy full replication, trivial cheap atomic snapshots, portability between many OS, and so on, address much more important threats then the extra load or any unknown potential vulns. No need for a monoculture ecosystem here rather then using the right specific tool for the job right?

-----

1: https://www.tedunangst.com/flak/post/ZFS-on-OpenBSD

The Qualsys analysis states that keys provided by an agent are not disclosed, and that encrypted keys are disclosed in their encrypted form.

https://www.qualys.com/2016/01/14/cve-2016-0777-cve-2016-0778/openssh-cve-2016-0777-cve-2016-0778.txt

Quoting from above: Finally, for these three reasons, passphrase-encrypted SSH keys are leaked in their encrypted form, but an attacker may attempt to crack the passphrase offline. On the other hand, SSH keys that are available only through an authentication agent are never leaked, in any form.

So if you use an agent, and follow the good advice to encrypt your private keys you should be safe(er).

See for older client versions:

http://martin.kleppmann.com/2013/05/24/improving-security-of-ssh-private-keys.html

or better for newer clients:

http://www.tedunangst.com/flak/post/new-openssh-key-format-and-bcrypt-pbkdf

I am hoping that Rust will make in-roads into the BSD world, since it interoperates well with C and is much safer by default while not imposing overhead like a managed language+runtime would. It also has very liberal licensing (GCC being GPL has always been a tough pill for some to swallow, FreeBSD at least has already switched to Clang) https://github.com/rust-lang/rust#license

The OpenBSD folks have done great work through auditing and writing safer code in C, and I agree that using a language that ameliorated at least some of the common mistakes programmers make would be a net positive.

Related - this blog from @tedunangst is worth reading, regarding the limit to which even a language like Rust can protect against specific exploits (the OpenSSL "Heartbleed" vulnerability, in this case) http://www.tedunangst.com/flak/post/heartbleed-in-rust