Andrew Nesbitt

@andrewnez@mastodon.social · Joined ⁨Apr⁩ ⁨2017⁩

Package Management Nerd, working on mapping the world of open source software ecosyste.ms and blogging about package managers at nesbitt.io

Homepage
nesbitt.io verified

Andrew Nesbitt boosted

RE: mastodon.me.uk/@Floppy/1169400

This is actually happening; we're building a community to execute a bigotry-free #Rails fork (29 people and increasing at time of writing). Come join us, we need your help and expertise.

matrix.to/#/#amiko:matrix.org

James Smith 💾@Floppy@mastodon.me.uk

I am ashamed of the fact that I’m stuck on #Rails because of the sunk costs of what I’ve already built, as are *so many* other project like Mastodon.

We cannot “just move”, the cost is enormous.

The Rails core team seem utterly compromised and under his spell. Nobody will speak out.

We need a hard #RailsFork. Now. And we need to coordinate to do it together and build a team.

I’m in. Who else?

Andrew Nesbitt boosted

Replying to @⁨andrewnez@mastodon.social⁩

@andrewnez @gvwilson @fedora is planning to use

fedoraproject.org/wiki/Changes

which is at the very least SBOM adjacent.

We find that otherwise each packaging ecosyatem has its own way of specifying dependencies, and this makes it harder for security teams to flag issues accurately

fedoraproject.orgChanges/Adopt PURL Metadata - Fedora Project Wiki

Andrew Nesbitt boosted

I know Mastodon hates LLM's and AI. So here goes!

I recently got access to trusted access of cyber capabilities of both openai and anthropic, which also allows you to weaponize security vulnerabilities.

The speed at which these parrots can find bugs and be creative enough to exploit them is staggering.

I recently pointed an LLM at an kernel fix that was reachable by an unprivileged namespace on Debian and it fully weaponized it, without too much me prompting it in the right direction, in about 7-9 hours.

I don't think open-source and companies will know what's coming for them once these open-source weight models will have broader reach and get better at exploiting vulnerabilities on a massive scale as anyone can access them.

The bottom line I think is, you cannot patch faster than the attackers can easily chain all kinds of vulnerabilities together and just move laterally on an incredibly fast pace.

I've started reporting vulnerabilities to all kinds of projects and the majority have trouble or patching issues found. There's not enough maintainers, or there's simply none anymore.

I've been getting quite worried about what our future will look like for data privacy. I think outright not running an LLM over your codebase to find critical security vulnerabilities because of your moral stance will keep us more insecure.

Please run an LLM over your code base if it's internet facing or something critical, we thank you!

Can't wait for the discussions on this!

Andrew Nesbitt boosted

Our August meeting is due on Monday 10th August. Once again we are hosted by the kind folks at GoCardless in their offices on Goswell Road.

We have one talk lined up so far:

* @felltir on having shame while metaprogramming

But there's always room for more. Get in touch on talks@lrug.org if you've got something to say.

More about the meeting at lrug.org/meetings/2026/august/ including the all important registration link at tickettailor.com/events/lrug/2

LRUGAugust 2026 Meeting | London Ruby User GroupThe August 2026 meeting of LRUG will be on Monday the 10th of August, from 6:00pm to 8:00pm (meeting starts at 6:30pm). The venue this month is provided by GoCardless and is in their offices, on Goswell Road. Full venue and registration details are given below.

Andrew Nesbitt boosted

Zięba-Kozarzewski 2026: "No Edges, No Verdict: A Large-Scale Empirical Study of Declared Dependency Graphs in 78K SBOMs in the Wild" arxiv.org/abs/2607.22140 "52.9% of SBOMs declare no edges at all, 8.8% declare a dependency block yet leave the majority of components isolated, and 38.3% form well-connected graphs."

arXiv logoarXiv.orgNo Edges, No Verdict: A Large-Scale Empirical Study of Declared Dependency Graphs in 78K SBOMs in the WildSoftware Bills of Materials (SBOMs) are consumed not only as component inventories but as dependency graphs: vulnerability triage, reachability filtering, and impact analysis all traverse the edges an SBOM declares. We present the first large-scale characterization of the declared dependency graph across 78,612 real-world SBOM files from the Wild SBOMs dataset (77,092 parseable). We find that the population splits into three regimes: 52.9% of SBOMs declare no edges at all (failing the NTIA minimum-elements requirement of dependency relationships), 8.8% declare a dependency block yet leave the majority of components isolated (degenerate regime; among such SBOMs with at least 50 components the median orphan share is 93%, and our 11 Syft-generated container-image SBOMs fall in this regime at 95-98% orphans), and 38.3% form well-connected graphs. Edge emission is determined by the generator, not the described software (0%-100% no-edge rates across tools), and the specification-level mechan

Andrew Nesbitt boosted

Dietrich et al 2026: "No Snake Oil: Verifying Python Package Builds" arxiv.org/abs/2607.21888 "Although only 15.4% of macaron rebuilds and 19.1% of oss-rebuild rebuilds are byte-for-byte identical to the published PyPI wheels, daleq4py establishes wheel equivalence for 60.2% and 78.9% of source-equivalent rebuilds, respectively."

arXiv logoarXiv.orgNo Snake Oil: Verifying Python Package BuildsPython has become the default language for interacting with AI, with packages being distributed through registries like the Python Package Index (PyPI). This creates a need to analyse supply chains comprising such packages. One such analysis is to rebuild packages in order to identify compromised builds injecting malware. Independent rebuilds in hardened environments have the added advantage that they can generate and record provenance in order to increase the trustworthiness of packages. Two tools that are designed to automate such rebuilds and run them at scale are macaron and oss-rebuild. We study 12,180 popular releases from PyPI and find that the byte-for-byte equivalence rate is generally low. We analyse the reasons why they produce different wheels, and find that equivalence between the original and rebuilt wheels can often still be established, preserving most of the guarantees users expect from rebuildable releases. We present and evaluate daleq4py, a tool to establish the equ

Andrew Nesbitt boosted

Replying to @⁨linnane@mastodon.social⁩

Mentioned in the post and worth your time: @zhongruoyu put huge effort into Homebrew's ARM64 Linux support and helping make it a Tier 1 platform. His FOSDEM 2025 talk on that work is excellent.

zhongruoyu.com/talks/homebrew-

Ruoyu ZhongHomebrew on ARM64 LinuxThis talk explored the technical hurdles for adapting the package manager to the ARM64 Linux platform. I examined the work done so far and the ongoing work needed to make Homebrew more accessible and reliable for ARM64 Linux users.

Andrew Nesbitt boosted

Homebrew describes itself as The Package Manager for Everywhere now. I went through our public analytics to see how well that holds up.

@UniversalBlue images are about a quarter of non-CI Linux events, with Bazzite alone at roughly one in five. They ship brew by default and it shows.

If you maintain something that ships Homebrew, I’d like to hear from you.

starhaven.io/blog/2026-07-27-t

The starhaven.io logo: a star above a crescent on a dark field.starhaven.ioThe Package Manager for EverywhereHomebrew has grown far beyond its macOS roots

Andrew Nesbitt boosted

Hey peeps! I am looking for a new full-time role as a Senior Product Engineer or Tech Lead, specialising in Ruby on Rails.

For the past couple of years, I have been building Cammi — a set of tools designed to help people who are neurodivergent get unstuck and work toward things that really matter to them. Now that it has launched and can continue in the background, I am ready to bring everything I have learned back into a collaborative product team. I have written more about that decision on my blog, linked in the comments.

I love being close to the product: speaking to users, doing discovery, helping teams identify the most valuable problems, and then writing great code to solve them.

While at Florence, I had the opportunity to lead discovery, empower my team to do the same, and focus our engineering effort on the most impactful work. I would love to find a role where I can work in that way again.

A selfie of me. A white woman with chin length wavy light brown hair.
ALT

Andrew Nesbitt boosted

Replying to @⁨andrewnez@mastodon.social⁩

@andrewnez ooh! The setup-uv major version bump due to the caching change is possibly good addition to include!

github.com/astral-sh/setup-uv/

Changes
This release disables the default cache cache pruning to ease the load on the PyPi infrastructure.
Since users might experience more GitHub Actions cache usage which might result in higher ...GitHubRelease v9.0.0 🌈 Change `prune-cache` default to `false` · astral-sh/setup-uvChanges This release disables the default cache cache pruning to ease the load on the PyPi infrastructure. Since users might experience more GitHub Actions cache usage which might result in higher ...

Anyone else get the fear when they get a dependabot update for anything called xz? github.com/git-pkgs/archives/p

Bumps github.com/ulikunitz/xz from 0.5.15 to 0.5.16.

Commits

024f909 isterminal_fallback.go: ensure +build and go:build lines are consistent
ba40d80 Prepare release v0.5.16
82b346c internal/term:...GitHubBump github.com/ulikunitz/xz from 0.5.15 to 0.5.16 by dependabot[bot] · Pull Request #18 · git-pkgs/archivesBumps github.com/ulikunitz/xz from 0.5.15 to 0.5.16. Commits 024f909 isterminal_fallback.go: ensure +build and go:build lines are consistent ba40d80 Prepare release v0.5.16 82b346c internal/term:...by dependabot[bot]