On Mon, 10 Oct 2016 13:16:23 -0400
Colin Walters <walters(a)verbum.org> 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(a)redhat.com> wrote:
> > 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
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; 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.