Bug#941126: stretch-pu: package dehydrated/0.6.2-2+deb9u1
On Sat, Jan 25, 2020 at 06:08:34PM +0100, Mattia Rizzolo wrote: > On Fri, Jan 24, 2020 at 09:28:29PM +, Adam D. Barratt wrote: > > I'm aware that you both called them trivialities and quoted > > "breakages", but is it worth documenting any of them somewhere in the > > package? > > I could probably add a NEWS item for the ACMEv2 default move, as that's > probably something interesting to many. I've no added this: diff --git a/debian/dehydrated.NEWS b/debian/dehydrated.NEWS new file mode 100644 index 000..1bc0fae --- /dev/null +++ b/debian/dehydrated.NEWS @@ -0,0 +1,12 @@ +dehydrated (0.6.2-2+deb10u1~deb9u1) stretch; urgency=medium + + This update changes the default API endpoint to use ACMEv2, as ACMEv1 is + in the process of being deprecated and Let's Encrypt will stop supporting it + in the upcoming months. + This change will, amongst others, bring new features like wildcard + certificates support; however, it also slightly changes the authorization + flow, which may impact a few users, especially those using DNS validation. + Another incompatible change, is the addition of a new --accept-terms command + line flag, required when registering a new account. + + -- Mattia Rizzolo Tue, 28 Jan 2020 17:33:15 +0100 Apart from that and an updated d/changelog, the thing is the same of the previously sent diff. With that, I've uploaed the package for convenience of your review. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#941126: stretch-pu: package dehydrated/0.6.2-2+deb9u1
On Fri, Jan 24, 2020 at 09:28:29PM +, Adam D. Barratt wrote: > I'm aware that you both called them trivialities and quoted > "breakages", but is it worth documenting any of them somewhere in the > package? I could probably add a NEWS item for the ACMEv2 default move, as that's probably something interesting to many. The --acept-terms thing is something that affects only new accounts, so it's not useful to show it on upgrades (not to mention that it already doesn't work since November…), and the other DNS thing is something that I don't consider worth warning about. What do you say? In the meantime I tried on a stretch system with the stretch version getting a cert from that (I had to re-use an account from another installation since I couldn't register a new account with ACMEv1), and then update to the proposed version and renew. I only tested http-01 tbh, but dns-01 has no reasons to fail if http works… (if it does it really should only be for how the local hooks does things). -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#941126: stretch-pu: package dehydrated/0.6.2-2+deb9u1
On Sat, 2020-01-18 at 15:51 +0100, Mattia Rizzolo wrote: [...] > On Wed, Sep 25, 2019 at 10:59:58AM +0200, Mattia Rizzolo wrote: [...] > > From what I can see, the breakages would pretty much account to the > > following: > > * you need a new --accept-terms flag while creating a new account > >(might break autoamted deployments who need to create a new > > account?) > > * only since v0.6.0 the upstream developer made clear that users > > should not hardcode a list of hook, and it's known many users did > > it, so hook scripts may break due to unknown hook types > > * this also changes the default endpoint to ACMEv2. It should be > >totally transparent for most users, and those who really need > > ACMEv1 (why?) would need to explicitly specify it. > To this list I need to add that apparently the DNS verification might > break if the user used a single TXT record that the several > _acme_challenge.* CNAMEd to., as now dehydrated deployes all the > challenges in one go and then asks LE to check, instead of doing one > at a time. There is a simple workaround to this by using HOOK_CHAIN > plus a forgiving hook script. > > I still consider the above "breakages" totally acceptable, as we > really ought to welcome ACMEv2 in face of those 4 trivialities above. I'm aware that you both called them trivialities and quoted "breakages", but is it worth documenting any of them somewhere in the package? Regards, Adam
Processed: Re: Bug#941126: stretch-pu: package dehydrated/0.6.2-2+deb9u1
Processing control commands: > tag -1 -moreinfo Bug #941126 [release.debian.org] stretch-pu: package dehydrated/0.6.2-2+deb9u1 Removed tag(s) moreinfo. -- 941126: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=941126 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#941126: stretch-pu: package dehydrated/0.6.2-2+deb9u1
Control: tag -1 moreinfo On Wed, Sep 25, 2019 at 10:59:58AM +0200, Mattia Rizzolo wrote: > Package: release.debian.org > User: release.debian@packages.debian.org > Usertags: pu > Tags: stretch > > Hi SRM, > > It was brought to my attention that stretch's version of dehydrated has > a few issues. They could be resolved by adding a bunch of patches on > top of the current versions, but I'd like to propose to instead > backport the buster version as it is into stretch. > I think we need to fix #941414 first, regardless. As far as I can tell that has a straightforward fix. Cheers, Julien
Processed: Re: Bug#941126: stretch-pu: package dehydrated/0.6.2-2+deb9u1
Processing control commands: > tag -1 moreinfo Bug #941126 [release.debian.org] stretch-pu: package dehydrated/0.6.2-2+deb9u1 Ignoring request to alter tags of bug #941126 to the same tags previously set -- 941126: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=941126 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#941126: stretch-pu: package dehydrated/0.6.2-2+deb9u1
On Wed, Sep 25, 2019 at 10:59:58AM +0200, Mattia Rizzolo wrote: > From my side, the buster version is much more tested by me, as well as > somewhat "looked after" by the upstream developer (who, for example, > contacted me a few months ago to be sure it had a few patches). > > Updating the stretch version would also bring in a few features that > might be interesting for some users: > * ACMEv2 support (related, ISTR hearing LE wanted to retire ACMEv1 at >some point, so bringing in support for v2 into stretch earlier would >be a good idea) It seems that I've been living out of this world. So, LE will disable new registrations at ACMEv1 starting next month: https://community.letsencrypt.org/t/end-of-life-plan-for-acmev1/88430/2 AFAIK there is no plan to disable issueance of renewing certs, but still, that's a breakage that we should fix. Either way, I don't think there is a need to rush anything to stretch-updates, even leaving that broken till the December-ish .-r should be fine. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#941126: stretch-pu: package dehydrated/0.6.2-2+deb9u1
Package: release.debian.org User: release.debian@packages.debian.org Usertags: pu Tags: stretch Hi SRM, It was brought to my attention that stretch's version of dehydrated has a few issues. They could be resolved by adding a bunch of patches on top of the current versions, but I'd like to propose to instead backport the buster version as it is into stretch. From my side, the buster version is much more tested by me, as well as somewhat "looked after" by the upstream developer (who, for example, contacted me a few months ago to be sure it had a few patches). Updating the stretch version would also bring in a few features that might be interesting for some users: * ACMEv2 support (related, ISTR hearing LE wanted to retire ACMEv1 at some point, so bringing in support for v2 into stretch earlier would be a good idea) * a bunch of new hook types * support for OCSP From what I can see, the breakages would pretty much account to the following: * you need a new --accept-terms flag while creating a new account (might break autoamted deployments who need to create a new account?) * only since v0.6.0 the upstream developer made clear that users should not hardcode a list of hook, and it's known many users did it, so hook scripts may break due to unknown hook types * this also changes the default endpoint to ACMEv2. It should be totally transparent for most users, and those who really need ACMEv1 (why?) would need to explicitly specify it. IMHO, it would be best to just take the buster version as-is, without starting a whack-a-mole in backporting fixes, even if it would be somewhat trivial (the lack of ACMEv2 means many can be skipped), but they would have so many conflicts that missing bits and causing (also subtle… it's bash after all) bugs makes me prefer not to try it. If this route is accepted, I'd keep both stretch and buster updated at the same time, if case further changes are required in the future. What's your opinion? -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
