From Fedora Project Wiki

Done items:

  • prepare NSS for alternatives links (Bug 915818). See nss-3.14.3-9.rpm
  • ship p11-kit with trust module


  • system-manage scripts cannot be in p11-kit, because of multilib.
  • system-manage scripts will be in ca-certificates.NOARCH
  • p11-kit* has binaries and the generic extract tool
  • ca-certificates has
    • the root trust bundle
    • all the knowledge which bundle files to install
    • migration logic (backup old config-file bundles)
    • symbloci links, install triggered scripts
    • knowledge into which filenames extracted trust output will be stored
    • a wrapper script update-ca-trust for manual execution
    • README files

Decisions needed:

  • exact path for 2 input directories. proposal:
    • /usr/share/pki/ca-trust-source/
    • /etc/pki/ca-trust/source/
  • parent path for extracted output. proposal:
    • /etc/pki/ca-trust/extracted/[openssl|gnutls|java]
  • exact path for extracted directories, and new filenames for generated/extracted files:


  • symbolic links from existing filenames to new files:
  -> /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem

  -> /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem

  -> /etc/pki/ca-trust/extracted/openssl/
  • for feature freeze must be done:
    • java
    • gnutls == openssl classic bundle without trust
    • only file based trust bundle
    • openssl hashed directory: no
  • script to recreate (extract) output bundles (simple command, no options):
    • update-ca-trust
    • shipped with ca-certificates
    • calls "p11-kit extract" multiple times as needed, once for each format
    • for now, update-ca-trust will be statically configured to extract the output files we need
  • for this fedora feature, we provide the new files, but what about making it the default for new apps?
    • feature freeze says, new stuff must be used by default
    • but this job should be done, by providing the new files using the old filenames

Independent decisions:

  • OpenSSL: makes own decision which bundle/dir to use by default

Tasks for ca-certificates package:

  • must conflict with older p11-kit (new ca-cert needs new p11-kit)
  • contains master mozilla bundle as a "trust file format bundle", not the "plain old cert bundle without trust"
  • installs to a filename in /usr/share/pki/ca-trust-source/
  • requires p11-kit
  • use alternatives for symbolic links? NO
  • installs symlinks to generated files
  • makes backups of old bundles in .rpmsave backup files (in %pre script)
  • calls "update-ca-trust" at install time (in %post script) to create sub-bundle at install time
  • which tool/script defines the output directory?
    • update-ca-trust generation script
    • same package contains READMEs (no PEM headers there)
    • use chmod -w for output dirs ? Make it work. See:
    • in Readme file, document that
      • files placed into source directory without trust = will be treated with TLS trust only
      • explain that all files inside here are automatically generated by "{tool}", manual changes are not allowed and will be overwritten
      • mention that NSS loads which directly reads "input"
      • mention that other crypto toolkits should be converted to use, too

Tasks for p11-kit:

  • split into p11-kit (old parts) and p11-kit-trust (only the module)
  • must have Conflicts: nss < first-version-with-alternatives-symlink
  • must use update-alternatives in %post and %postun scripts, priority 30
  • it currently uses only the non-trust file as input. should be changed to use both /usr/share/pki/ca-trust-source/ and /etc/pki/ca-trust/source/ directories by monday
  • implement priorities:
  • fact (document?): p11-trust ignores all unknown files, ignores subdirs. See:

Testing required:

  • later: does NSS mechanism to override the p11-module trust still work? See Firefox edit trust.
  • test that gnutls can use new bundle file
  • test tha openssl can use new trust bundle file
  • test that openssl can use new hash directory
  • test that java can use generated java bundle file

Possible future feature, postponed, management tool:

  • use a new p11-root tool with actions INSTALL, UPDATE, REMOVE <nickname-for-cert-or-bundle> which copies from any source file into the INPUT directory, using the nickname as a filename, does sanity checking of nickname and possibly sanity checking of the input (optionally add input sanity checks later), and runs the tool to update the generated output. A new package install would do: install regular file anywhere, in %post script, run p11-root INSTALL. On upgrade, run p11-root UPDATE. On removal of a package, run p11-root REMOVE. p11-root INSTALL would abort (with error code) if a file with the given nickname is already installed. This prevents accidental overwriting when intending to add something separate from existing roots.
  • This approach allows us to have automatic actions that are required on top of installing. In addition, have a p11-root RESCAN command, that will simply update the generated output, without copiying or removing files from the input directory. This can be used if a user chooses to simply copy a file manually to the input directory? Running RESCAN is curently necessary to immediately update the output. This teaches people that copying into the directory isn't sufficient. We could document in p11-root that we reserve the right to later disallow manual copying and make RESCAN obsolete, and might require the use of INSTALL/UPDATE at a later time.

Postponed, later:

  • make /etc/pki/nssdb obsolete
  • change other tools that currently install roots into /etc/pki/nssdb. research first: are there any?
  • must nss-sysinit / get changed?