Open wojtekmach opened 3 years ago
Is this going to become a problem with Root CA file expiring at the end of the month since we can't pass hackney options down?
Is this going to become a problem with Root CA file expiring at the end of the month since we can't pass hackney options down?
Should not be an issue, for two reasons:
ssl
options are being passed to Hackney, it will use its defaults which (at least with recent Hackney versions) will verify the server cert correctly before and after the DST Root CA cert expiresssl
should have no problem connecting to it in any case, regardless of OTP version or the client usedThanks @wojtekmach Option 2 sounds good, because it doesn't depend on any other packages.
:public_key.verify/4
This would replace the system call to gpg
right?
Re: @voltone
Since no ssl options are being passed to Hackney, it will use its defaults which (at least with recent Hackney versions) will verify the server cert correctly before and after the DST Root CA cert expires
Sorry, maybe I'm missing something. Isn't the purpose is to use httpc
and not depend on Hackney though? So there won't be any Hackney?
If we use option 2, we could theoretically even use http
(without the s), since we would rely on the GPG signature to verify the downloaded file, correct?
:public_key.verify/4
This would replace the system call to gpg right?
Yeah, that's the idea. But I'm not sure if it is possible, I hope it is.
Sorry, maybe I'm missing something. Isn't the purpose is to use
httpc
and not depend on Hackney though? So there won't be any Hackney?
Right, but I interpreted the question as referring to the current situation, which relies on server certificate verification. I suppose @bryannaegele wanted to know whether current applications might stop fetching tzdata updates as a result of the DST Root CA expiry.
If we use option 2, we could theoretically even use
http
(without the s), since we would rely on the GPG signature to verify the downloaded file, correct?
There is some value in using HTTPS even without the certificate verification. For one thing, the IANA repository might one day stop serving data over plain HTTP altogether. But yes, using HTTP would be possible.
Yeah, that's the idea. But I'm not sure if it is possible, I hope it is.
It should be possible in theory, but :public_key
does not support PGP/GPG signatures, so it would require an implementation of RFC4880. I am not aware of a package that implements that, and doing that inside the Tzdata package might be a bit of a stretch...
RE RFC4880, got it, thanks Bram.
In that case, I believe the next best thing is to use httpc with secure options and castore or certifi, I think many users will appreciate tzdata bringing just one extra dep.
See also this that I just wrote about alerting about new versions and then requiring data updates via hex packages: https://github.com/lau/tzdata/issues/127 Comments appreciated.
Yes. My only concern was if the CA expiry was going to prevent downloading.
As you approach this issue, please also consider corporate environments in which TLS interception is active, as described in hexpm/hex#727. Something analogous to HEX_CACERTS_PATH
for injecting an additional valid certificate would be helpful. 🙂
Also keep in mind that since OTP 25 there is support for native OS CA certificates that httpc can use and don't need the extra dependency
We need Hackney to make sure that tzdata we're downloading and unpacking has not been tampered with. However, hackney brings many transient dependencies and for that reason I believe it is not the best choice, it would be great to depend on as least deps as possible.
I think we have two options:
Option 1: httpc +
castore
. EEF Security WG has a nice guide how to give httpc secure settings. I think this will be pretty simple to implement and already be a big improvement.Option 2: httpc + manually checking tzdata signature.
This would be similar to how
mix local.hex
works, it fetches https://repo.hex.pm/installs/hex-1.x.csv and https://repo.hex.pm/installs/hex-1.x.csv.signed and checks if it wasn't tampered with against Hex public key that is included in Elixir.Turns out tzdata releases are signed with GPG using Paul Eggert's public key. If we include the key in
tzdata
and verify against that, we wouldn't even needcastore
which I think would be a small win.I have a proof of concept:
the next step is to use
:public_key.verify/4
but not sure how to transform the arguments appropriately so it accepts them.Maybe @voltone could help with that :)