Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Open source security at Astral

astral.sh

Post reply on HN
Print view View original

11–20 of 120 posts

Re: Open source security at Astral

#11

Post by raphinou »

snthpy wrote: post #8
raphinou wrote: post #6

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 inte…

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.

Here's the GitHub repo of the backend code: https://github.com/asfaload/asfaload

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 !

Re: Open source security at Astral

#12

Post by raphinou »

arianvanp wrote: post #10
darkamaul wrote: post #7

Earlier quoted context omitted.

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)? [0] https://docs.github.com/en/actions/how-tos/secure-your-work/...

The problem is nobody checks. All the axios releases had attestations except for the compromised one. npm installed it anyway.

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.

Re: Open source security at Astral

#19

Post by dirkc »

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.

Re: Open source security at Astral

#20

Post by Eufrat »

3abiton wrote: post #16
trashcan2137 wrote: post #15

Lengths people will go to rediscover Nix/Guix is beyond me

I don't see the connection though?

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.

Post reply on HN