Notices by Matthew Garrett (mjg59@nondeterministic.computer), page 5

Twitter just doing a "redirect links in tweets that go to x.com to twitter.com instead but accidentally do so for all domains that end x.com like eg spacex.com going to spacetwitter.com" is not absolutely the funniest thing I could imagine but it's high up there

Absolutely lovely day with friends that included reminiscing with a former coworker about how Fedora almost shipped a Tetris clone in the installer called "Shit Keeps Falling" as a reference to the QA Confidential strip from Leisure Town

If you click on the little "Verified" tag on github it tells you the key ID used for the signing - is there any way to get that from the API?

@GossiTheDog I've been the security lead for a security-critical Linux deployment in a giant corporation and I literally cannot envisage a way we could have caught this without rearchitecting the entire OS, up until the point where it was actively exploited against us.

I love that Debian discovered both the failure of crowdsourcing a web of trust via keysigning parties (someone used ID in their name but issued by a fake country) and the failure of assuming upstream is trustworthy (an upstream buried code that wouldn't trigger on the Debian maintainer's system but would everywhere else) back in the 2000s but the free software ecosystem is still trying to come up with social solutions to a technical problem

English police assumed false identities and infiltrated activist groups and even had children with members of those groups with the backing of the state, what kind of "real name" policy would have prevented that? There's a degree to which reputation associated with an online identity is important but there's no evidence that trying to tie that to any kind of government issued ID improves anything - and there's no inherent reason to believe that an established identity is trustworthy

There really is no simple answer to the xz case. We can reduce dependencies, we can strengthen sandboxing, we can make it harder for dependencies to inject code. But fundamentally we still depend on the idea that our dependencies are trustworthy and the only real way to guarantee that is to have strict examination of every single line of code

nation state actor maintenance of an open source project may introduce a lot of backdoors, but it also helps a lot of PRs get merged, so, it;s impossible to say if its bad or not,

@DrHyde "My backdoor relies on this behaviour, please revert this change to maintain ABI"

Watching people much better at this than me RE the xz backdoor and it's very much the reverse engineering scene from Hackers (spoiler it seems to take a signed payload smuggled in the form of the client's SSH pubkey and then pass that to system()) https://youtu.be/bcAACOrgVKE

It's kind of amazing that systemd had already upstream changed the behaviour of libsystemd such that liblzma wouldn't have been loaded, raising the hilarious possible alternative reality where that release got cut earlier and hit distros before the backdoored liblzma did and all of that work would have been for nothing

Being less flippant about this - the xz backdoor relied on a line that was present in the tarball release, but not in the git repo. Do we have any infrastructure for validating this kind of thing? (It's expected that the tarball would contain things that aren't in git - for example, the configure script doesn't exist in git, but is expected to be in the release. The problem is that extra code was injected into the configure script after it was generated)

Just finished writing my lengthy paper on how "Many eyes make all bugs shallow", time to check what's happening on the internet today

@trdebunked That is a take I hadn't really considered, thank you!

@trdebunked I think the obvious response there is just how much free software ended up depending on GNU behaviour (be that libc, gcc, or even somewhat more arguably Linux)

@trdebunked I think it's interesting tying this into the "systemd isn't really free software because it's so complicated" kind of argument. Free software is never going to be equivalently free for everyone - people who can code enjoy more freedom than people who can't (unless they have enough money to pay someone to do it). Where do boundaries get drawn?

@trdebunked (I don't think LLM models are inherently non-free - if someone supplied all the tools and the training data someone could rebuild that, the problem is that it would be implausibly expensive for most people to do so, but again that's not something that's been factored into the free software definition)

@trdebunked I completely agree there, you're pushing a free idea into an opaque blob in order to receive free code. But free software as defined in the 80s was fine with opaque compilers, and I don't think anything ever happened to expressly redefine that

@RoganDawes @ryanc There's not really a problem in the banner exchange - the client won't initiate key exchange until it's consumed the banner, so no matter who speaks first it could send a different packet type if the server had sent a signal in the banner

Is there a reason ssh doesn't support including server name in the handshake before key exchange so it can be proxied to the actual host via a single IP? I know you can make this work with proxycommand, it just seems like a weird absence in the protocol