#
357082 |
|
24-Jan-2020 |
kevans |
MFC r352948-r352951, r353002, r353066, r353070: caroot infrastructure
Infrastructure only -- no plans in place currently to commit any certs to these branches.
r352948: [1/3] Initial infrastructure for SSL root bundle in base
This setup will add the trusted certificates from the Mozilla NSS bundle to base.
This commit includes: - CAROOT option to opt out of installation of certs - mtree amendments for final destinations - infrastructure to fetch/update certs, along with instructions
A follow-up commit will add a certctl(8) utility to give the user control over trust specifics. Another follow-up commit will actually commit the initial result of updatecerts.
This work was done primarily by allanjude@, with minor contributions by myself.
r352949: [2/3] Add certctl(8)
This is a simple utility to hash all trusted on the system into /etc/ssl/certs. It also allows the user to blacklist certificates they do not trust.
This work was done primarily by allanjude@, with minor contributions by myself.
r352950: [3/3] etcupdate and mergemaster support for certctl
This commit add support for certctl in mergemaster and etcupdate. Both will either rehash or prompt for rehash as new certificates are trusted/blacklisted.
This work was done primarily by allanjude@, with minor contributions by myself.
r352951: caroot: add @generated tags to extracted .pem
As is the current trend; while these files are manually curated, they are still generated. If they end up in a review, it would be helpful to also take the hint and hide them.
r353002: Unbreak etcupdate(8) and mergemaster(8) after r352950
r352950 introduced improper case fall-through for shell scripts. Fix it with a pipe.
r353066: certctl(8): realpath the file before creating the symlink
Otherwise we end up creating broken relative symlinks in /etc/ssl/blacklisted.
r353070: certctl(8): let one blacklist based on hashed filenames
It seems reasonable to allow, for instance:
$ certctl list # reviews output -- ah, yeah, I don't trust that one $ certctl blacklist ce5e74ef.0 $ certctl rehash
We can unambiguously determine what cert "ce5e74ef.0" refers to, and we've described it to them in `certctl list` output -- I see little sense in forcing another level of filesystem inspection to determien what cert file this physically corresponds to.
Relnotes: yes |
#
352948 |
|
02-Oct-2019 |
kevans |
[1/3] Initial infrastructure for SSL root bundle in base
This setup will add the trusted certificates from the Mozilla NSS bundle to base.
This commit includes: - CAROOT option to opt out of installation of certs - mtree amendments for final destinations - infrastructure to fetch/update certs, along with instructions
A follow-up commit will add a certctl(8) utility to give the user control over trust specifics. Another follow-up commit will actually commit the initial result of updatecerts.
This work was done primarily by allanjude@, with minor contributions by myself.
No objection from: secteam Relnotes: yes Differential Revision: https://reviews.freebsd.org/D16856
|