I'm using trust anchor foo.crt/trust anchor --remove foo.crt as root to temporarily add the CA my company uses to my system-wide trust store. However, this stopped working with p11-kit-0.23.2-3.fc25 / p11-kit-0.23.5-1.fc26 , trust anchor succeeds, but then trust anchor --remove tells me it cannot remove from a read-only store (forgot the exact wording but started with "couldn't remove read-only XXX"). I downgraded to p11-kit-0.23.2-2.fc24 and trust anchor --remove worked fine with it.
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
Thank you for the report. This was caused by this commit: https://github.com/p11-glue/p11-kit/commit/8eed1e60b0921d05872e2f43eee9088cef038d7e The original issue addressed by the commit was that, after the input format change of ca-certificate[1], all the built-in certificates had CKA_MODIFIABLE(true). The commit restricted the behavior by checking "modifiable" flag set in the file, but it was apparently too generic and caused unwanted effect. Given that all the built-in certificates have CKA_NSS_MOZILLA_CA_POLICY attribute, I guess a more conservative fix would be to check "nss-mozilla-ca-policy": https://github.com/p11-glue/p11-kit/pull/66
Kai, since you reported the original issue, could you double check if this follow-up change is okay?
I'll work on it soon
It seems that with your patch, you want to allow to remove an anchor that has attribute "modifiable: false". Is my understanding correct? Was attribute "modifable: false" set when the anchor was added using the "trust anchor" command? If yes, isn't that the real bug? If "trust anchor" installs a file, which is allowed to be removed later, I think "trust anchor" should set "modifable: true"? (I don't know the full internals of p11-kit-trust, so I cannot say if this makes sense. I don't know for which purposes p11-kit-trust uses the modifiable attribute.) Regarding the original bug I had reported: When I started to use the MOZILLA_POLICY_CA flag, I had switched from the BEGIN TRUSTED CERTIFICATE file format to the p11-kit file format. I had used the "trust dump" command to compare the state with the old and new file formats. I saw that the old file format produced "modifiable: false", and that the dump with the new format always produced "modifiable: true", even if the new p11-kit input format specified "modifiable: false". I didn't have a specific requirement for "modifiable: false". I had simply intended to be as identical as possible to the old state when using the new file format, for completeness. After this new information, do you still want to use the same patch, or do you want to check if the behavior of trust anchor should be changed, to set "modifiable: true"?
(In reply to Kai Engert (:kaie) from comment #5) > If "trust anchor" installs a file, which is allowed to be removed later, I > think "trust anchor" should set "modifable: true"? That would be ideal, but in reality it would be a backward incompatible change, because the "trust anchor" command has never done that and "trust anchor --remove" would only be able to remove anchors installed by the newer "trust anchor" command.
I see, that's unfortunate. I just made a test, without your patch, but I changed the p11-kit file installed by ca-certificate into the /usr/share/pki/ca-trust-source directory to say "modifiable: true" for a CA, I copied the certificate data to a PEM file, and executed "trust anchor --remove" on that file. This had the effect that the file in /usr/share/pki/ca-trust-source was modified and the CA was removed. This surprised me. I wasn't aware that the "trust" command can be used to have that effect. (This would also happen with your patch, for CAs that don't have the policy CA flag.) I think we shouldn't assume that all files installed by the ca-certificates.rpm will contain the policy-ca attribute. Distrusted certificates might not have it. Mozilla has also occassionally added neutral certificates to the trust bundle, to help with trust chain detection, without giving them any positive trust flags. Those don't qualify to have the mozilla_ca_policy attribute. Some deployments could have their own RPM package, that installs a set of local CAs into the /usr/share/pki/ca-trust-source directory. Such files will not contain the MOZILLA_POLICY_CA attribute. If an administrator runs a command to distrust a CA that is stored in /usr, that change will be silently overwritten the next time a CA RPM is updated. I think it isn't ideal to use that flag to conclude "cannot be modified", because it might not cover everything that is installed in /usr. I think the trust command shouldn't modify any files in /usr/ because /usr shouldn't contain local configuration. (And it may be even read only on some systems, if /usr lives on read-only storage.) When adding new files, it seems the trust command always adds these files to the /etc/pki/ca-trust/source directory. I conclude this means, that the trust command is already able to distinguish between the /etc and /usr directories, and knows that the /etc directory is the place to add local configuration. My suggestion is, the trust command should: - never modify anything that is installed below /usr - allow to modify anything that is installed in /etc regardless of attributes. You could argue, it would be again a backwards incompatible change, if we change trust to never modify /usr. But in my opinion it was a bug that it ever allowed to do that.
Thank you for the suggestion. That sounds like a better approach indeed. I have updated the pull-request along those lines.
I came up with a new idea: From the start, the trust module adds a line to the generated .p11-kit files: # This file has been auto-generated and written by p11-kit. We can use this as a magic comment to determine whether the objects read from a .p11-kit file are read only. This approach shouldn't break backward compatibility and still allow the certificates installed by the ca-certificates package to be read-only. I have filed a new PR: https://github.com/p11-glue/p11-kit/pull/70
If a file contains the line # This file has been auto-generated and written by p11-kit. do you suggest this file is "read-only" or is it "read-write" ?
(In reply to Kai Engert (:kaie) from comment #10) > If a file contains the line > # This file has been auto-generated and written by p11-kit. > > do you suggest this file is "read-only" or is it "read-write" ? I mean "read-write", so no change to the current ca-certificate package is necessary.
p11-kit-0.23.5-2.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-6d3abc84f6
As a consequence, does that mean, files without that line are read-only? If files without that line are read-only, how can the "trust" command remove the files that were installed with past versions?
(In reply to Kai Engert (:kaie) from comment #13) > As a consequence, does that mean, files without that line are read-only? Yes. > If files without that line are read-only, how can the "trust" command remove > the files that were installed with past versions? All files written by the trust command should have that line even for the past versions, because the change which added the write capability to the "trust" command also had a logic to produce this comment: https://github.com/p11-glue/p11-kit/commit/a2165fe35e336fd807af053a21a396b020f90a23
(In reply to Daiki Ueno from comment #14) > All files written by the trust command should have that line even for the > past versions, because the change which added the write capability to the > "trust" command also had a logic to produce this comment: Ok, this wasn't clear to me previously, thanks for the clarification!
p11-kit-0.23.5-3.fc26 has been pushed to the Fedora 26 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-6d3abc84f6
p11-kit-0.23.2-4.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2017-11fb7450f4
p11-kit-0.23.2-4.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2017-c54e3353b6
p11-kit-0.23.2-4.fc24 has been pushed to the Fedora 24 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-c54e3353b6
p11-kit-0.23.2-4.fc25 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-11fb7450f4
p11-kit-0.23.2-4.fc25 has been pushed to the Fedora 25 stable repository. If problems still persist, please make note of it in this bug report.
p11-kit-0.23.5-3.fc26 has been pushed to the Fedora 26 stable repository. If problems still persist, please make note of it in this bug report.
p11-kit-0.23.2-4.fc24 has been pushed to the Fedora 24 stable repository. If problems still persist, please make note of it in this bug report.