On Mi, 2013-12-11 at 09:59 -0800, Toshio Kuratomi wrote: > Last night someone asked me about a package that they were working on that > had a pem file in it. Looking closer, it seems that the pem file is > a cacert bundle. Looking around, there's not currently documentation on > what to do with these. I did find some information on the wiki, though: > > https://fedoraproject.org/wiki/PackagingDrafts/Certificates > https://fedoraproject.org/wiki/Features/SharedSystemCertificates > https://fedoraproject.org/wiki/Talk:Features/SharedSystemCertificates > > I'm by no means an expert in this area but my impression is that the > PackagingDraft is made obsolete by the Shared System Certificates Feature. > As Killerix and Misc note on the talk page we should probably have some > packaging guidelines added that tell us what the expectations are. > > The Guideline should answer the following questions: > > * Should packages that ship their own cacerts be patched to use Shared > System Certificates instead? [I think the answer to this is yes] Packages, that would like to use a default list of CA certificates, should be changed to use (consume) the new consolidated data that we provide as part of SharedSystemCertificates. Fedora packages that need to trust additional, application specific CA(s) should install them into a different, applicaton specific location, and implement loading of those additional trust anchors in their application code. Fedora packages other than the ca-certificates.rpm shouldn't install into the global trusted locations (unless the Fedora decision makes decide otherwise). The reason is, installating additional CAs has the side effect that all other applications on the system will trust that CA, too. (For example, if a game application requires a CA to connect to a game network, that CA shouldn't be trusted for certifying the identities of web sites when surfing using Firefox etc. For that, we want only CAs that have been vetted according to the rules of the Mozilla CA Certificate Policy). Besides Fedora packages, there might be deployment specific packages. If a closed user group, for example the members of an organization, would like to trust a CA operated by that organization, and make it easy to add that CA for the members, the organization could create a package that places an additional CA certificate (or bundle file) into our global locations. Such an RPM package shouldn't qualify for inclusion in Fedora's standard repositories, but it should be made available for download from a separate location. Another category might be community operated CAs, like the one operated by http://cacert.org which hasn't been able yet to fulfil the requirements for inclusion in the Mozilla CA list (but which has some popularity in the free software and free information world). Someone could make an RPM package that installs their root certificate into Fedora's global trust location. I personally would argue, such packages shouldn't be included in Fedora's repositories either, as another package could easily pull it in with an dependency, and users might install it without noticing the impact of installing it. > * If the package contains a cacert that is not in our bundle, should those > be added? We shouldn't do that. If any CA would like to get included as a globally trusted third party, it should follow the rules outlined at http://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ and we'd eventually include them as part of the regular updates to that list maintained by Mozilla. > * How does a package add a cacert to our existing bundle? If it's a global Fedora package, it shouldn't. If it's a non-Fedora package, outside of Fedora's repositories, targetted for a closed user group, where people deliberately choose to trust those CAs, the package can install additional files into the /etc/pki/ca-trust/ or /usr/share/pki/ca-trust-source/ as explained in the manual page that you get with $ man update-ca-trust Regards Kai -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
