Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

update policy #9

Open
benoitc opened this issue Sep 10, 2015 · 5 comments
Open

update policy #9

benoitc opened this issue Sep 10, 2015 · 5 comments

Comments

@benoitc
Copy link
Collaborator

benoitc commented Sep 10, 2015

There is no clear description on how the certificate bundle are currently built and the update cycle of it.
Imo we should define the following:

  • explain how the bundle is built (which certificates are used)
  • describe when the bundle is refreshed.

There is a running discussion on erlang/rebar3#789 about these topics. Answering to them would expand the adoption of certifi.

@Lukasa
Copy link
Member

Lukasa commented Sep 11, 2015

Yeah, we can elaborate on process a bit. I'll be honest, before recently the process around here wasn't always followed perfectly because of a lack of resources, but now that I'm full-time on Python HTTP projects certifi's state of affairs should get a bit better.

The high-level features are:

  • cert bundles are generated by curling https://mkcert.org/generate/. That service is basically a web-server wrapper around the extract-nss-certs tool that Adam Langley wrote with some extra goodness that certifi itself doesn't use at this time. It has the advantage, however, of always being up to date.

Beyond that, we get notified using a tool called certifi-prompt, which was a very quick script that dumps an OS X desktop notification onto my laptop when a difference is detected between the output of mkcert and the bundle in certifi. Generally this works pretty well.

The goal is to refresh the bundle fairly swiftly after Mozilla changes it. That doesn't always happen, but it usually does, and we're getting better all the time.

@benoitc
Copy link
Collaborator Author

benoitc commented Sep 16, 2015

OK, thanks for the information :)

I am working on a script that regenerate automatically the erlang bundle. However I wonder if we couldn't generalize that to all projects as a policy. Or at least regenerating the website to tell which package is outdated. Thoughts?

@Lukasa
Copy link
Member

Lukasa commented Sep 16, 2015

@benoitc It generalises pretty easily. The really stupid one I wrote for Python is here: https://github.com/certifi/certifi-prompt. Its principle is basically to do a diff of the file produced by mkcert.org and the one in the master of the bundle. That works great for most of them, but is a bit tricky for Go: though if we have a policy that we always update Go in step with Python that problem mostly goes away.

It would be helpful if each project had essentially a Makefile that would apply a new update correctly: that way, admins can easily update all projects if needed.

@benoitc
Copy link
Collaborator Author

benoitc commented Sep 16, 2015

@Lukasa this is what I did in erlang-certifi: https://github.com/certifi/erlang-certifi/blob/master/Makefile

Running the Makefile will regenerate the source.

@Lukasa
Copy link
Member

Lukasa commented Sep 16, 2015

@benoitc That looks reasonable to me. =) I'll work on having a better notification service put in place (the most general I can think of at this time is email, which is less than ideal, but might work).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants