Re: Shared System Certificates followup: Packaging Guidelines?
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 01/08/2014 12:05 PM, Kai Engert wrote:
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).
Probably this needs to go to FESCo/FPC, but what about
package-specific CAs? For example, I have a pattern I was thinking
about adding to the tog-pegasus that causes it to do the following:
1. Create an x509v3 certificate and key with the CA extension
2. Create a new service certificate for tog-pegasus locally
3. Sign it with the CA certificate.
4. Store the public CA certificate in the system's trust store.
5. Destroy the private key so that it cannot be used to sign other
certificates.
(The effect here being that a user on the local system can connect to
an SSL socket on localhost without being challenged or having to
ignore the verification)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlLNi7cACgkQeiVVYja6o6ONEQCgqbx04Ws+HaFHJ6PDZfv+c6ea
tv4AoKW8RfCOCWGI01n88kb0KwjhRaJh
=37EY
-----END PGP SIGNATURE-----