Pkg: attack vectors

Thanks for the feedback @ckneale. Such a distance check shouldn’t be too hard to implement, no? Name revocation should also be a thing then though (on package deprecation)? That might add to the implementation complexity.

I like that idea @chakravala! That would enable some ‘karma’-based system and such local settings could substantially reduce the attack surface. E.g. only trust: this list of packages I use commonly.

Additionally like for Deb packages allow for adding of cryptographic signatures.

1 Like

@dcastel - It wouldn’t take more than an afternoon to get a prototype up! This was one of my biggest gripes with the python package ecosystem. Made trying to find packages a pain, and also a security concern. Even look at R’s package system, it’s a little crazy to navigate and it’s fricking curated:
Screenshot from 2019-12-08 10-23-51 Screenshot from 2019-12-08 10-23-40

Like how is that okay? And in my opinion pythons is worse, it’s just harder to easily show that it is… I prefer verbose naming in programming… Even if it makes code look longer, its so much more readable.

“Oh yea just install abc something or another and use that one function uh forget the name something like Ec_i and some numbers you know”

Did they say “abc? ABC.RAP? abcADM?”
10 minutes of installs later
finds its abcdeFBA
now which function?

Ec_iAF1260_flux1.rda, Ec_iAF1260_flux2.   Ec_iJR904 . 

Nope nope nope. We can do way better with a tiny bit of effort.

5 Likes

I just discovered a recent preprint subtitled “A Review of Open Source Software Supply Chain Attacks,” via LWN. I haven’t looked through it in detail yet, but it seems like a very good summary of the real-world attacks that have happened to date through package managers/ecosystems, which Stefan’s post starting this thread asked about.

8 Likes

In regards to package deletion. If someone deletes a package repo, in many cases they deleted it for a reason or just dont want to maintain it anymore. Also allot of packages are forked by random people, just picking one of them would leave the job of maintaining it to them. Potentially a security threat.

But “automatically fork all registered packages” sounds like a good solution.

I have been doing a lot of different things so no ‘afternoon’ prototype yet.

I still need to start reading into Pkg & Registry APIs/source to figure out how to implement this. And some more research/tips from other software ecosystems is probably valuable and desirable.

If anyone can point me to good learning resources for this, let me know!

Also if anyone else is already working on something similar, I’d love to know as well. Hooking into something existing/(re)combining is often easier. As a prototype could we leverage existing systems with RCall/PyCall?