Formed in 2009, the Archive Team (not to be confused with the archive.org Archive-It Team) is a rogue archivist collective dedicated to saving copies of rapidly dying or deleted websites for the sake of history and digital heritage. The group is 100% composed of volunteers and interested parties, and has expanded into a large amount of related projects for saving online and digital history.
In conjunction with Sectigo; design doc here: https://docs.google.com/document/d/16qxEe7FqhBgsHqpYf7zc_xpyMQw5VNZlmxxijJQok2E/edit?usp=sharing
Work related to cleaning up and better defining Certbot's interfaces in preparation for Certbot 1.0.
Mitigate crypto shortcuts
How can we improve Certbot's behavior based on the recommendations in https://jhalderm.com/pub/papers/forward-secrecy-imc16.pdf?
Pieces of the terminal revamp project, and issues that would be solved if Certbot had better concepts to communicate what's going on with certificates and their management.
Terminal revamp design doc here: https://docs.google.com/document/d/1aKnQYEzCrZgYX-iuE-ErOdIKERUuLmZSX_BDb7d0M6I/edit?usp=sharing
Everything I've ever read about properly handling strings in Python says that you should use Unicode throughout your program and then convert them to/from the correct external encoding at the edges of your program. This means decoding input from a user, file, or network and converting it to Unicode as soon as possible and conversely encoding output right before it is sent. I've heard this described as the "Unicode sandwich". To do this, you should use unicode/str in Python 2 and 3 respectively throughout your program and convert to str/bytes respectively before output. six.text_type and six.binary_type help with this.
I don't think we currently do this correctly in Certbot. For example, see #4273. If someone is aware of a better way to handle text encoding, I'm open to other suggestions, but AFAIK this is the best way to do things. We should look through our code and make sure we a have a Unicode sandwich, correcting code as necessary.