IndieWeb post types

Enhance and enrich your OpenAPI descriptions without creating conflicts in the source code using filters and overlays.

Just did a task that was open since Feb. 20th that will unblock six teammates doing full-time work starting this week. It took 5 minutes 35 seconds to finish. I will, again, learn nothing from this.

Attached: 1 image When you realise that people have been *planning* shitty jokes like this just for one day, for the likes

I really can only shitpost about the #xv debacle because the whole thing just makes me tired and sad. Anyone paying even a tiny bit of attention to the conversation about open source sustainability could have told you this was inevitable. And now we're watching people blame a volunteer trying to step back, and rehashing all the same old tired arguments we've been having literally for decades. It's just so tired and predicable and boring and sad.

so do alice and bob ever fuck or like what

My favorite Ren Faire story: I knew a guy who kept a Starfleet insignia pinned to the inside of his garb. A few times per season, some folks would come to the Faire cosplaying as a Star Trek landing party, investigating a “primitive” world. He would take them aside, show his insignia, and identify himself as a Starfleet officer on a cultural research mission. He’d call them out for breaking the Prime Directive and ruining his research. Then he’d demand to know what ship they’re from, and threaten to get them court martialed if they didn’t change into something less conspicuous.

Anyone who thinks commit signing is the answer to malicious actors, at a time when the web of trust has been killed by a lil green verified box, is foolish. Like sure they verify that someone who can log into a particular GitHub account is the author of a commit, but that… don’t mean shit when the author is malicious 🙃

Originally a thread on Twitter about the xz/liblzma vulnerability, when I finished typing it, I realized I had a real world slice of Open Source interaction that deserved more attention.

You can absolutely push your development cycle to the limit, the fastest programmer with a completely comprehensive suite of tests, sure. Go for it. You will still be fundamentally hamstrung by not-fit-for-purpose tooling (JIRA), overly bureaucratic release processes, and slow deployment mechanisms. Yes, be the most efficient developer you can, work in small increments and iterate effectively, but it's just as important to remove systematic issues that hinder you and your team.

being forced to mute the word “backdoor” is queerphobic

hey does anybody out there have any thoughts about the xz compromise or perhaps have you thought of a way to relate it to some axe you have been grinding for 20 years

The clocks went forward an hour in the UK today, which raises an important question: when they go back in October will there be a compensatory Trans Hour Of Visibility?

If you want many eyes on your open source project, you need to get rid of assholes. Bad community management is a security risk. Assholes bully sole maintainers. Assholes gatekeep and keep maintainer numbers low. Assholes waste time on the mailing list with petty bullshit. If you fundraise, assholes are bullying your grant writers and community managers. Some of the best security contributors don't write a single line of code. They yeet assholes.

Being a woman fixed all the problems in my brain (except the ones caused by the autism and being a huge bitch)

I've been informed by the 11yo that his mother and I are the target of an antitrust lawsuit joined by at least 15 other children, that we have abused our power to maintain an illegal monopoly in the relevant market of "parenting decisions" specifically for preventing choice and putting in place limits regarding food, videogames, and other media, and have conspired to make it effectively impossible for them to switch to alternative parenting decision providers

My current take on the #xz situation, not having read the actual source backdoor commits yet (thanks a lot #Github for hiding the evidence at this point...) besides reading what others have written about it (cf. https://boehs.org/node/everything-i-know-about-the-xz-backdoor for a good timeline): 1. This is going to be an excellent teaching example for advanced supply chain attacks that I will definitely be using in the future - after much more in-depth analysis. 2. It seems to have been a long game, executed with an impressive sequence of steps and preparation, including e.g. disabling OSSFuzz checks for the particular code path and pressuring the original maintainer into accepting the (malicious) contributions. 3. The potential impact could have been massive, and we got incredibly lucky that it was caught and reported (https://www.openwall.com/lists/oss-security/2024/03/29/4) early. Don't count on such luck in the future. 4. Given the luck involved in this case, we need to assume a number of other, currently unknown supply chain backdoors that were successfully deployed with comparable sophistication and are probably active in the field. 5. Safe(r) languages like #rustlang for such central library dependencies would maybe (really big maybe) have made it a bit harder to push a backdoor like this because - if and only if the safety features are used idiomatically in an open source project - reasonably looking code is (a bit?) more limited in the sneaky behavior it could include. We should still very much use those languages over C/C++ for infrastructure code because the much larger class of unintentional bugs is significantly mitigated, but I believe (without data to back it up) that even such "bugdoor" type changes will be harder to execute. However, given the sophistication in this case, it may not have helped at all. The attacker(s) have shown to be clever enough. 6. Sandboxing library code may have helped - as the attacker(s) explicitly disabled e.g. landlock, that might already have had some impact. We should create better tooling to make it much easier to link to infrastructure libraries in a sandboxed way (although that will have performance implications in many cases). 7. Automatic reproducible builds verification would have mitigated this particular vector of backdoor distribution, and the Debian team seems to be using the reproducibility advances of the last decade to verify/rebuild the build servers. We should build library and infrastructure code in a fully reproducible manner *and* automatically verify it, e.g. with added transparency logs for both source and binary artefacts. In general, it does however not prevent this kind of supply chain attack that directly targets source code at the "leaf" projects in Git commits. 8. Verifying the real-life identity of contributors to open source projects is hard and a difficult trade-off. Something similar to the #Debian #OpenPGP #web-of-trust would potentially have mitigated this style of attack somewhat, but with a different trade-off. We might have to think much harder about trust in individual accounts, and for some projects requiring a link to a real-world country-issued ID document may be the right balance (for others it wouldn't work). That is neither an easy nor a quick path, though. Also note that sophisticated nation state attackers will probably not have a problem procuring "good" fake IDs. It might still raise the bar, though. 9. What happened here seems clearly criminal - at least under my IANAL naive understanding of EU criminal law. There was clear intent to cause harm, and that makes the specific method less important. The legal system should also be able to help in mitigating supply chain attacks; not in preventing them, but in making them more costly if attackers can be tracked down (this is difficult in itself, see point 8) and face risk of punishment after the fact. H/T @GossiTheDog@cyberplace.social @AndresFreundTec@mastodon.social @danderson@hachyderm.io @briankrebs @eloy@hsnl.social

@Gaelan@cathode.church @neil@mastodon.neilzone.co.uk You see, I saw your response and I *still* clicked anyway. Social engineering will be the death of me.