Took a minute more to read the gdoc link.
The CI build should produce every {OS,} package as a build artifact (along
with coverage and static analysis reports). #goeswithoutsaying
Someone can probably point to a good GitLab CI config that produces all of
the requisite artifacts and uploads them to the appropriate repos (with an
optional manual approval step).
## a new package updater tool
- IIRC, cloudmatrix/esky has transactional updates but is no longer updated.
- what are other good ways way to do auto-updating transactional updates?
- It makes sense to *start with TUF* (which is derived from the Tor updater)
- Polling for updates costs time and money.
## systemd/cron config
Official repos with e.g. Puppet, Salt, Ansible configs would be
advantageous because:
- certbot should be run on an appropriately secured baseline (with
filesystem labels)
- otherwise there are like 10 not even forks of unofficial configs and no
consensus
These also need to be part of the CI build.
On Thursday, July 26, 2018, Wes Turner <wes.tur...@gmail.com> wrote:
>
>
> >> 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/JI63HVLYJXGUR6SLOWD4ZFWUKH5J2FS7/
