On Mon, 10 Oct 2016 13:16:23 -0400 Colin Walters <walters@xxxxxxxxxx> wrote: > On Mon, Oct 10, 2016, at 01:04 PM, Kevin Fenzi wrote: > > On Mon, 10 Oct 2016 16:57:25 +0000 > > Patrick Uiterwijk <puiterwijk@xxxxxxxxxx> wrote: > > > > ...snip... > > > > > As far as I know, yum/dnf supports setting a cafile for repos, so > > > we can just update fedora-repos. > > > > That doesn't help. If we are using a well known cert, it's already > > valid based on the system ca's, and IMHO it would be very poor to > > use a self signed cert for this. So, either librepo carries a > > static list for our base repos or we add support for HPKP. > > I would s/static list/custom root CA set/. > > It's worth emphasizing that having a custom CA root set is > a very standard thing to do - we're basically just doing > exactly what ca-certificates does, just with a different > configuration. > > And it's supported today by both librepo and ostree, and many > HTTP libraries in general. And both of those code paths are used > today for Red Hat Enterprise Linux Atomic Host, talking > to the default Akamai CDN. > > HPKP is (as far as I know) mostly a browser thing[1]; it isn't > implemented by libcurl for example. Though it does > make sense for general outside-of-the-browser use cases, > from an operating system perspective, we already have > a mechanism to ship the configuration out-of-band to > client systems by embedding it into the installation media > and the update stream. The same as we do for GPG. > > Basically, I think it's easiest if we think of the keys/configuration > for CA-pinning the same as GPG. But does that not mean anyone going to the same place with a browser or command line downloading specific packages will get a "sorry, this cert is not trusted" ? Thats not such a big deal for ostree's, but for rpms, people do this all the time. kevin
Attachment:
pgpOIOK3nx8b4.pgp
Description: OpenPGP digital signature
_______________________________________________ infrastructure mailing list -- infrastructure@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to infrastructure-leave@xxxxxxxxxxxxxxxxxxxxxxx
