I’m an upstream maintainer of python-acme. Both Let’s Encrypt [1] and the Certbot client which uses this library encourage people to use Let’s Encrypt’s staging endpoint to test that they have things working correctly before using Let’s Encrypt’s production endpoint which has strict rate limits. Certbot uses the staging endpoint when —dry-run is provided which we tell all Debian Stretch users to use [2] and we have been doing so for years.
If this update is released after November 1st, I would expect a significant amount of bug reports and confusion as well as some people resorting to using the production environment to debug domain validation problems with their setup which can easily cause them to become rate limited. Delaying this update won’t break existing setups where Certbot is automatically renewing the user’s certificates, but I personally think there will be enough headaches about —dry-run breaking from those initially creating or modifying their setup that it’s worth releasing early. Best, Brad [1] https://letsencrypt.org/docs/staging-environment/ [2] https://certbot.eff.org/lets-encrypt/debianstretch-other > On Oct 25, 2019, at 10:18 AM, Adam D. Barratt <a...@adam-barratt.org.uk> > wrote: > > On Tue, 2019-09-03 at 22:16 -0400, Harlan Lieberman-Berg wrote: >> We have a proposed update for acme in stretch (oldstable). This is >> necessary to prevent the package, and all its dependencies, stopping >> to work due to changes to the web service that the acme module is >> primarily used for. (Let's Encrypt) > > Apparently this is now only an issue for the staging endpoint in the > immediate future, according to > https://community.letsencrypt.org/t/acme-v2-scheduled-deprecation-of-unauthenticated-resource-gets/74380/3 > > On that basis, could releasing this update now wait until the next > stretch point release, or is the change to the staging endpoint still > likely to have a significant enough impact to want to make an earlier > release? > > Regards, > > Adam > > -- > To unsubscribe, send mail to 939364-unsubscr...@bugs.debian.org. >
