IndieWeb post types

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:

 Like

Liked danielle 🏳️‍🌈 (@endocrimes@toot.cat)
Post details
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 🙃

 Like

Liked Alex Wilson (@probablyfine@tech.lgbt)
Post details
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.

 Repost

Reposted Terence Eden (@Edent@mastodon.social)
Post details
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.

 Repost

Reposted cathos (@cathos@merveilles.town)
Post details
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.

 Like

Liked Wren Reilly (@akareilly@hachyderm.io)
Post details
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.

 Bookmark

Bookmarked Optimizing SQLite for servers
Post details
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

 Like

Liked Dan Hon (@danhon@dan.mastohon.com)
Post details
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

 Like

Liked René Mayrhofer :verified: 🇺🇦 🇹🇼 (@rene_mobile@infosec.exchange)
Post details
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

 Reply

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

 Repost

Reposted yossarian (1.3.6.1.4.1.55738) (@yossarian@infosec.exchange)
Post details
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.

 Repost

Reposted Geoffrey Thomas (@geofft@mastodon.social)
Post details
@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."

 Repost

Reposted Glyph (@glyph@mastodon.social)
Post details
@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

 Repost

Reposted danielle 🏳️‍🌈 (@endocrimes@toot.cat)
Post details
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. 🙃.

 Listen

Listened to A RedMonk Conversation: Engaging with Developers on Hacker News (With Dan Moore) | PodServe.fm
Post details
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.