Andrew Nesbitt

npm publish-time malware scanning and dual-use metadata https://github.blog/changelog/2026-07-28-npm-publish-time-malware-scanning-and-dual-use-metadata
#github

Lots of new stuff in pip 26.2:

🍊 Support for Python 3.15
🍊 Selecting only dependencies
🍊 Experimental: venv based build isolation
🍊 Faster repeated resolves by caching index simple responses
🍊 No more progress bar spam in CI
🍊 Deprecation to remove the legacy dependency resolver (--use-deprecated=legacy-resolver)

See @ichard26's post for more!

https://sichard.ca/blog/2026/07/whats-new-in-pip-26.2/
#Python #pip

Can you help me out with some citations? I'd love reliable articles that support or refute these #AI statements:
0) AI-generated code's harder to review (because it looks plausible but you can't try and work on a "the author meant [thing]" basis)
1) People are less good at reviewing AI-generated code (because they're inclined to trust what the computer says)
2) AI-generated code has high environmental costs (e.g. figures about DC capacity?)
3) Using AI is cognitively harmful

Boosts very welcome

GitHub Actions holds potentially malicious workflows for approval https://github.blog/changelog/2026-07-28-github-actions-holds-unproven-workflows-for-approval
#github

RE: https://mastodon.me.uk/@Floppy/116940067151749214

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.

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

@andrewnez @gvwilson @fedora is planning to use

https://fedoraproject.org/wiki/Changes/Adopt_PURL_Metadata

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

Why npm Dependency Trees Are So Big

https://nesbitt.io/2026/07/28/why-npm-dependency-trees-are-so-big.html

@defuneste I’m still very dependent on https://octobox.io to stay on top of everything all these years later

@defuneste notifications is such a mess 🫠

Why npm Dependency Trees Are So Big

https://nesbitt.io/2026/07/28/why-npm-dependency-trees-are-so-big.html

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!

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 https://lrug.org/meetings/2026/august/ including the all important registration link at https://www.tickettailor.com/events/lrug/2331753

Zięba-Kozarzewski 2026: "No Edges, No Verdict: A Large-Scale Empirical Study of Declared Dependency Graphs in 78K SBOMs in the Wild" https://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."

Dietrich et al 2026: "No Snake Oil: Verifying Python Package Builds" https://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."

@gvwilson I’m amazed they managed to find that many in the wild, no-one in oss uses them

@mikemcquaid I always tell people "Open source is doomed to be fun". Love that you put it in writing so eloquently, now I can point folks to your post. Thanks Mike!

Homebrew is thriving while other open source projects struggle. Its scarcest resource isn't money: it's maintainer motivation.

https://mikemcquaid.com/open-source-must-be-fun-or-it-will-die/

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.

https://www.zhongruoyu.com/talks/homebrew-on-arm64-linux/

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.

https://starhaven.io/blog/2026-07-27-the-package-manager-for-everywhere/

ALT https://effinbirds.com/post/823225423568814080