From Fedora Project Wiki

< Features
Revision as of 10:56, 6 March 2013 by Kengert (talk | contribs)

Done items:

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


TODO

  • ship new ca-certificates
    • must conflict with older p11-kit (new ca-cert needs new p11-kit)

Facts:

  • system-manage scripts cannot be in p11-kit, because of multilib.
  • system-manage scripts will be in ca-certificates.NOARCH

Decisions needed:

  • exact path for 2 input directories. proposal:
    • /usr/share/pki/ca-trust-intake/
    • /etc/pki/ca-trust/intake/
  • parent path for extracted output. proposal:
    • /etc/pki/ca-trust/toolkits/[openssl|gnutls]
  • exact path for extractex directories, proposal:

/etc/pki/ca-trust/toolkits/openssl/ /etc/pki/ca-trust/toolkits/openssl/tls-whitelist-bundle.pem /etc/pki/ca-trust/toolkits/openssl/email-whitelist-bundle.pem /etc/pki/ca-trust/toolkits/openssl/objsign-whitelist-bundle.pem /etc/pki/ca-trust/toolkits/openssl/trust-bundle.pem /etc/pki/ca-trust/toolkits/openssl/trusted-hashed/ /etc/pki/ca-trust/toolkits/gnutls/tls-whitelist-bundle.pem -> ../openssl/tls-whitelist-bundle.pem /etc/pki/ca-trust/toolkits/java/cacerts

  • for feature freeze:
    • java
    • gnutls == openssl classic bundle without trust
    • both openssl-directory and openssl-trust bundle?
  • name for recreate bundles script (must be simple command, no options)
    • shipped in ca-certificates
  • 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:

  • contains master mozilla bundle as trust bundle, not the old bundle
  • installs to a filename in /usr/share/
  • 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 "p11-kit extract" at install time (in %post script) to create sub-bundle at install time
  • must have re-generate command/script in ca-certificates before feature freeze
  • which tool/script defines the output directory?
    • ca-certificates generation script
    • same package contains READMEs (no PEM headers there)
    • use chmod -w for output dirs ? Make it work.
    • in Readme file, document that
      • files in intake directory without trust = TLS trust only
      • explains that all files inside here are automatically generated by "{tool}", manual changes are not allowed and will be overwritten
      • mention that NSS loads p11-kit-trust.so which directly reads "input"

Tasks for p11-kit:

  • must have Conflicts: nss < first-version-with-alternatives-symlink
  • must use update-alternatives in %post and %postun scripts, priority 30
  • currently uses only the non-trust file as input
  • must change p11-kit to use both /usr/share/ and /etc/ TRUST-BUNDLES by monday
  • implement prioritiies:
    • /usr low priority, /etc high priority
    • trust.so and extract tool ensure that higher priority trust setting wins
    • ca in low priority marked as untrusted in high priority will be excluded from plain no-trust bundles
  • fact (document?): p11-trust ignores all unknown files, ignores subdirs

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 / libnsssysinit.so get changed?
Retrieved from "https://fedoraproject.org/w/index.php?title=Features/SharedSystemCertificates:SubTasks&oldid=325305"