Closed woodruffw closed 4 months ago
Looks like these changes have been merged upstream, so we should check to see whether the production or staging instances have deployed them. If so, we should follow suit.
This changes have been fully deployed, so we should begin supporting them.
I did some quick tests in https://github.com/jku/sigstore-python/commit/50418201b5ade7ddaa7dc2fdd9e86a7bccf04b42:
_SingleX509ExtPolicy
support "alternative oids": I like this option, it's likely the least amount of workpolicy
module completely (all policies are just _SingleX509ExtPolicy
with a specific OID). Instead put the complexity in "verify github" codeGitHubWorkflowName
no longer exists: it probably should never have been used anyway since it has no real claim value -- it's not unique at all and SAN already contains the workflow path. We may want to expose Build Signer Digest
as policy instead (?) and the CLI could use "sha" argument as default value for thatBuild Signer URI
-- should the cli use the cert identity argument there too?FWIW, I also have an initial stab at this up at #715: it keeps the old extension handling in place while adding new APIs for the new extensions. My thinking was that backwards compatibility could be maintained by using the AnyOf
building block to compose the old and new extensions.
(More generally, using these new extensions is blocked by the fact that they contain DER encodings for their values, which pyca/cryptography doesn't support for arbitrary third-party extensions yet. That's being tracked here: https://github.com/pyca/cryptography/issues/9283.)
FWIW, I also have an initial stab at this up at #715: it keeps the old extension handling in place while adding new APIs for the new extensions. My thinking was that backwards compatibility could be maintained by using the
AnyOf
building block to compose the old and new extensions.
Yeah this works but does lead to a lot of classes (e.g. GitHubWorkflowTrigger(_SingleX509ExtPolicy)
, _BuildTrigger(_SingleX509ExtPolicy)
, BuildTrigger(Anyof)
). Supporting "deprecations" in _SingleX509ExtPolicy makes that more manageable since you could just have BuildTrigger(_SingleX509ExtPolicy)
-- this is with the assumption that API stability of the policy module is not that important, but supporting old certificates is very important (which is my intuition). But either solution definitely works.
(More generally, using these new extensions is blocked by the fact that they contain DER encodings for their values, which pyca/cryptography doesn't support for arbitrary third-party extensions yet.
ooh, good to know
After reading up on the situation in cryptography:
this is with the assumption that API stability of the policy module is not that important, but supporting old certificates is very important (which is my intuition)
Yeah, this is a fair point. IMO it'd be okay to break the API here between major versions if we think the resulting code will be smaller (especially since the migration path will be smooth).
it looks like this should not block a sigstore-python release as solving this will likely take some time?
Yes, agreed -- I have this as a 2.0 milestone ATM but I don't think it should block at 2.0 release of sigstore-python (since the legacy extensions continue to work just fine). We can move it to 3.0, I think.
is this going to be a scheduling issue: what's the plan if fulcio does start thinking about a 2.0 release and the cryptography DER API is not close to being implemented:
DER crimes with pyasn1
is an option, but not one I find appealing 😅
Short of a full declarative ASN.1 API in Python becoming available, I can think of two other options:
OCTET STRING
wrappers).Regardless I think we have options available to us, so we won't need to ask Fulcio to prolong its support for the deprecated extensions 🙂
Dropped this from 2.0, per #766.
Just filing this for tracking purposes: https://github.com/sigstore/fulcio/pull/945 will change Fulcio's certificate extensions to make them more generic, avoiding unnecessary references to implementation details for e.g. GitHub.
These changes will follow Fulcio's deprecation policy, so no action is immediately required on our part.