This content type is full of IndieWeb post types, which are all content types which allow me to take greater ownership of my own data. These are likely unrelated to my blog posts. You can find a better breakdown by actual post kind below:
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.
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,
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.
I think the most important lesson from the xz incident is that if you're losing an online argument about the quality of your open-source project, you can now safely accuse the opponents of being state-sponsored sock puppets and drop the mic
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?
I wrote this ⬆️ a few years ago.
As the fallout from the #XZ hack reverberates, expect to see people calling for a "real name" policy for contributors to critical infrastructure.
But, as I explain, there are several practical problems with that.
https://shkspr.mobi/blog/2021/02/whats-my-name-again/
That's before we get to the ethical and privacy issues. Oh, and making it *easier* for attackers to target named individuals.
Maintenance is more important than innovation.
This xz debacle is a symptom of a system that prioritizes lots of things above maintenance.
Take this as a reminder to rest, to mend things & pay attention to what needs mending in yourself. Do the radical thing of working slowly and making all things more whole.
Proposals(re)accepted: add slices.Repeat functionaccepted: report use of too-new standard library symbols with go vetFrom around the communityBlog: Context-induced performance bottleneck in Go by Gabriel AugendreNew community Q&A site: godev.com, powerd by Apache AnswerBlog: Go Enums Still Suck...
Jacob talks about the backlash against open source maintainers seeking compensation, ethical use of software, financial support for maintainers, and complexities in licensing.
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.
SQLite is often misconceived as a "toy database", only good for mobile applications and embedded systems because it's default configuration is optimized for embedded use cases, so most people trying it will encounter poor performances and the dreaded SQLITE_BUSY error. But what if I told you that by tuning a
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
Attached: 1 image
This text is not something we wrote in a rush this morning to meet the moment. We've had variations on this on our site from day 1. I believed it then and I believe it now.
people are saying the xz backdoor is likely the work of a nation state actor, and given that it appears to been slow rolled for a couple of years and immediately became obsolete before it was fully launched - you do have to admit it bears the hallmarks of a government IT project
@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.
New blogpost: _**[It is about trust, not software](https://neilzone.co.uk/2024-03-30-it-is-about-trust-not-software.html)**_
My reflections on the `xz` situation.
> This isn't about software, it's about trust, and trust, especially *digital* trust, is easy to misplace...
Justin & Autumn take you with them to the 2024 SoCal Linux Expo where they asked six fellow attendees about their favorite open source projects and their least favorite commands.
Awesome! A substandard SBOM is better than none, and a highly detailed SBOM is better than that 🤓 then plugging it into something like dependency-management-data or guac to understand more about your software estate is a great next step. Making sure the runtime environment is safer is a great shout too - recently found out about OpenSSF's S2C2F which has some good stuff in there around reducing supply chain security risks too
stateunstableinblogdate3/29/2024
😖 Unstable
Updating at the speed of light, blink once and a word could be gone! These nodes are eratic, unstable, dangerous, but that's why they are fun.
Please note: …
I know nobody wants to admit it, but security shit shows like heartbleed, log4shell, or xzgate are kinda exciting times to live thru. 🤓
Also I’m afraid it’s the only way to prove the problems we’ve been droning about for years are real and not made up by greedy maintainers.
My heart goes out to xz. A single maintainer, who was clearly in a rough place with mental health, screaming out to the world for some help and additional contributions, and somebody shows up wanti...
This game came by at just the right time. Covid gave me the perfect excuse to play this game for hours on end without feeling guilty, and now I’ve finally achieved 5 stars!
🐶💩⛳️ I binned the bag in 4 throws, rating ⭐️⭐️⭐️⭐️⭐️
https://vole.wtf/dog-poo-golf/
my only contribution to the xz discourse:
absolutely none of the supply chain stuff we're currently doing, including the things i like, would have stopped this. the only things that can stop this are (1) compulsively treating all code as untrusted, and (2) way, way stronger capability checks and restrictions in running systems. (1) is economically infeasible (the world runs on free labor from OSS), and (2) has had only very limited practical success.
Random, unordered, probably useless thoughts on today's apocalypxze... Part of the success in getting this into Debian may be the result of there being no xz maintainer there. It is "maintained" ...
@glyph @eb@social.coop I'm frustrated that big tech's efforts to increase core library security are "your project is too popular, you must use 2FA" and "the best reverse engineers in the world will find your bugs and put you on a 90 day disclosure deadline" and not "here is $100K/year and benefits to keep doing what you're doing at your own pace."
@eb@social.coop I really hope that this causes an industry-wide reckoning with the common practice of letting your entire goddamn product rest on the shoulders of one overworked person having a slow mental health crisis without financially or operationally supporting them whatsoever. I want everyone who has an open source dependency to read this message https://www.mail-archive.com/xz-devel@tukaani.org/msg00567.html
It’s not surprising that a major security vulnerability is once again caused by maintainer burnout and someone stepping in to take over. We’ve all been talking about that risk for years.
Sadly it’s also unsurprising that OSS teams still are going to need to plead with management to stay funded, and paid OSS maintainers will still do unpaid overtime to work with volunteers. 🙃.
Jerod, KBall & Nick discuss the latest news: Devin, Astro DB, The JavaScript Registry, Tailwind 4 & Angular merging with Wiz. Oh, and a surprise mini-game of HeadLIES!
Join RedMonk analysts James Governor and Kate Holterhoff as they chat with Dan Moore about Hacker News, the social news website for developers. This conversation digs into significant questions concerning this network that include not only what makes it unique, but also the special sauce that makes developers flock there. Moore suggests strategies for vendors hoping to successfully engage this community, and more general best practices for becoming involved.
This RedMonk Conversation was originally published in video form on March 28, 2024.
Big fan of oapi-codegen for building openapi specified, contract first Go based APIs, great to see a v2 release reduced module dependencies, and isolated examples in another module! Great pattern to learn and understand. #golang #openapi https://github.com/deepmap/oapi-codegen/releases/tag/v2.0.0