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