Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reproducible (and signed?) builds #14

Open
effigies opened this issue Jan 1, 2019 · 2 comments
Open

Reproducible (and signed?) builds #14

effigies opened this issue Jan 1, 2019 · 2 comments

Comments

@effigies
Copy link
Member

effigies commented Jan 1, 2019

From both a reproducibility and security perspective - and I think we should take security seriously if we're building a package manager that will pull code off of the Internet and run it on health-related data - we should work towards reproducible builds. Python wheels and Docker/Singularity images should be as close to bit-for-bit identical as possible every time they're built, and a third party should be able to produce verifiably identical packages/images from the same git hash.

A few resources to look over in this topic:

This should apply equally to nfm itself and any packages produced by it.

We should also consider signed tags/packages. Tags would be relatively easy to enforce, triggering a Travis/CircleCI failure if there is no signature or it doesn't verify. Signed packages would directly contravene #8 (a cursory glance through PyPI docs does not indicate a way for us to grab the packages, verify and subsequently upload signatures). It's possible that a signed tag and reproducible package would provide sufficient assurance, but it would be multi-step, rather than built-in.

We could also consider a separate system from Travis for uploading to Python, which would verify the tag, build and sign the package with a key clearly marked as belonging to an automatic builder and upload to PyPI.

@kaczmarj
Copy link
Member

kaczmarj commented Jan 1, 2019

@effigies - I think signing nfm and workflows it distributes is a great idea. Can you explain what you want to do when you wrote

grab the packages, verify and subsequently upload signatures

from PyPi? The twine documentation suggests that packages can be signed before being uploaded to PyPi. According to pypa/twine#157 (comment), the signature for the wheel is available at {WHEEL_URL}.asc.

@effigies
Copy link
Member Author

effigies commented Jan 2, 2019

I was imagining the scenario where Travis could build the packages and upload them to PyPI, and somebody could, after the fact, download the packages from PyPI, rebuild from source and verify that the packages on PyPI match, and then sign the packages and upload just the signatures. This would preserve us from uploading a package signing key to Travis or making the whole release process manual.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants