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/
