Comment 1 for bug 1893274

Hi Erica,

Thank you for looking after the certbot packages in Ubuntu and being proactive about managing service deprecations as always.

My feeling on this one is to cherry-pick the commit you identified only, if that is all that is required? Could you confirm which Ubuntu releases require this please? Is it all of 16.04, 18.04 and 20.04? Is the version in Ubuntu Groovy (1.7.0-1 currently, not yet released) affected?

I appreciate your preference to update our existing releases to 1.6.0+, especially considering your confidence in your own newer releases as opposed to cherry-picking that you have not tested. However I think the other side of the trade-off is in the complexity that you describe in the number of dependencies that would need to be updated or introduced. While we might have confidence that certbot 1.6.0+ when correctly presented with the necessary dependencies will work correctly, there's a risk that packaging will get it wrong and certbot don't correctly get that - for example in specific upgrade paths. This already happened to us in our first attempt to update certbot like this (that we realized and thus didn't release, but that did delay us). Also, distribution package consumers prefer stability in the "doesn't change behaviour" sense.

Given that historically we find it difficult to find volunteers to work on this, the triviality of this particular fix, and my points in the previous paragraph, I think we should focus on the cherry-pick.

If you could confirm the affected release list please, I (or someone else on my team) can drive the SRU process for this update based on a cherry-pick.

Going forwards, I suggest that the policy we adopt in making a decision on whether to update distribution certbot packaging in Ubuntu should be to prefer cherry-picks if they are reasonably simple to achieve, but permit major version updates when cherry-picks aren't practical to solve an "Internet deprecation". Users could then expect distribution certbot packaging to avoid changing behaviour when possible, but still change behaviour where that is required to keep it working. Users who specifically want to upgrade to newer certbot behaviour but remain on an old distribution release now have the option of using the snap.

What changed my opinion from before, when we set up the certbot exception, is that the complexity of the necessary changes to certbot needed to keep it working as Let's Encrypt and ACME have changed seem to me to have reduced considerably over time. I think this is a sign of maturity of the project. I think users expect the churn in stable distribution release packages to reduce accordingly. However I appreciate that we might yet need major changes in the future and so I don't rule out using the standing exception again should that become necessary.

What do you think?