On Thu, Aug 18, 2022 at 1:45 PM Yann Droneaud <ydroneaud@xxxxxxxxxx> wrote: > I've noticed ca-certificates package was updated recently, and went looking > at the changes, and I have some questions. Not Bob Relyea, but I'll try to answer to the best of my knowledge: > The first issue is what certdata.txt was used ? It's supposed to be > downloaded from Mozilla NSS sources, but doesn't match any released > versions. 3.79, as suggested by both the changelog entries and https://src.fedoraproject.org/rpms/ca-certificates/blob/rawhide/f/nssckbi.h matching https://hg.mozilla.org/projects/nss/raw-file/NSS_3_79_RTM/lib/ckfw/builtins/nssckbi.h > The second issue is what are the changes that were made to certdata.txt ? > The commit messages and RPM changelogs say the root CA certificate database > was updated thrice to the same version. > > Below the 3 latest updates to certdata.txt used to build the root CA > certificates database in ca-certificates RPM package for Fedora Rawhide > from ca-certificates git repository > ... > As you can find, the last 3 ca-certificate's certdata.txt version match > *no* NSS's certdata.txt which is suspicious. > > In https://fedoraproject.org/wiki/CA-Certificates it is said, that since > Fedora 25, there's no modification on the upstream root certificates > database. So what happened here ? > > Unfortunately, the ca-certificates' commit messages nor the RPM's changelog > provide any reason for the differences. > > This raise the question of the trust we can have in the update, if the > certdata.txt supposedly imported from Mozilla NSS, doesn't match any file > released by Mozilla. Indeed it doesn't. If you diff it against Mozilla's https://hg.mozilla.org/projects/nss/log/NSS_3_79_RTM/lib/ckfw/builtins/certdata.txt you should observe significant differences of two varieties: 1. -CKA_TRUST_CODE_SIGNING CK_TRUST CKT_NSS_MUST_VERIFY_TRUST +CKA_TRUST_CODE_SIGNING CK_TRUST CKT_NSS_TRUSTED_DELEGATOR on some of the Mozilla-originating certificates 2. half of the file consisting of newly added certificates with a comment # Microsoft Code Signing Only Certificate trusted for code signing alone. diff -U0 upstream-3.79.txt certdata-fedora.txt | grep CKA_TRUST | sort -u +CKA_TRUST_CODE_SIGNING CK_TRUST CKT_NSS_TRUSTED_DELEGATOR +CKA_TRUST_EMAIL_PROTECTION CK_TRUST CKT_NSS_MUST_VERIFY_TRUST +CKA_TRUST_SERVER_AUTH CK_TRUST CKT_NSS_MUST_VERIFY_TRUST +CKA_TRUST_STEP_UP_APPROVED CK_BBOOL CK_FALSE -CKA_TRUST_CODE_SIGNING CK_TRUST CKT_NSS_MUST_VERIFY_TRUST Thus, for purposes other than code signing we have effectively Mozilla's 3.79 version. For code signing, we additionally trust an extra set of certificates, including ones not coming from Mozilla. The rather detailed description in https://bugzilla.redhat.com/show_bug.cgi?id=2117793 suggests that this is an unfortunately non-transparent stop-gap solution of sorts to satisfy .NET code signing needs while a better approach is in the works. > Commit messages (and RPM changelog) should details the changes made to the > NSS's certdata.txt during the update. And, for the sake of traceability, the > repository, branch, tag, hg commit, from which certdata.txt was pulled > should > also be part of the commit message (and RPM changelog). (and an empty line > between commit title and the rest of the commit message would be > appreciated, > for git log --oneline usage). That'd be great. > It should also be noted the fetch.sh script (most notably check_certs.sh) is > doing a terrible job at reporting the changes, most notably saying already > present certificates are added. I'd also like to suggest separating Mozilla and Microsoft-originating certdata in the repository and only mixing them together as part of the build process, if need be. _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
