One (amongst other) big problem with current software supply chain is that a lot of tools and dependencies are downloaded (eg from GitHub releases) without any validation that it was published by the expected author. That's why I'm working on an open source, auditable, accountless, self hostable, multi sig file authentication solution. The multi sig approach can protect against axios-like breaches. If this is of interest to you, take a look at https://asfaload.com/
darkamaul 2 hours ago [-]
I’m maybe not understanding here, but isn’t it the point of release attestations (to authenticate that the release was produced by the authors)?
Artifact attestation are indeed another solution based on https://www.sigstore.dev/ . I still think Asfaload is a good alternative, making different choices than sigstore:
- Asfaload is accountless(keys are identity) while sigstore relies on openid connect[1], which will tie most user to a mega corp
- Asfaload ' backend is a public git, making it easily auditable
- Asfaload will be easy to self host, meaning you can easily deploy it internally
- Asfaload is multisig, meaning event if GitHub account is breached, malevolent artifacts can be detected
- validating a download is transparant to the user, which only requires the download url, contrary to sigstore [2]
So Asfaload is not the only solution, but I think it has some unique characteristics that make it worth evaluating.
All the axios releases had attestations except for the compromised one. npm installed it anyway.
raphinou 2 hours ago [-]
Yes, that's why I aim to make the checks transparant to the user. You only need to provide the download url for the authentication to take place. I really need to record a small demo of it.
snthpy 2 hours ago [-]
Overall I believe this is the right approach and something like this is what's required. I can't see any code or your product though so I'm not sure what to make of it.
I'm looking for early testers, let me know if you are interested to test it !
sevg 2 hours ago [-]
FYI it was actually William Woodruff (the article author) and his team at Trail of Bits that worked with PyPI to implement Trusted Publishing.
dirkc 1 hours ago [-]
The open source ecosystem has come very far and proven to be resilient. And while trust will remain a crucial part of any ecosystem, we urgently need to improve our tools and practices when it comes to sandboxing 3rd party code.
Almost every time I bump into uv in project work, the touted benefit is that it makes it easier to run projects with different python versions and avoiding clashes of 3rd dependencies - basically pyenv + venv + speed.
That sends a cold shiver down my spine, because it tells me that people are running all these different tools on their host machine with zero sandboxing.
Oxodao 47 minutes ago [-]
meh not always. I do use uv IN docker all the time, its quite handy
dirkc 40 minutes ago [-]
Honest question - what are the main benefits for you when you use it in docker?
ps. I feel like I've been doing python so long that my workflows have routed around a lot of legit problems :)
sersi 32 minutes ago [-]
Main reason I now use uv is being able to specify a cool down period. pip allows it but it's with a timestamp so pretty much useless..
And that doesn't prevent me from running it into a sandbox or vm for an additional layer of security.
zwp 23 minutes ago [-]
> pip allows it but it's with a timestamp
A PR to be able to use a relative timestamp in pip was merged just last week
If anyone from Astral sees this: at this level of effort, how do you deal with the enormous dependence on Github itself? You maintain social connections with upstream, and with PyPA... what if Github is compromised/buggy and changes the effect of some setting you depend on?
darkamaul 3 hours ago [-]
With the recent incidents affecting Trivy and litellm, I find it extremely useful to have a guide on what to do to secure your release process.
The advices here are really solid and actionable, and I would suggest any team to read them, and implement them if possible.
The scary part with supply chain security is that we are only as secure as our dependencies, and if the platform you’re using has non secure defaults, the efforts to secure the full chain are that much higher.
tao_oat 33 minutes ago [-]
This is a really great overview; what a useful resource for other open-source projects.
trashcan2137 1 hours ago [-]
Lengths people will go to rediscover Nix/Guix is beyond me
3abiton 1 hours ago [-]
I don't see the connection though?
Eufrat 60 minutes ago [-]
Nix provides declarative, reproducible builds. So, ostensibly, if you had your build system using Nix, then some of the issues here go away.
Unfortunately, Nix is also not how most people function. You have to do things the Nix way, period. The value in part comes from this strong opinion, but it also makes it inherently niche. Most people do not want to learn an entire new language/paradigm just so they can get this feature. And so it becomes a chicken and egg problem. IMHO, I think it also suffers from a little bit of snobbery and poor naming (Nix vs. NixOS vs. Nixpkgs) which makes it that much harder to get traction.
diffeomorphism 34 minutes ago [-]
There are different notions of "reproducible". Nix does not automatically make builds reproducible in the way that matters here:
[0] https://docs.github.com/en/actions/how-tos/secure-your-work/...
- Asfaload is accountless(keys are identity) while sigstore relies on openid connect[1], which will tie most user to a mega corp
- Asfaload ' backend is a public git, making it easily auditable
- Asfaload will be easy to self host, meaning you can easily deploy it internally
- Asfaload is multisig, meaning event if GitHub account is breached, malevolent artifacts can be detected
- validating a download is transparant to the user, which only requires the download url, contrary to sigstore [2]
So Asfaload is not the only solution, but I think it has some unique characteristics that make it worth evaluating.
1:https://docs.sigstore.dev/about/security/
2: https://docs.sigstore.dev/cosign/verifying/verify/
All the axios releases had attestations except for the compromised one. npm installed it anyway.
There's also a spec of the approach at https://github.com/asfaload/spec
I'm looking for early testers, let me know if you are interested to test it !
Almost every time I bump into uv in project work, the touted benefit is that it makes it easier to run projects with different python versions and avoiding clashes of 3rd dependencies - basically pyenv + venv + speed.
That sends a cold shiver down my spine, because it tells me that people are running all these different tools on their host machine with zero sandboxing.
ps. I feel like I've been doing python so long that my workflows have routed around a lot of legit problems :)
And that doesn't prevent me from running it into a sandbox or vm for an additional layer of security.
A PR to be able to use a relative timestamp in pip was merged just last week
https://github.com/pypa/pip/pull/13837/commits
The advices here are really solid and actionable, and I would suggest any team to read them, and implement them if possible.
The scary part with supply chain security is that we are only as secure as our dependencies, and if the platform you’re using has non secure defaults, the efforts to secure the full chain are that much higher.
Unfortunately, Nix is also not how most people function. You have to do things the Nix way, period. The value in part comes from this strong opinion, but it also makes it inherently niche. Most people do not want to learn an entire new language/paradigm just so they can get this feature. And so it becomes a chicken and egg problem. IMHO, I think it also suffers from a little bit of snobbery and poor naming (Nix vs. NixOS vs. Nixpkgs) which makes it that much harder to get traction.
https://reproducible.nixos.org
It is still good at that but the difference to other distros is rather small:
https://reproducible-builds.org/citests/
https://github.com/backnotprop/oss-security-audit