Move the CA certificates list out of NSS into a separate repository

RESOLVED INCOMPLETE

Status

RESOLVED INCOMPLETE
2 years ago
2 years ago

People

(Reporter: kaie, Assigned: kaie)

Tracking

3.26
3.27

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(5 attachments)

(Assignee)

Description

2 years ago
I suggest to move the CA certificates list out of NSS into a separate repository.

It will allow consumers to use arbitrary combinations of the NSS library and the CA certificates list, without having to understand the internals of NSS.

In the past, in order to pick up code fixes for security reasons, we occassionally had to update the NSS code in a stable Firefox branch to a newer version of NSS. However, for various reasons, we didn't want to update the CAs on that branch to a newer snapshot.

As a workaround, we had to release additional NSS branch releases that contained the code fixes, but kept the CA list stable.

On other occassions, we wanted to backport a CA update to an older branch of Firefox, because it contained new blacklisted CAs, but didn't want to update the NSS code.

By separating NSS from the CA list, we will be able to declare release versions and release tags individually, and consumers, such as Firefox branches, can only update the part they need.

Another scenario are CA removals, which need to be postponed to a future date. Currently, those CA removals need to be landed early into a Firefox development branch, because changes to Firefox during the beta testing phase are discouraged. However, releasing them early as part of an NSS release, has the undesirable consequence, that consumers other than Firefox, who might be interested to run the most recent NSS code as soon as possible, can get the undesirable side effect of removing CAs too early, while they are still needed.

The split will give us the ability to handle those situations more flexibly.
(Assignee)

Updated

2 years ago
See Also: → bug 1290999
(Assignee)

Updated

2 years ago
Depends on: 1294016

Comment 1

2 years ago
I would like to register my strong opposition to this.

"Without having to understand the internals" of NSS should be a non-goal, as explained at https://wiki.mozilla.org/CA:FAQ#Can_I_use_Mozilla.27s_set_of_CA_certificates.3F

Further, the CA database is tightly coupled with implementation details of NSS. Implementation of constraints on particular CAs, for example, the whitelisting of some certificates (e.g. CNNIC), or other policies that may apply or be applied in the future.

The CA database is tightly coupled to NSS, in implementation and behaviour, and separating it out sends the wrong message to both NSS developers and potential consumers. While I'm sensitive to and appreciate the overhead that is involved with an NSS release, the issues it purports to solve will still exist in another form (e.g. the application of constraints), while the damage will be done.

Comment 2

2 years ago
On Bug 1294016, you position justification as the very thing that we SHOULD NOT do - which is mix versions of NSS and the CA certificate database. There was significant discussion when setting up https://wiki.mozilla.org/CA:FAQ#Can_I_use_Mozilla.27s_set_of_CA_certificates.3F about the risks that such decisions can pose. Judging from the empirical evidence of how distros are packaging NSS as well, I'm convinced this will make users less secure on Linux in particular, and have detrimental effects on the ecosystem as a whole.
(Assignee)

Comment 3

2 years ago
As of today, in order to build NSS, it's already required to retrieve source code from two separate repositories:
- https://hg.mozilla.org/projects/nspr
- https://hg.mozilla.org/projects/nss

The build environment assumes the following directory layout:

main-directory
|- nspr
|- nss

When built in the simple configuration, files in directory nss will access files from ../nspr

I'd like to suggest we add a new repo:
- https://hg.mozilla.org/projects/ca-certificates
which I've already requested in bug 1294016,

and suggest that we assume anyone building nss needs the following directory layout:

main-directory
|- nspr
|- ca-certificates
|- nss

and nss will directly access ../ca-certificates

Comment 4

2 years ago
Right, I'm aware of what your suggestion was, I'm stating that I believe it's bad for users and security to separate out the ca-certificates from NSS. Though I appreciate your comments in Comment #3 to suggest they'll still be a part of NSS, it's very clear from your Comment #1 and your Bug 1294016 that your larger justification is two anti-patterns:

1) Making it easier for non-NSS consumers to consume the database, when the decisions and policies are intrinsically tied to the behaviour of NSS/Firefox
2) Making it easier for NSS consumers to mix/match the database version, when we really want to ensure that the version being deployed by users is the current/secure set of roots, and we constantly see distros not taking ca-certificate updates unless they're part of an NSS security fix release.

The trade-off we're making here is whether it's better to cost the NSS maintainers - of which, I readily admit, you bear the brunt of this with relation to root cert updates every quarter - time in figuring out the exact sequence of landing, versus the ecosystem costs for both NSS and non-NSS consumers. From my experiences the past year with a variety of open-source and Google projects, I'm absolutely convinced that this proposal will make it more error prone and dangerous for consumers, and as such, we should bear the cost.
(Assignee)

Comment 5

2 years ago
Several distributions already package the ca-certificates list separately.

In order to simplify consumption of NSPR and NSS for those that don't, we already provide combined archives on the NSS source code distribution site, where we group an NSS release with the recommended NSPR release.

I suggest that we expand that. In the future, instead of shipping nss-with-nspr, I suggest we ship combined nss-with-ca-and-nspr archives, that bundles the version of CA list, which we recommended for major consumption at the time of the release of the respective NSS release.

Comment 6

2 years ago
Kai, I'm not sure why we're talking past each other, but it doesn't seem you're replying to my concerns, or perhaps you've misunderstood.

I'm aware that distros package the ca-certificates list separately. That's BAD. That's the anti-pattern. That's the thing that should not (generally) be done - https://wiki.mozilla.org/CA:FAQ#Can_I_use_Mozilla.27s_set_of_CA_certificates.3F

The rest of your Comment #5 seems to be replying to a separate concern, which is not the set I raised, so I don't feel as if responding to it would be useful.
(Assignee)

Comment 7

2 years ago
Correct, I haven't yet replied to Ryan's comments.
(Assignee)

Comment 8

2 years ago
I'd like to proceed with attaching and describing a potential implementation, because I have already worked on it.


Step 1:
Remove version numbers from nssckbi.h and replace them with symbols that
will be dynamically replaced at build time.

See part1-nssckbi.h.patch


Step 2:
Rename nssckbi.h to nssckbi.template


Step 3:
Embed version number information into the certdata.txt file

See part3-certdata.txt.patch


Step 4:
Because the intention is to move file certdata.txt to a separate repository,
a developer might want to decide to build NSS without it,
by explicitly defining symbol NSS_EMPTY_BUILTINS.

(For example, Fedora and RHEL offers a replacement library for libnssckbi.so, implemented using p11-kit-trust, which uses a different source, provided by the ca-certificates package, and extendable by the local system administrator. The NSS libnssckbi.so library is still shipped, but it's automatically obsoleted using the update-alternatives system, so having the module provided by NSS to be empty could be fine.)

To make that possible, a new file empty-certdata.txt is added to NSS.

See part4-empty-certdata.txt.patch


Step 5:
If certdata.txt is available, we want to dynamically extract the version
information, and combine it with nssckbi.template to create nssckbi.h

This requires to change the build rules in Makefile and manifest.mn.

Explanation for
  sed 's/^# *MOZILLA_CERTDATA_MAJOR_VERSION *\(.*\) *.*/s#CERTDATA_VERSION_MAJOR#\1#g/'

The first part searches for the version numbers.
The replacement text is a new sed command.
For that new sed command, I use '#' as the separator character, to avoid
having to escape /, which is hopefully easier to read.

See part5-makefile-manifest.patch


In addition to the individual patches, which are intended to simplify
review, I'm attaching a combined patch, which can be applied to NSS immediately.

It allows to test this new code.


Later - Step 6

When we are ready to move certdata.txt to the new separate
repository, we will adjust the published NSS build instructions,
and change Makefile again, to access certdata.txt from an external
parent directory (see the comment in the Makefile in part5).

When we land an updated NSS snapshot into the Firefox repository,
we will import a snapshot the the ca-certificates repo into the
Firefox repository, too.
(Assignee)

Comment 9

2 years ago
Created attachment 8779809 [details] [diff] [review]
part1-nssckbi.h.patch
(Assignee)

Comment 10

2 years ago
Created attachment 8779810 [details] [diff] [review]
part3-certdata.txt.patch
(Assignee)

Comment 11

2 years ago
Created attachment 8779811 [details] [diff] [review]
part4-empty-certdata.txt.patch
(Assignee)

Comment 12

2 years ago
Created attachment 8779812 [details] [diff] [review]
part5-makefile-manifest.patch
(Assignee)

Comment 13

2 years ago
Created attachment 8779814 [details] [diff] [review]
combined-steps-1-to-5.patch

This patch combines all the individual steps I've described in my previous comment.

It already contains preparations for step 6,
which would replace
 NSS_CERTDATA_TXT = certdata.txt
with
 NSS_CERTDATA_TXT = $(CORE_DEPTH)/../ca-certificates/certdata.txt
in the Makefile.
Assignee: nobody → kaie
(Assignee)

Comment 14

2 years ago
With the attached potential implementation, consumers who download NSS without any ca-certificates library, will fail to get a build. They will either need to get the ca-certificates and install them in the correct place for building, or they must define symbol NSS_EMPTY_BUILTINS. Note I've haven't yet tested the use of NSS_EMPTY_BUILTINS, that's a todo, should we decide to proceed with this approach.

Comment 15

2 years ago
Let's discuss this in the NSS call tomorrow.  Thanks.
(Assignee)

Comment 16

2 years ago
(In reply to Ryan Sleevi from comment #1)
> Further, the CA database is tightly coupled with implementation details of
> NSS. Implementation of constraints on particular CAs, for example, the
> whitelisting of some certificates (e.g. CNNIC), or other policies that may
> apply or be applied in the future.

I cannot find any mention of the string CNNIC inside NSS, except in certdata.txt

Are you referring to certverifier/CNNICHashWhitelist.inc ?
That's outside of NSS, and in Firefox application code.

Comment 17

2 years ago
(In reply to Kai Engert (:kaie) from comment #16)
> (In reply to Ryan Sleevi from comment #1)
> > Further, the CA database is tightly coupled with implementation details of
> > NSS. Implementation of constraints on particular CAs, for example, the
> > whitelisting of some certificates (e.g. CNNIC), or other policies that may
> > apply or be applied in the future.
> 
> I cannot find any mention of the string CNNIC inside NSS, except in
> certdata.txt
> 
> Are you referring to certverifier/CNNICHashWhitelist.inc ?
> That's outside of NSS, and in Firefox application code.

I'm not entirely sure the point you're trying to make, but it may have been that mine was not as clear as it could have been, so I'm sorry for that.

The point I was making is that the decision to trust some CAs - such as CNNIC or ANSSI - is entirely dependent upon what the application code supports, generally NSS, but specifically, Firefox. That is, one should not simply examine certdata.txt (as many distros and maintainers were and are doing) to determine if CA X is trustworthy, but look at how the applications (NSS and Firefox) actually behave.

Which is the point: The decisions in nssckbi are based upon what the NSS code supports and, now that Mozilla has moved more out into mozilla::pkix/PSM, what Firefox supports. You should not separate the two, and if you do, you should be aware of that coupling.

The proposal to split these out is, in part, intentionally motivated by a desire to remove the above statement. But that's not desirable. Cert Version Y is making implicit and explicit decisions based on what the (bundled) version of Firefox & NSS are going to do. So you can't just assume version Y will work with old-Firefox or old-NSS, or afford the same security. Similarly, Cert Version X (the older version) will generally be 'less secure' than Cert Version Y - there will be CAs that shouldn't still be in still trusted, or there won't be new CAs needed for transitions. So you wouldn't want to mix Cert Version X with new-NSS or new-Firefox.

That is, your explicit stated goal - allowing ca-certificates (implicitly, nssckbi) - to be independently versioned from Firefox/NSS - is a thing specifically advised against because it creates security and interoperability issues. I realize Red Hat has taken a different perspective of this security stance (e.g. including unaudited 1024-bit certificates because you were using them with not-NSS, particularly OpenSSL, and they didn't support the audited 2048-bit paths), but I'm arguing that's damage that should be kept localized to Red Hat. That was also reflected in the previous decision - which was that Red Hat would add those 1024-bit certs back, rather than having upstream do it (as was requested).

Further, while Red Hat may be adept and capable of ensuring a relative synchronicity in the versions (although historically we know this not to be true), many other bundlers are not, which is why the FAQ was added to begin with, to try to mitigate the harm. The proposal - to split out the CA certificates - is to add legitimacy to the perception that the certificates are independently maintainable, rather than a core and inseparable part of NSS (now, Firefox).

These decisions affect not just the direct NSS developers, but affect how the project is perceived, used, and consumed, and we have ample evidence that going down the path suggested causes developers to make poor or suboptimal solutions.
(Assignee)

Comment 18

2 years ago
(In reply to Ryan Sleevi from comment #17)
> > I cannot find any mention of the string CNNIC inside NSS, except in
> > certdata.txt
> > 
> > Are you referring to certverifier/CNNICHashWhitelist.inc ?
> > That's outside of NSS, and in Firefox application code.
> 
> I'm not entirely sure the point you're trying to make

My point is:

You have earlier argued (I'm trying to summarize in my own words) that:
- splitting NSS and the CA list is a bad idea
- it's a bad idea, because the CA list logically belongs to constraints that
  have been implemented in code, and shouldn't be separated

The above made sense, if as of today, both logic and CA were indeed tightly coupled to each other.

But apparently they aren't. Apparently the Firefox application developers have already made the (IMHO unfortunate) decision to move required logic into application code, instead of adding it at the more general NSS library level.

So, given that NSS+CA-Certificates are already being distributed independently of the related code in Firefox, it seems to me that the strictly bundled state, which you're trying to conserve, is already nonexistent?

If the strict coupling is already nonexistent, I'm not convinced that conserving strict coupling can be used as an argument against the proposed split.

The NSS team would continue to make recommendations which combinations of NSS library and CA list are recommended, by demonstrating which combinations are being used on Firefox release branches, and by making announcements on appropriate announcement channels, and by publishing combined source archives.

Comment 19

2 years ago
While Red Hat does not preserve the strict state, Mozilla does. So it seems you're arguing that because Red Hat breaks this bundling, it's OK for others to do so as well?
(Assignee)

Comment 20

2 years ago
(In reply to Ryan Sleevi from comment #19)
> While Red Hat does not preserve the strict state, Mozilla does.

Mozilla does already publish the CA list plus the NSS code as separately downloadable software, that excludes the Firefox code, that you argue is required for handling the CA list correctly.
(Assignee)

Comment 21

2 years ago
Resolving this as incomplete for now, as based on discussions, it's currently unclear if this will be done.
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.