>> If we didn’t want to trust any binaries built by someone else or proprietary code, how much work would that be?
- Docker Notary (The Update Framework) - PEP 458, PEP 480 (TUF) - Host GPG .asc(s) for things you just found ## To build the whole toolchain yourself? Build, Package, Install, Upgrade/Replace_with_new_container - Makefile - Conda-forge recipes with CI (meta.yaml, build.sh) - [x] platform / architecture compilation optimizations - [x] support for Windows (build.bat) - [x] support for Mac & Linux (build.sh) - conda constructor - build an installer - tar up the whole virtualenvwrapper virtualenv and unpack that into the exact same path in a container - and check the .ASC ## To sign trusted releases: - See: Warehouse & GPG, Wheel & signatures - *The Update Framework* - There are plans to merge support for TUF (which is designed to withstand package repo compromise) into Warehouse at some point, AFAIU. TUF: The Update Framework ======================== | Wikipedia: https://en.wikipedia.org/wiki/The_Update_Framework_(TUF) | Homepage: https://theupdateframework.github.io/ | Src: https://github.com/theupdateframework | Spec: https://github.com/theupdateframework/specification/blob/master/tuf-spec.md - Docker Notary supports TUF - TUF is mostly written in Python - Python PEP458: - https://www.pypa.io/en/latest/roadmap/#pypi-integrate-tuf - "PEP 458 -- Surviving a Compromise of PyPI" https://www.python.org/dev/peps/pep-0458/"; - "PEP 480 -- Surviving a Compromise of PyPI: The Maximum Security Model" https://www.python.org/dev/peps/pep-0480/ - https://github.com/pypa/pip/issues/1035 "Implement "hook" support for package signature verification." ## To build native packages for your package and the whole toolchain? - fpm - release keys (note that any key in the ring can sign for any package) - docker/kubernetes - conda-forge (Appveyor, CircleCI, Travis CI) - OSX instances fpm ===== | Src: https://github.com/jordansissel/fpm | Docs: https://fpm.readthedocs.io/en/latest/ | Docs: https://fpm.readthedocs.io/en/latest/source/virtualenv.html - { deb, rpm, osxpkg, tar, } ## To host package repositories yourselves: Pulp ===== | Homepage: https://pulpproject.org/ | Src: https://github.com/pulp/ ## To sign releases uploaded to e.g. GitHub (which are CDN'd, AFAIU): - Wheel had a native signing mechanism that's since been removed - [ ] Attach a GPG .asc signature to the GitHub release - https://wiki.debian.org/Creating%20signed%20GitHub%20releases ## To sign commits and merges: - Configure a per-project GPG agent and keyring config - Trust local datetimes - Remember that `git push -f` can occur. ## Include SELinux filesystem labels with the package: - This isn't possible with Python packaging (without extending setup.py with a custom command with a build dependency or calling out to a shell script that may be locatable with distutils.spawn.find_executable) On Thu, Jul 26, 2018 at 1:41 PM Nathaniel Smith <n...@pobox.com> wrote: > On Thu, Jul 26, 2018, 05:48 Ben Finney via Distutils-SIG < > distutils-sig@python.org> wrote: > >> Brad Warren <b...@eff.org> writes: >> >> > Our main use case has been the long tail of individuals or small teams >> > of sysadmins who maintain servers and need or want help and automation >> > around maintaining a secure TLS configuration. >> >> For what it's worth, I certainly concur that most people in the group >> you describe will thank you to not have a bundle of custom dependencies >> from outside the OS repository, and instead make Certbot work with >> (and/or be advocates to introduce) the dependencies as OS-provided >> library packages. >> > > I wonder if they have any user survey or anything that would speak to this. > > FWIW my impression is that the kinds of sysadmins who know enough to have > opinions about packaging hygiene also know enough to set up one of > certbot's many simpler, less magical competitors. Certbot's target audience > has always been folks who didn't really understand any of this stuff and > wanted to just hit a button and have things somehow work out by whatever > means necessary. Which is great, those people deserve secure > communications. But the point is that you can't make everything your number > one priority, and when they have to choose, certbot has chosen to > prioritize "make it work" over "fit nicely into a traditional distro", and > I think that's the right decision for what they are. > > > This is definitely our preferred approach to building native packages >> > right now. To be honest, no one on my team has any experience building >> > .debs and .rpms and we’re happy to learn what we need to if we go with >> > this approach, but the more reliable automation around the process we >> > can use the better. >> >> For Debian, instead of becoming packaging experts yourselves, instead we >> ask that you make Certbot easier for *us* to package and maintain in >> Debian. See <URL:https://wiki.debian.org/UpstreamGuide>; other OS >> projects likely have similar documentation. >> > > That's a nice idea in principle and all, but see also > https://wiki.debian.org/LetsEncrypt which cheerily notes that the version > of certbot shipped in stretch is so old that it doesn't actually work, and > as a workaround it recommends running a command that will take down the > user's website without even warning that that's what it does. > > I love Debian. I've been a loyal user for twenty years. But Debian is > really bad at coping with software that needs to react quickly to changing > external conditions, or that depends on a tight feedback loop between users > and developers. (Indeed, Debian's whole value-add is to insert themselves > as a buffer between users and developers, which is great in some situations > but terrible in others.) > > Maybe if certbot worked hard enough they could arrange to get special > treatment like Firefox or clamav or something, but in their position I > would see this as a total non-starter. Even if they did somehow manage to > navigate Debian's politics, they'd still have to go and repeat the process > for Redhat, SuSE, Ubuntu, Gentoo, ... > > -n > >> -- > Distutils-SIG mailing list -- distutils-sig@python.org > To unsubscribe send an email to distutils-sig-le...@python.org > https://mail.python.org/mm3/mailman3/lists/distutils-sig.python.org/ > Message archived at > https://mail.python.org/mm3/archives/list/distutils-sig@python.org/message/EDCELE3LBN7LMUXF6FX4EYERX4I33ELL/ >
-- Distutils-SIG mailing list -- distutils-sig@python.org To unsubscribe send an email to distutils-sig-le...@python.org https://mail.python.org/mm3/mailman3/lists/distutils-sig.python.org/ Message archived at https://mail.python.org/mm3/archives/list/distutils-sig@python.org/message/SK66YOWDEE42KUDHDBSEESIC3O6XUIGQ/
