Comment 0 for bug 1640978
Revision history for this message
| Peter Eckersley (pde-lists) wrote letsencrypt 0.4.1 contains numerous bugs fixed upstream | #0 |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
73416ba
(Get the code!)
This bug contains a list of known major and other issues fixed between upstream letsencrypt 0.4.1 and the latest version, certbot 0.9.3 (the project has also been renamed to avoid confusion between the python client software and the Let's Encrypt CA service).
[Impact]
MAJOR BUGS FIXED
https:/
letsencrypt < 0.5.0 was not compatible with future configuration files, so users who run certbot-auto then downgrade to the Xenial packages will encounter errors.
https:/
Failure to remember choices of authenticator plugins for renewal operation. This would essentially make "letsencrypt renew" useless on Xenial. Numerous less severe automated renewal-related bugs fixed in subsequent releases:
https:/
https:/
https:/
https:/
https:/
https:/
Failure to handle IPv6 Virtual hosts in Apache configurations
https:/
Erroneous behaviour with Apache configs that have multiple vhosts in a single file (these are still not supported for cert installation in 0.9.3, but at least produce clear error messages)
https:/
Incompatibility with the specified version of the ACME protocol, preventing the Let's Encrypt serverside code from following it correctly
https:/
Failure to parse Plesk's apache config files
https:/
Apache plugin errors out when transformations to a configuration turn out to be a no-op.
https:/
Incorrect handling of RewriteCond directives when trying to avoid Apache inifinite redirect loops
https:/
Problems running Apache renewal in cron due to cron's default PATH
UX: fail to re-ask for email address if the first one seems invalid:
https:/
UX: when re-running is a NOOP (due to renewal not being needed yet), print an explanation:
https:/
OTHER BUGS FIXED
Reduce the risk of incorrect or corrupt state in case of control-C interrupts:
https:/
Failure to correctly parse certain rewrite directives in Apache configs:
https:/
Failure to correctly enable HTTP -> HTTPS redirects in some Apache configs:
https:/
Failure to provide a sensible error if the user requests a Unicode domain:
(support for those is being added in 0.10.0)
https:/
Directory deletion permission errors are fatal when using the webroot plugin for non-root users (but shouldn't be):
https:/
UX: provide helpful guidance for people who want to run Certbot as a non-root user:
https:/
SIGNIFICANT NEW FEATURES WARRANTING AN SRU:
Support --quiet / -q
https:/
User interface for requesting certificates for multiple domain names with the
webroot plugin:
https:/
Support for DNS based authentication:
https:/
[Test Case]
All or almost all of the pull requests for the bugs above include unit test coverage.
Some also include integration or compatibility test coverage.
[Regression Potential]
The Certbot team has viewed breakage of existing workflows (especially ones that may be automated) as a serious issue, has strived to avoid them, and has treated workflow changes as regressions where it has occurred.
We have the following test suites in place for Certbot:
* Nosetest unit tests with coverage for each module between 97% and 100%; *test.py in the relevant tree.
* Integration tests that run Certbot against the current copy of Let's Encrypt's serverside boulder codebase. These require docker and are a little more involved to run. See tests/boulder_
* "Compatibility tests" that run the Apache and Nginx plugins against corpora of configuration files for those webservers; these live in certbot-
* Test farm tests, which we use to check that our releases run correctly on a wide range of platforms. These spin up Amazon EC2 instances for numerous OSes and run various tests on them. They live in tests/letstest
We recommend that Ubuntu run the first of these test suites during build (but we believe the Debian packages already do that).
All of these tests mitigate the risk of regressions in our releases; nonetheless, some regressions do slip past. Because many of our users auto-update, these tend to be reported and fixed quickly in point releases. For instance, regressions in 0.9.0 were fixed in 0.9.1, 0.9.2 and 0.9.3. Certbot 0.9.3 has been used to issue hundreds of thousands of Certs in the field, so we are fairly confident that no further significant regressions exist in it, and that release is likely to be safe as a Xenial SRU.
At least two changes in functionality between 0.4.1 and 0.9.3 do bear specific consideration for Xenial though:
Debian has added a "certbot renew" twice-daily cron job to their packages between 0.4.1 and 0.9.3; we believe this is low regression risk (having secondary renewal mechanisms in place is a NOOP) but Xenial packages may want to increase the debconf verbosity to get consent for this from Xenial users who are upgrading?
We had a custom log rotation scheme (rotate logs after every run), we now act like a more typical daemon, so packages need to be rotating our logs:
https:/
[Other Info]
RAOF has offered to sponsor 0.9.3 into Xenial.