Hello, On Fri, Feb 8, 2013 at 12:41 PM, Michael Scherer <misc@xxxxxxxx> 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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
