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

31–40 of 120 posts

Re: Open source security at Astral

#31

Post by Oxodao »

dirkc wrote: post #23
Oxodao wrote: post #22

Earlier quoted context omitted.

meh not always. I do use uv IN docker all the time, its quite handy

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 :)

Mainly the "project" system. I'm only developing python in my free time, not professionally so I'm not as well versed in its ecosystem as I would be in PHP. The fact that there's tons of way to have project-like stuff I don't want to deal with thoses. I used to do raw python containers + requirements.txt but the DX was absolutely not enjoyable. I'm just used to it now

Re: Open source security at Astral

#32

Post by Zopieux »

The entire paragraph about version pinning using hashes (and using a map lookup for in-workflow binary deps) reminds me that software engineers are forever doomed to reinvent worse versions of nixpkgs and flakes.

I don't even love Nix, it's full of pitfalls and weirdnesses, but it provides so much by-default immutability and reproducibility that I sometimes forget how others need to rediscover this stuff from first principles every time a supply chain attack makes the news.

Re: Open source security at Astral

#34

Post by 12_throw_away »

I don't have much experience with GitHub's CI offering. But if this is an accurate description of the steps you need to take to use it securely ... then I don't think it can, in fact, ever be used securely.

Even if you trust Microsoft's cloud engineering on the backend, this is a system that does not appear to follow even the most basic principles of privilege and isolation? I'm not sure why you would even try to build "supply-chain security" on top of this.

Re: Open source security at Astral

#35

Post by duskdozer »

lrvick wrote: post #28

The only binaries of uv in the world you can get that were full source bootstrapped from signed package commits to signed reviews to multi-signed deterministic artifacts are the ones from my teammates and I at stagex. All keys on geodistributed smartcards held by maintainers tied to a web of trust going back 25 years with over 5000 keys. https://stagex.tools/packages/core/uv/ Though thankful for clients that let indi…

>Why is it a bunch of mostly unpaid volunteer hackers are putting more effort into supply chain security than OpenAI.

Unpaid volunteer hackers provide their work for free under licenses designed for the purpose of allowing companies like OpenAI to use their work without paying or contributing in any form. OpenAI wants to make the most money. Why would they spend any time or money on something they can get for free?

Re: Open source security at Astral

#36

Post by nDRDY »

Zopieux wrote: post #32

The entire paragraph about version pinning using hashes (and using a map lookup for in-workflow binary deps) reminds me that software engineers are forever doomed to reinvent worse versions of nixpkgs and flakes. I don't even love Nix, it's full of pitfalls and weirdnesses, but it provides so much by-default immutability and reproducibility that I sometimes forget how others need to rediscover this stuff from first p…

>worse versions of nixpkgs and flakes

You mean statically-compiled binaries and hash pinning? Those have been around a bit longer than Nix :-)

Re: Open source security at Astral

#37

Post by ra »

duskdozer wrote: post #35
lrvick wrote: post #28

The only binaries of uv in the world you can get that were full source bootstrapped from signed package commits to signed reviews to multi-signed deterministic artifacts are the ones from my teammates and I at stagex. All keys on geodistributed smartcards held by maintainers tied to a web of trust going back 25 years with over 5000 keys. https://stagex.tools/packages/core/uv/ Though thankful for clients that let indi…

>Why is it a bunch of mostly unpaid volunteer hackers are putting more effort into supply chain security than OpenAI. Unpaid volunteer hackers provide their work for free under licenses designed for the purpose of allowing companies like OpenAI to use their work without paying or contributing in any form. OpenAI wants to make the most money. Why would they spend any time or money on something they can get for free?

Not sure if you're fully over the context that openAI bought Astral - who "own" uv.

Re: Open source security at Astral

#39

Post by hootz »

duskdozer wrote: post #35
lrvick wrote: post #28

The only binaries of uv in the world you can get that were full source bootstrapped from signed package commits to signed reviews to multi-signed deterministic artifacts are the ones from my teammates and I at stagex. All keys on geodistributed smartcards held by maintainers tied to a web of trust going back 25 years with over 5000 keys. https://stagex.tools/packages/core/uv/ Though thankful for clients that let indi…

>Why is it a bunch of mostly unpaid volunteer hackers are putting more effort into supply chain security than OpenAI. Unpaid volunteer hackers provide their work for free under licenses designed for the purpose of allowing companies like OpenAI to use their work without paying or contributing in any form. OpenAI wants to make the most money. Why would they spend any time or money on something they can get for free?

Yep. Permissive licenses, "open source", it's all just free work for the worst corporations you can think.

Re: Open source security at Astral

#40

Post by silvester23 »

dirkc wrote: post #23
Oxodao wrote: post #22

Earlier quoted context omitted.

meh not always. I do use uv IN docker all the time, its quite handy

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 :)

For us, the DX of uv for dependency management is much better than just using pip and requirements.txt.

To be clear though, we only use uv in the builder stage of our docker builds, there is no uv in the final image.

Post reply on HN