You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
And if so (or if they already are in some cases) has the project plans for documenting or developing some tooling to automatically re-build and compare the checksum for packages potentially impacted by a security breach of one of the infrastructure providers (e.g. a CI provider) as recently happened with Circle CI?
The auditing of packages with reproducible builds could be triggered manually after specific security breach events.
It could also happen continuously (at least for the most popular packages to save CI costs), by running on different CI providers (for the most common CPU architectures) to have them cross-validate one another to be able to check that not any of them is corrupting the generated binary artifacts with a malware infected compiler for instance.
Note that, under Linux, the docker image itself should ideally be made reproducible to be able to check that it has not been tempered with. For Operating Systems without docker... I don't know what to do beyond trusting that different CI providers do not share tempered compilers and system libraries.
The text was updated successfully, but these errors were encountered:
Note that conda/conda-build#2140 is "only" the first step. Having extra tools and doc to automate cross-checking of reproduced builds by different CI providers was not discussed as part of conda/conda-build#2140.
Your question:
Has the conda-forge project any plans to make (some of) the builds byte-for-byte reproducible?
And if so (or if they already are in some cases) has the project plans for documenting or developing some tooling to automatically re-build and compare the checksum for packages potentially impacted by a security breach of one of the infrastructure providers (e.g. a CI provider) as recently happened with Circle CI?
The auditing of packages with reproducible builds could be triggered manually after specific security breach events.
It could also happen continuously (at least for the most popular packages to save CI costs), by running on different CI providers (for the most common CPU architectures) to have them cross-validate one another to be able to check that not any of them is corrupting the generated binary artifacts with a malware infected compiler for instance.
Note that, under Linux, the docker image itself should ideally be made reproducible to be able to check that it has not been tempered with. For Operating Systems without docker... I don't know what to do beyond trusting that different CI providers do not share tempered compilers and system libraries.
The text was updated successfully, but these errors were encountered: