Bug 1006034 - stapling of an extension in p11-kit-trust (sometimes) doesn't work - Heisenbug?
stapling of an extension in p11-kit-trust (sometimes) doesn't work - Heisenbug?
Product: Fedora
Classification: Fedora
Component: p11-kit (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Stef Walter
Fedora Extras Quality Assurance
Depends On:
Blocks: 1007812
  Show dependency treegraph
Reported: 2013-09-09 16:03 EDT by Kai Engert (:kaie)
Modified: 2013-11-03 00:33 EDT (History)
4 users (show)

See Also:
Fixed In Version: p11-kit-0.18.7-1.fc19
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1007812 (view as bug list)
Last Closed: 2013-11-03 00:33:05 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Test case for bug where stapled extensions don't apply (2.84 KB, patch)
2013-09-13 06:26 EDT, Stef Walter
no flags Details | Diff

External Trackers
Tracker ID Priority Status Summary Last Updated
FreeDesktop.org 69314 None None None Never

  None (edit)
Description Kai Engert (:kaie) 2013-09-09 16:03:25 EDT
I spent a few hours testing bug 989013, bug was constantly puzzled by behaviour. Related background information can be found in that bug 989013 comment 11.

I *sometimes* was able to reproduce the following, but then again, I couldn't.

- use a fully updated f19 system (which includes p11-kit 0.18.5)
- however, use the older ca-certificates package 
  which contains the older Entrust 2048 root (the one lacking basic constraints)
  and which requires the stapled attributes found in
  to be accepted by p11-kit-trust as a valid cert.

During one period of time, evolution + firefox listed the certificate as absent, indicating that stapling isn't working.

(I'm worried this unreliable stapling might also cause the distrust stapling to not be effective.)

But then, after experimenting a lot, suddenly evolution + firefox showed the certificate. And even after I edited the ca-bundle.supplement.p11-kit file and removed the stapling section for the entrust root, the entrust 2048 root was still shown and listed as trusted.

I fully agree what I saw doesn't make sense, and I wish I could present more consistent test results, but right now I can't.

Bug 989013 is evidence that we do have an incorrect behaviour. People should have never seen the old Entrust root as untrusted, because we always shipped those stapling bits, and the newer ca-certificates (which was shipped just a few days ago) doesn't need the stapling bits.

I had a hard time reproducing bug 989013 in the beginning, then I suddenly was able to reproduce. While trying to upgrade/downgrade packages and reset configurations, even restoring earlier non-reproducing configurations, I still saw the bug. And then suddenly I couldn't reproduce the bug any more, regardless of installed versions and configuration.
Comment 1 Stef Walter 2013-09-13 06:17:57 EDT
Sounds bad. Investigating.

(In reply to Kai Engert (:kaie) from comment #0)
> (I'm worried this unreliable stapling might also cause the distrust stapling
> to not be effective.)

For what it's worth, we don't use stapling to do distrust in Fedora 19 ca-certificates. So there's likely less cause for worry.
Comment 2 Stef Walter 2013-09-13 06:26:06 EDT
Created attachment 797260 [details]
Test case for bug where stapled extensions don't apply

Seems to happen if loaded after certificate.
Comment 3 Stef Walter 2013-09-13 06:27:32 EDT
Can reproduce. This is a race condition. The attached patch makes the tests fail.

The problem is where the certificate is loaded before the stapled certificate extension. We have code to account for loading both ways, however it seems to be broken.
Comment 4 Stef Walter 2013-09-13 06:29:17 EDT
Test case failure, when above patch is applied.


There was 1 failure:
1) test_build_certificate_staple_ca_backwards: test-builder.c:470: attribute does not match: expected { CKA_CERTIFICATE_CATEGORY = 2 (authority) } but found { CKA_CERTIFICATE_CATEGORY = 3 (other-entry) }

Runs: 31 Passes: 30 Fails: 1

FAIL: test-builder
Comment 5 Stef Walter 2013-09-13 07:28:18 EDT
Patch upstream.
Comment 6 Stef Walter 2013-09-13 07:44:13 EDT
Scratch build with the upstream patch.

Comment 7 Stef Walter 2013-10-10 00:40:20 EDT
Kai, have you had a chance to test this patch?
Comment 8 Fedora Update System 2013-10-14 08:44:37 EDT
p11-kit-0.18.7-1.fc19 has been submitted as an update for Fedora 19.
Comment 9 Kai Engert (:kaie) 2013-10-15 16:09:24 EDT
(In reply to Stef Walter from comment #7)
> Kai, have you had a chance to test this patch?

No, given how painful it was to test this issue, and how intermittent it was, I'd prefer if you could come up with a good testing strategy.
Comment 10 Stef Walter 2013-10-15 16:10:58 EDT
Understood ... We have an upstream test case for this. So I've pushed this an an update to fix the issue. As you noted, it should be rare to run into this, given it's intermitancy and the fact that we now have a better Entrust Root CA cert.
Comment 11 Fedora Update System 2013-10-18 15:36:04 EDT
Package p11-kit-0.18.7-1.fc19:
* should fix your issue,
* was pushed to the Fedora 19 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing p11-kit-0.18.7-1.fc19'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).
Comment 12 Fedora Update System 2013-11-03 00:33:05 EDT
p11-kit-0.18.7-1.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.