On Wed, Oct 12, 2016, at 03:17 PM, Kevin Fenzi wrote:
> Sure, but they won't. They will complain that we have an invalid cert
> and we will need to explain to them whats going on. ;)
I still think this would be mostly covered if the yum repo files
and the ostree remote config had a comment like:
# This URL is ca-pinned, see https://fedoraproject.org/wiki/CAPinning
> Instead of shipping a fedora-ca that you verify against, why not do
> what chrom*/firefox do and have a hardcoded list of hashes that must be
> in the cert?
The Chrome and Firefox implementations seem different - Firefox
hashes the certs, but Chrome seems to have a CA whitelist, which
is actually a lot easier to read.
Anyways, there's a higher level question here - you're arguing
for pinning to Digicert rather than a custom CA. That seems good
enough, but I think we need a recovery mechanism in case Digicert
So I'd propose pinning to a 3 set of CAs:
- Some other well-regarded CA vendor
- A Fedora-infra custom CA (doesn't have to be deployed, just a backup plan)
And as for a specific implementation mechanism, we'd have just
those CAs in /etc/pki/tls/certs/fedora-infra.crt or so, and that file
would be in the fedora-repos package. The argument for this again
is that librepo and ostree already have all of the code for this, and so does
Doing the hashes of the certs like Firefox does is certainly possible,
but it requires custom logic in the HTTP layer, and there's no
standard configuration file formats for the data, etc.
> Also in the same file chom*/firefox set a list of sites to assume ssl,
> which would also be nice to hard code.
Yeah, we could follow up with this adding Fedora sites to the browser
lists. Chrome's version seems saner to me.
infrastructure mailing list -- firstname.lastname@example.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org