Package shipping their own CA and security

Miloslav Trmač mitr at volny.cz
Fri Feb 8 15:54:51 UTC 2013


Hello,
On Fri, Feb 8, 2013 at 12:41 PM, Michael Scherer <misc at zarb.org> wrote:
> That's where it start to be funny and security related, because the
> whole certificate authority idea requires update to be kept secure ( for
> exemple, when a CA was compromised, like DigiNotar, Trustwave ). And
> that's something we may not really watch.

There's also the system administration impact - an application that
ships its own CA bundle will not be affected by admin's changes to
https://fedoraproject.org/wiki/Features/SharedSystemCertificates .


> - ban all certificates if used to validate something.
I think this is too strict; there may be legitimate cases of
service-specific CAs; there even are projects that use the X.509
certificate format for something completely unrelated to the global CA
universe.  Requiring an exception or an independent review may be
fine.

> - list all problematic packages on a wiki.
Well, not necessarily a wiki, but a list of all potentially
problematic packages, and eventually an analysis of them, would make a
potential policy decision much easier (and would make it more likely
that the chosen policy will be the right one).

> We cannot automate that test, since private key and certificates are
> often used in tests suite. And as long as this is just used for testing
> purpose, the certificate should be ok.
Wouldn't this be handled by only checking the binary packages, and
allowing private keys/certificates in SRPMs?  Shipping test suites is
usually not that valuable (... speaking as an owner of a package that
does ship a test suite :)  It will be dropped soon).

 If people want to look at
> affected packages, there is
> # yum whatprovides '*pem'
That's quite a few :(  Don't forget about other formats - .der, .p12
at least; possibly also the native NSS and Java formats.
    Mirek


More information about the devel mailing list