Rendered at 12:45:34 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
edelbitter 1 days ago [-]
> this file was independently reproduced by <name of trusted party>
Sounds risky, unless paired with strong policy about what a verifier should do.
e.g. if the verifier just grants network access to the buildbot that then checks what the result should look like, then compromise could remain invisible while the label silently downgrade to "independently downloaded by".
And I do not expect there are many parties that would be willing to provide such service beyond their own needs, while simultaneously not already providing that service in places where the infrastructure and policies are already set (such as Debian). Or at least they would already contribute towards build dependencies that do not break reproducibility on every other version bump.
kpcyrd 1 days ago [-]
I think running this with network access disabled is a good idea, but it's also important to note "was independently reproduced" is about "we challenged the SBOM and were able to produce this output from the stated inputs".
Whether the code in the SBOM subvertly downloads additional code (during build time or later during runtime) is still for the code reviewer to be found.
whateverboat 1 days ago [-]
For python, it seems very difficult to actually do reproducible builds in a way that is useful, because python wheels have very implicit assumptions about paths and environemtns that do not happen anywhere else.
zejn 1 days ago [-]
I don't know what your experience is, but I can pack a reproducible AppImage containing a Python virtual environment and it works okay.
whateverboat 12 hours ago [-]
Yeah, but then you are packaging the distribution, which is a valid and often a good choice, but then it is not a reproducible wheel anymore.
crabbone 1 days ago [-]
These people are so far gone in their fantasy land...
> So we either have to shrug and say, "don't use sdists if you want reproducible builds,"
What is this, I can't even... How can anyone expect to have a reproducible build's artifact if they downloaded the source?
Now, and most importantly, all this talk is about "pure" (as in Python-only) packages. This is, practically, worthless for most real Python projects because those rely on native bindings. Why should anyone expect PyPI to be able to build those if no standard procedure exists for building them is beyond comprehension.
kpcyrd 1 days ago [-]
They use the word "Reproducible Builds" for linking the VCS commit to PyPI's repacked source code upload, that's why "reproduce the source code" sounds a little confusing.
For projects with native bindings you can still fairly trivially solve this with SBOMs, and some Linux distributions are doing this for many years now. The compiler is a dependency that needs documenting, and they explicitly write they need means to re-create the documented environment from that SBOM.
akoboldfrying 1 days ago [-]
> For projects with native bindings you can still fairly trivially solve this with SBOMs
For bitwise identical results there are many small details that need to be taken care of, even in the pure-Python case: Ensuring that files appear in the wheel (zip) file in the same order (glob() doesn't guarantee this and you can definitely see different orders from run to run), timestamps are set to some fixed standard time. Any kind of build-time code generation or pulling in of external info like git commit hashes needs to be handled. Then once you include compiled build dependencies, there might be nondeterminism in the order that a multithreaded compiler writes object code, hidden timestamps, hidden absolute paths, and things like runtime detection of CPU version leading to different instructions being emitted on different machines.
kpcyrd 20 hours ago [-]
I'm well aware of those issues (having worked on this for many years), but I still believe the majority of python packages won't be affected by this. :)
Most of these you would fix once on the relevant [build-system] and be done with it, no need to fix each individual python library.
wakawaka28 12 hours ago [-]
I don't think they are talking about getting the artifact at the same time as the source or any such thing. They are saying, the metadata required to reproduce a build is not present in that sdist format, and there's no place to attach it. So, if you got an artifact and separately got the source, you couldn't verify it without another source of information about how to do the build itself in exactly the same way. It goes beyond pure reproducibility as well. Without that metadata to set up your environment, you may see bugs or other differences in your build that are not in the distributed artifact.
Sounds risky, unless paired with strong policy about what a verifier should do. e.g. if the verifier just grants network access to the buildbot that then checks what the result should look like, then compromise could remain invisible while the label silently downgrade to "independently downloaded by". And I do not expect there are many parties that would be willing to provide such service beyond their own needs, while simultaneously not already providing that service in places where the infrastructure and policies are already set (such as Debian). Or at least they would already contribute towards build dependencies that do not break reproducibility on every other version bump.
Whether the code in the SBOM subvertly downloads additional code (during build time or later during runtime) is still for the code reviewer to be found.
> So we either have to shrug and say, "don't use sdists if you want reproducible builds,"
What is this, I can't even... How can anyone expect to have a reproducible build's artifact if they downloaded the source?
Now, and most importantly, all this talk is about "pure" (as in Python-only) packages. This is, practically, worthless for most real Python projects because those rely on native bindings. Why should anyone expect PyPI to be able to build those if no standard procedure exists for building them is beyond comprehension.
For projects with native bindings you can still fairly trivially solve this with SBOMs, and some Linux distributions are doing this for many years now. The compiler is a dependency that needs documenting, and they explicitly write they need means to re-create the documented environment from that SBOM.
For bitwise identical results there are many small details that need to be taken care of, even in the pure-Python case: Ensuring that files appear in the wheel (zip) file in the same order (glob() doesn't guarantee this and you can definitely see different orders from run to run), timestamps are set to some fixed standard time. Any kind of build-time code generation or pulling in of external info like git commit hashes needs to be handled. Then once you include compiled build dependencies, there might be nondeterminism in the order that a multithreaded compiler writes object code, hidden timestamps, hidden absolute paths, and things like runtime detection of CPU version leading to different instructions being emitted on different machines.
Most of these you would fix once on the relevant [build-system] and be done with it, no need to fix each individual python library.