Certbot 0.14.0 Release

Certbot 0.14.0 has just been released. Changes in this release are:

Added

  • Python 3.3+ support for all Certbot packages. certbot-auto still currently only supports Python 2, but the acme, certbot, certbot-apache, and certbot-nginx packages on PyPI now fully support Python 2.6, 2.7, and 3.3+.
  • Certbot’s Apache plugin now handles multiple virtual hosts per file.
  • Lockfiles to prevent multiple versions of Certbot running simultaneously.

Changed

  • When converting an HTTP virtual host to HTTPS in Apache, Certbot only copies the virtual host rather than the entire contents of the file it’s contained in.
  • The Nginx plugin now includes SSL/TLS directives in a separate file located in Certbot’s configuration directory rather than copying the contents of the file into every modified server block.

Fixed

  • Ensure logging is configured before parts of Certbot attempt to log any messages.
  • Support for the --quiet flag in certbot-auto.
  • Reverted a change made in a previous release to make the acme and certbot packages always depend on argparse. This dependency is conditional again on the user’s Python version.
  • Small bugs in the Nginx plugin such as properly handling empty server blocks and setting server_names_hash_bucket_size during challenges.

As always, a more complete list of changes can be found on GitHub: https://github.com/certbot/certbot/issues?q=is%3Aissue+milestone%3A0.14.0+is%3Aclosed

4 Likes

nice - should make for a better time for everyone

any chance of having a parameter to not use lock files. FCNTL work on linux only meaning running it on windows creates issues

Andrei

Instead of that, I think we’d like to see a patch to certbot/lock.py to make the code work on Windows. A number of other projects like fasteners and portalocker have done similar work before, but their projects didn’t quite work for us because they didn’t securely delete the lockfile. Ideally we’d like to see this property on Windows too, but getting locking at all on Windows is a higher priority.

would a if (linux) use linuxlocks() not be a better approach for now so windows based systems are no affected?

I am observing the way that certbot features are written is a linux first and only approach.

I would like to see a change in approach. Hey this is a linux only method so when we write this lets think about how we do this and account for non linux system.

This is a problem throughout certbot. I have even written a powershell script to remove the linux features however the new locks is very hard to work around (having to go through a lot of code) https://github.com/ahaw021/CERTBOT-WINDOWS-BUILD

  • os.geteuid method
  • using os.rename vs os.replace for expand
  • the current locks issue
  • augeas parsing of apache files
  • openssl detection for certificate checking

I am sure there are other methods which throw issues i just haven’t used them

if the ultimate aim is to make certbot cross system capable (python is cross os capable) then the code needs to be written in a way to support this

i would be more than happy to contribute and test windows methods and function but currently this is not possible

for example:

write files method is a true cross system codebase would have something like.

if(os==linux)
use writeFilesOnLinux() method

if(os==windows)
use writeFilesOnWindows() method

This would let me to write code to account for windows and fix it without impacting linux based systems

I have asked for this previously: Certbot - Better Handling of Folder Creation for Windows
Just my 5 cents

Andrei

Unless that code was followed by:

else:
    windowslocks()

I don't think we'd accept something like that ourselves. You're of course welcome to do whatever you want and put code like that into your fork of Certbot, but the purpose of these locks is to prevent race conditions that can cause files to become corrupted if two instances of Certbot run at once. Rather than writing code that just silently leaves Windows users open to this possibility, I'd rather the official project continue to not work on Windows until we can provide these users a safe and reasonable experience.

As for Certbot's approach to Windows support, Certbot is developed by only a few paid developers with much of our support coming from the open source community in their spare time. Due to our limited resources, it is unlikely we will have the time to (re)write solutions to be Windows compatible ourselves in the near future when there are already a number of other unresolved issues with Certbot on the platform with no progress being made on resolving them in our official repository.

With that said, we'd certainly be open and excited about pull requests from the community to make Certbot Windows compatible as long as it doesn't break compatibility with anything else we support as I expressed in Running Certbot on Windows - Phase 1 - #16 by ahaw021. In fact, after our previous conversation my coworkers and I talked excitedly about the possibility of someone being able and interested in doing the work to make Certbot Window compatible. If Certbot worked on Windows and we could set up some sort of automated Windows integration testing so we can be aware of potential problems, we'd certainly not break our Windows support, but we're unlikely to be able to do the work to get it to that point ourselves any time soon.

I'm sorry I missed both Certbot - Better Handling of Folder Creation for Windows and os.Rename() Causing Issues on Windows · Issue #4510 · certbot/certbot · GitHub. In general, Certbot's GitHub page is a better place for discussions of Certbot's code. On GitHub, I usually manage Certbot's PR queue while others respond to issues unless someone mentions me directly. Feel free to mention me with @bmw on GitHub if you'd like my response to something and if you're still interested in doing this work I look forward to seeing PRs from you soon!

makes sense

and i completely agree about not breaking anything in the process

my intention is try to introduce windows components slowly but i expected the initial PR will be quite substantial so will need to wait a bit longer until i have time to dedicate full time to it :smiley:

exciting times ahead

For what it’s worth, it’s probably a good idea to send multiple smaller PRs rather than one large one as it makes things easier to review, they’ll land faster, and if we have any review comments it saves you a lot of work redoing things, but exciting times ahead indeed!

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.