>> 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 <njs@pobox.com> wrote:
On Thu, Jul 26, 2018, 05:48 Ben Finney via Distutils-SIG <distutils-sig@python.org> wrote:
Brad Warren <bmw@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-leave@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/