NO-JIRA: Add ECDSA P-256 support for certificates and CAs by fabiendupont · Pull Request #2116 · openshift/library-go

fabiendupont · 2026-02-04T17:25:08Z

Extends the crypto package to generate ECDSA P-256 key pairs and certificates in addition to existing RSA support, enabling OpenShift components to use modern elliptic curve cryptography.

Changes

Key generation:

KeyAlgorithm type for algorithm selection (AlgorithmRSA, AlgorithmECDSA)
ECDSA P-256 key pair generation with proper SubjectKeyIdentifier hashing (SHA-1 per RFC 5280)
newKeyPairWithAlgorithm() for unified key generation dispatch

Server certificates:

CA.MakeServerCertWithAlgorithm() and CA.MakeServerCertForDurationWithAlgorithm()

CA certificates:

MakeSelfSignedCAConfigForDurationWithAlgorithm() for ECDSA root CAs
MakeCAConfigForDurationWithAlgorithm() for ECDSA intermediate CAs

Template cleanup:

Removed hardcoded SignatureAlgorithm: x509.SHA256WithRSA from certificate templates
x509.CreateCertificate infers the correct algorithm from the signing key (SHA256WithRSA for RSA, ECDSAWithSHA256 for ECDSA P-256)
This is backward compatible and enables correct cross-algorithm signing (e.g. RSA CA signing ECDSA leaf certs)

All existing APIs remain unchanged — new functionality is opt-in through *WithAlgorithm variants.

Test coverage

Key generation, signature algorithm detection, and ECDSA PEM encoding
Server certs: RSA CA + ECDSA leaf, ECDSA CA + RSA leaf, ECDSA CA + ECDSA leaf
MakeServerCertForDurationWithAlgorithm (production code path from certrotation/target.go)
Self-signed ECDSA CAs and mixed-algorithm intermediate CA chains
Backwards compatibility: all existing RSA tests pass unchanged

openshift-ci-robot · 2026-02-04T17:25:12Z

@fabiendupont: This pull request explicitly references no jira issue.

Details

In response to this:

Extends the crypto package to generate ECDSA P-256 key pairs in addition to existing RSA support, enabling OpenShift components to use modern elliptic curve cryptography.

Adds:

KeyAlgorithm type for algorithm selection (RSA, ECDSA)

newECDSAKeyPair() and newECDSAKeyPairWithHash() functions using P-256 curve

newKeyPairWithAlgorithm() for unified key generation

signatureAlgorithmForKey() for automatic algorithm detection

CA.MakeServerCertWithAlgorithm() and CA.MakeServerCertForDurationWithAlgorithm()

All existing APIs remain unchanged, preserving 100% backwards compatibility. New functionality is opt-in through *WithAlgorithm functions.

ECDSA P-256 provides equivalent security to 3072-bit RSA with smaller keys (~87% smaller), faster operations, and better performance. This prepares OpenShift for modern TLS deployments and aligns with industry best practices.

Test coverage includes:

Unit tests for key generation, signature algorithm detection, and encoding

Integration tests for RSA CA + ECDSA server and vice versa

Backwards compatibility tests verifying existing RSA functionality

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

Adds support for generating ECDSA P-256 certificates by specifying the key algorithm via the new service annotation: service.beta.openshift.io/serving-cert-key-algorithm: ecdsa When the annotation is not specified or set to "rsa", the operator generates RSA certificates for full backwards compatibility. This enables services to opt into modern elliptic curve cryptography, which provides equivalent security to 3072-bit RSA with significantly smaller keys (~87% smaller) and better performance. Implementation: - Added ServingCertKeyAlgorithmAnnotation constant in api.go - Modified MakeServingCert() to check annotation and select algorithm - Uses library-go's new MakeServerCertWithAlgorithm() API - Validates annotation values (rsa, ecdsa) with helpful error messages - Case-insensitive algorithm matching Testing: - Added TestECDSACertificateGeneration with 5 test cases - Verifies RSA (default and explicit), ECDSA, and invalid inputs - All existing tests pass with no regressions Depends on: openshift/library-go#2116 Co-authored-by: Claude Sonnet 4.5 <noreply@anthropic.com> Signed-off-by: Fabien Dupont <fdupont@redhat.com>

p0lyn0mial · 2026-02-11T14:08:28Z

pkg/crypto/crypto.go

 }

+// MakeServerCertWithAlgorithm creates a server certificate with the specified key algorithm
+func (ca *CA) MakeServerCertWithAlgorithm(hostnames sets.Set[string], lifetime time.Duration, algorithm KeyAlgorithm, fns ...CertificateExtensionFunc) (*TLSCertificateConfig, error) {


Hmm, I might be wrong, but it looks like MakeServerCert and MakeServerCertWithAlgorithm are very similar. There are two differences. The first is the key algorithm, and the second is that MakeServerCertWithAlgorithm sets the signature algorithm.

I’m wondering if it would make sense to create a private common function for both. I think something like the following could work:

func (ca *CA) MakeServerCertWithAlgorithm(hostnames sets.Set[string], lifetime time.Duration, algorithm KeyAlgorithm, fns ...CertificateExtensionFunc) (*TLSCertificateConfig, error) { sigFn := func(template *x509.Certificate) error { template.SignatureAlgorithm = signatureAlgorithmForKey(ca.Config.Key) return nil } fns = append([]CertificateExtensionFunc{sigFn}, fns...) return ca.makeServerCertWithAlgorithm(hostnames, lifetime, algorithm, fns...) }

and

func (ca *CA) MakeServerCert(hostnames sets.Set[string], lifetime time.Duration, fns ...CertificateExtensionFunc) (*TLSCertificateConfig, error) { return ca.makeServerCertWithAlgorithm(hostnames, lifetime, AlgorithmRSA, fns...) }

p0lyn0mial · 2026-02-11T14:13:07Z

pkg/crypto/crypto.go

+	case AlgorithmRSA:
+		return newKeyPairWithHash()
+	default:
+		return newKeyPairWithHash() // Default to RSA for backwards compatibility


Since this is a private method I think we could return an error for unsupported algorithms.

p0lyn0mial · 2026-02-11T14:17:42Z

pkg/crypto/crypto.go

+}
+
+// MakeServerCertForDurationWithAlgorithm creates a server certificate with specified duration and algorithm
+func (ca *CA) MakeServerCertForDurationWithAlgorithm(hostnames sets.Set[string], lifetime time.Duration, algorithm KeyAlgorithm, fns ...CertificateExtensionFunc) (*TLSCertificateConfig, error) {


am I right that the differences between MakeServerCertForDuration and MakeServerCertForDurationWithAlgorithm mirror those between MakeServerCert and MakeServerCertWithAlgorithm (key algorithm and signature algorithm)? If so, could we refactor them in the same way?

Good feedback. Makes sense.

fabiendupont · 2026-02-13T14:51:50Z

@p0lyn0mial, I extended the changes to add the ECDSA CA support as well, so we can have a full ECDSA chain.

pkg/crypto/crypto.go

p0lyn0mial · 2026-02-16T08:57:00Z

pkg/crypto/crypto.go

 	template := &x509.Certificate{
 		Subject: subject,

-		SignatureAlgorithm: x509.SHA256WithRSA,


OK. I think that the SignatureAlgorithm will be set by x509.CreateCertificate and our unit tests assert this. Is that correct ?

Yes, that's correct. When SignatureAlgorithm is zero-valued in the template, x509.CreateCertificate infers it from the signing key — SHA256WithRSA for RSA keys, ECDSAWithSHA256 for ECDSA P-256 keys. Our tests assert the resulting SignatureAlgorithm on the generated certs for all combinations (RSA CA + RSA leaf, RSA CA + ECDSA leaf, ECDSA CA + RSA leaf, ECDSA CA + ECDSA leaf).

p0lyn0mial · 2026-02-16T09:02:09Z

pkg/crypto/crypto.go

+	case AlgorithmRSA:
+		return newKeyPairWithHash()
+	default:
+		return nil, nil, nil, fmt.Errorf("unsupported key algorithm: %d", algo)


It looks like the error message will take the form of unsupported key algorithm: 2, which isn't meaningful to someone debugging. Is there a way to make it more descriptive ?

Good point. This default branch can only be reached if a new KeyAlgorithm constant is added to the const block (e.g. AlgorithmEd25519) without adding a corresponding case in this switch.

Since newKeyPairWithAlgorithm is private and the callers always pass one of the defined constants, a developer hitting this error would know they forgot to wire up their new algorithm.

I added a comment to clarify that, and kept %d so the numeric value is visible for debugging.

pkg/crypto/crypto.go

p0lyn0mial · 2026-02-19T08:45:37Z

pkg/crypto/crypto.go

+	return makeSelfSignedCAConfigForSubjectAndDuration(subject, time.Now, caLifetime, AlgorithmRSA)
+}
+
+func MakeSelfSignedCAConfigForDurationWithAlgorithm(name string, caLifetime time.Duration, algorithm KeyAlgorithm) (*TLSCertificateConfig, error) {


I might be wrong but
MakeSelfSignedCAConfigForDurationWithAlgorithm & MakeCAConfigForDurationWithAlgorithm use newSigningCertificateTemplateForDuration which sets

KeyUsage: x509.KeyUsageKeyEncipherment | x509.KeyUsageDigitalSignature | x509.KeyUsageCertSign,

I found RFC 5480 where Section 3 says:

If the keyUsage extension is present in a Certification Authority (CA) certificate that indicates id-ecPublicKey in SubjectPublicKeyInfo, then any combination of the following values MAY be present: digitalSignature; nonRepudiation; keyAgreement; keyCertSign; and cRLSign.

which tells me that x509.KeyUsageKeyEncipherment (in newSigningCertificateTemplateForDuration) should not be used for ECDSA only for RSA.

Added a keyUsageForAlgorithm helper that returns:

RSA: KeyEncipherment | DigitalSignature

ECDSA: DigitalSignature only

Per RFC 5480 Section 3, KeyEncipherment is not valid for ECDSA keys. The CA, server, and intermediate cert templates now receive the algorithm and set KeyUsage accordingly. Tests assert the correct KeyUsage for both RSA and ECDSA certs.

The public client cert template functions (NewClientCertificateTemplate / NewClientCertificateTemplateForDuration) are unchanged since client cert creation currently always uses RSA.

p0lyn0mial · 2026-02-19T08:47:27Z

pkg/crypto/crypto.go

+}
+
+// MakeServerCertWithAlgorithm creates a server certificate with the specified key algorithm
+func (ca *CA) MakeServerCertWithAlgorithm(hostnames sets.Set[string], lifetime time.Duration, algorithm KeyAlgorithm, fns ...CertificateExtensionFunc) (*TLSCertificateConfig, error) {


I think the issue described at https://github.com/openshift/library-go/pull/2116/changes#r2826380341 is also applicable to the server, client cert template.

p0lyn0mial

Added a few more nits, overall lgtm.

Before merging, should we pull the changes to the service-ca-operator to make sure the backward compatibility path works?

Also, are we planning some e2e tests for the service-ca-operator to cover the new path?

p0lyn0mial · 2026-02-24T09:12:43Z

pkg/crypto/crypto.go

+// keyUsageForAlgorithm returns the appropriate KeyUsage for the given algorithm.
+// RSA keys use KeyEncipherment (for RSA key transport in TLS) + DigitalSignature.
+// ECDSA keys use only DigitalSignature per RFC 5480 Section 3.
+func keyUsageForAlgorithm(algorithm KeyAlgorithm) x509.KeyUsage {


nit: could we rename this to baseKeyUsageForAlgorithm (or something similar) to indicate the returned value is a starting point that callers may need to extend?

Done. Renamed to baseKeyUsageForAlgorithm to make it clear the returned value is a starting point that callers extend (e.g. | KeyUsageCertSign for CAs).

p0lyn0mial · 2026-02-24T09:19:00Z

pkg/crypto/crypto_test.go

+	case *rsa.PrivateKey:
+		return x509.SHA256WithRSA
+	default:
+		return x509.SHA256WithRSA


why not to t.Fatal for unrecognized values?

Done. signatureAlgorithmForKey now takes testing.TB and calls t.Fatalf on unrecognized key types instead of silently defaulting to RSA.

p0lyn0mial · 2026-02-25T09:09:37Z

pkg/crypto/crypto_test.go

+		return x509.SHA256WithRSA
+	default:
+		t.Fatalf("unrecognized private key type: %T", key)
+		return 0


nit: this is unreachable code - i think this could be removed.

Unfortunately Go requires it — t.Fatalf does not have a "never returns" type, so the compiler needs a return statement to satisfy the function signature. Added a // unreachable, but required by the compiler comment and moved the t.Fatalf + return outside the switch to make it clearer.

mhm, ok, thanks for checking.

Adds support for generating ECDSA P-256 certificates by specifying the key algorithm via the new service annotation: service.beta.openshift.io/serving-cert-key-algorithm: ecdsa When the annotation is not specified or set to "rsa", the operator generates RSA certificates for full backwards compatibility. This enables services to opt into modern elliptic curve cryptography, which provides equivalent security to 3072-bit RSA with significantly smaller keys (~87% smaller) and better performance. Implementation: - Added ServingCertKeyAlgorithmAnnotation constant in api.go - Modified MakeServingCert() to check annotation and select algorithm - Uses library-go's new MakeServerCertWithAlgorithm() API - Validates annotation values (rsa, ecdsa) with helpful error messages - Case-insensitive algorithm matching - Wired ECDSA CA support: caConfig now accepts a KeyAlgorithm field, initializeSigningSecret passes algorithm to CA creation - CA rotation supports both RSA and ECDSA keys: removed RSA-only type assertion, rotateSigningCA and createIntermediateCACert accept crypto.PrivateKey, algorithm is detected and preserved on rotation Testing: - Added TestECDSACertificateGeneration with 5 test cases - Verifies RSA (default and explicit), ECDSA, and invalid inputs - Added e2e tests: ECDSA cert provisioning, invalid algorithm rejection, and ECDSA cert regeneration after corruption - All existing tests pass with no regressions Depends on: openshift/library-go#2116 Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> Signed-off-by: Fabien Dupont <fdupont@redhat.com>

p0lyn0mial · 2026-02-26T10:53:51Z

/lgtm

/hold
putting this on hold until the service-ca-operator PR gets reviewed and we are confident the changes introduced in this PR are the ones we need.

@fabiendupont thanks for the pr and all your work :)

openshift-ci · 2026-02-26T10:54:54Z

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: fabiendupont, p0lyn0mial

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details

Needs approval from an approver in each of these files:

~~OWNERS~~ [p0lyn0mial]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

benluddy

This looks reasonable. I spoke with @sanchezl about potential overlap with openshift/enhancements#1882 and I don't think it would be harmful to grow a second way to do this in the future or have to do some refactoring.

benluddy · 2026-02-26T19:15:17Z

pkg/crypto/crypto.go

 	authorityKeyId := ca.Config.Certs[0].SubjectKeyId
 	subjectKeyId := publicKeyHash
-	serverTemplate := newServerCertificateTemplateForDuration(pkix.Name{CommonName: sets.List(hostnames)[0]}, sets.List(hostnames), lifetime, time.Now, authorityKeyId, subjectKeyId)
+	serverTemplate := newServerCertificateTemplateForDuration(pkix.Name{CommonName: sets.List(hostnames)[0]}, sets.List(hostnames), lifetime, time.Now, authorityKeyId, subjectKeyId, algorithm)


The difference between MakeServerCert[WithAlgorithm] and MakeServerCertForDuration[WithAlgorithm] appears to come down to whether they call newServerCertificateTemplate or newServerCertificateTemplateForDuration, and those two have evolved in a strange way.

The first accepted the lifetime as number of days, applied a default, then converted it to a time.Duration before delegating to the ...ForDuration func. Last year, this was changed so that both accept time.Duration. The remaining differences are (1) the first form applies a default lifetime and (2) has a side effect of writing to stderr.

I think this means that MakeServerCert[WithAlgorithm] will apply a default when the provided lifetime is <= 0, whereas MakeServerCertForDuration[WithAlgorithm] will not. I doubt this difference is obvious to anyone who might be using this package. I agree with what Fabien has done in this PR (i.e., MakeServerCertWithAlgorithm is consistent with MakeServerCert, and MakeServerCertForDuration is consistent with MakeServerCertForDurationWithAlgorithm), but this feels like something we should improve later (cc @p0lyn0mial @sanchezl).

sgtm, the distinction is almost invisible.

Done. Consolidated the two paths:

Removed makeServerCertForDuration — MakeServerCertForDuration and MakeServerCertForDurationWithAlgorithm now delegate to makeServerCert.

Removed the newServerCertificateTemplate lifetime-defaulting wrapper — newServerCertificateTemplateForDuration is now the sole newServerCertificateTemplate.

Updated TestValidityPeriodOfServerCertificate to remove the test cases for 0 and negative lifetime that relied on the removed defaulting behavior.

benluddy · 2026-02-26T20:28:17Z

pkg/crypto/crypto_test.go

@@ -151,7 +168,11 @@ func newSigningCertificateTemplate(subject pkix.Name, lifetime time.Duration, cu
 		warnAboutCertificateLifeTime(subject.CommonName, DefaultCACertificateLifetimeDuration)
 	}

-	return newSigningCertificateTemplateForDuration(subject, lifetime, currentTime, nil, nil)
+	algo := AlgorithmRSA
+	if len(algorithm) > 0 {
+		algo = algorithm[0]
+	}
+	return newSigningCertificateTemplateForDuration(subject, lifetime, currentTime, nil, nil, algo)


Instead of making the function variadic with a default (and tossing all but the first KeyAlgorithm), can we make the KeyAlgorithm a normal parameter and update the callers to always provide a value?

Done. newSigningCertificateTemplate now takes algorithm KeyAlgorithm as a required parameter. All callers updated to explicitly pass AlgorithmRSA (or tt.caAlgorithm for the mixed test).

benluddy · 2026-02-26T20:35:59Z

pkg/crypto/crypto_test.go

+	// Verify public key matches private key
+	require.True(t, publicKey.X.Cmp(privateKey.PublicKey.X) == 0, "public key X should match")
+	require.True(t, publicKey.Y.Cmp(privateKey.PublicKey.Y) == 0, "public key Y should match")


Would https://pkg.go.dev/crypto/ecdsa#PublicKey.Equal be suitable for this test?

Done. Replaced the manual X.Cmp/Y.Cmp checks with publicKey.Equal(&privateKey.PublicKey).

Adds support for generating ECDSA P-256 certificates by specifying the key algorithm via the new service annotation: service.beta.openshift.io/serving-cert-key-algorithm: ecdsa When the annotation is not specified or set to "rsa", the operator generates RSA certificates for full backwards compatibility. This enables services to opt into modern elliptic curve cryptography, which provides equivalent security to 3072-bit RSA with significantly smaller keys (~87% smaller) and better performance. Implementation: - Added ServingCertKeyAlgorithmAnnotation constant in api.go - Modified MakeServingCert() to check annotation and select algorithm - Uses library-go's new MakeServerCertWithAlgorithm() API - Validates annotation values (rsa, ecdsa) with helpful error messages - Case-insensitive algorithm matching - Wired ECDSA CA support: caConfig now accepts a KeyAlgorithm field, initializeSigningSecret passes algorithm to CA creation - CA rotation supports both RSA and ECDSA keys: removed RSA-only type assertion, rotateSigningCA and createIntermediateCACert accept crypto.PrivateKey, algorithm is detected and preserved on rotation Testing: - Added TestECDSACertificateGeneration with 5 test cases - Verifies RSA (default and explicit), ECDSA, and invalid inputs - Added e2e tests: ECDSA cert provisioning, invalid algorithm rejection, and ECDSA cert regeneration after corruption - All existing tests pass with no regressions Depends on: openshift/library-go#2116 Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> Signed-off-by: Fabien Dupont <fdupont@redhat.com>

hasbro17 · 2026-03-03T17:53:45Z

pkg/crypto/crypto.go


+// newECDSAKeyPair generates a new P-256 ECDSA key pair
+func newECDSAKeyPair() (*ecdsa.PublicKey, *ecdsa.PrivateKey, error) {
+	privateKey, err := ecdsa.GenerateKey(elliptic.P256(), rand.Reader)


Not a review, just a note for the PKI feature team that will refactor this down the line openshift/enhancements#1882

Support RSA (with configurable key sizes: 2048, 3072, 4096) and ECDSA (with configurable curves: P-256, P-384, P-521) algorithms in the initial implementation

/cc @rh-roman @sanchezl We'll have to thread the key size here and for newKeyPairWithHash() for the RSA case.

library-go/pkg/crypto/crypto.go

Line 1005 in 5d9eb62

func newKeyPairWithHash() (crypto.PublicKey, crypto.PrivateKey, []byte, error) {

And through newKeyPairWithAlgorithm() as well.

Extends the crypto package to generate ECDSA P-256 key pairs and certificates in addition to existing RSA support, enabling OpenShift components to use modern elliptic curve cryptography. Adds: - KeyAlgorithm type for algorithm selection (RSA, ECDSA) - ECDSA P-256 key pair generation with proper SubjectKeyIdentifier hashing - MakeServerCertWithAlgorithm() and MakeServerCertForDurationWithAlgorithm() - MakeSelfSignedCAConfigForDurationWithAlgorithm() for ECDSA root CAs - MakeCAConfigForDurationWithAlgorithm() for ECDSA intermediate CAs Removes hardcoded SignatureAlgorithm from certificate templates, letting x509.CreateCertificate infer the correct algorithm from the signing key. This is backward compatible and enables correct cross-algorithm signing (e.g. RSA CA signing ECDSA leaf certs). All existing APIs remain unchanged, preserving backwards compatibility. New functionality is opt-in through *WithAlgorithm variants. Co-authored-by: Claude Sonnet 4.5 <noreply@anthropic.com> Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> Signed-off-by: Fabien Dupont <fdupont@redhat.com>

openshift-ci · 2026-03-04T14:39:46Z

New changes are detected. LGTM label has been removed.

openshift-ci · 2026-03-04T14:49:58Z

@fabiendupont: all tests passed!

Full PR test history. Your PR dashboard.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here.

openshift-ci-robot added the jira/valid-reference Indicates that this PR references a valid Jira ticket of any type. label Feb 4, 2026

openshift-ci bot requested review from deads2k and p0lyn0mial February 4, 2026 17:26

fabiendupont force-pushed the add-ecdsa-support branch from 8dd03c3 to 724c6f6 Compare February 4, 2026 17:49

fabiendupont mentioned this pull request Feb 4, 2026

NO-JIRA: Add ECDSA certificate generation support via annotation openshift/service-ca-operator#315

Draft

fabiendupont force-pushed the add-ecdsa-support branch from 724c6f6 to b5ed9f4 Compare February 5, 2026 14:01

p0lyn0mial reviewed Feb 11, 2026

View reviewed changes

fabiendupont force-pushed the add-ecdsa-support branch from b5ed9f4 to 854a902 Compare February 11, 2026 16:23

fabiendupont changed the title ~~NO-JIRA: Add ECDSA P-256 key generation support~~ NO-JIRA: Add ECDSA P-256 support for certificates and CAs Feb 13, 2026

fabiendupont force-pushed the add-ecdsa-support branch 2 times, most recently from 3e1f176 to 62ba714 Compare February 13, 2026 16:48

openshift-merge-robot added the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Feb 13, 2026

fabiendupont force-pushed the add-ecdsa-support branch from 62ba714 to 3a9f301 Compare February 13, 2026 16:55

openshift-merge-robot removed the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Feb 13, 2026

p0lyn0mial reviewed Feb 16, 2026

View reviewed changes

fabiendupont force-pushed the add-ecdsa-support branch from 3a9f301 to 212d47c Compare February 17, 2026 12:32

p0lyn0mial reviewed Feb 19, 2026

View reviewed changes

fabiendupont force-pushed the add-ecdsa-support branch from 212d47c to 4f7ae88 Compare February 19, 2026 14:42

p0lyn0mial reviewed Feb 24, 2026

View reviewed changes

fabiendupont force-pushed the add-ecdsa-support branch from 4f7ae88 to 7b058d5 Compare February 24, 2026 14:56

p0lyn0mial reviewed Feb 25, 2026

View reviewed changes

fabiendupont force-pushed the add-ecdsa-support branch from 7b058d5 to 4ffdff6 Compare February 25, 2026 16:08

openshift-ci bot added the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Feb 26, 2026

openshift-ci bot assigned p0lyn0mial Feb 26, 2026

openshift-ci bot added the lgtm Indicates that a PR is ready to be merged. label Feb 26, 2026

openshift-ci bot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Feb 26, 2026

benluddy reviewed Feb 26, 2026

View reviewed changes

hasbro17 reviewed Mar 3, 2026

View reviewed changes

fabiendupont force-pushed the add-ecdsa-support branch from 4ffdff6 to 125dfb4 Compare March 4, 2026 14:39

openshift-ci bot removed the lgtm Indicates that a PR is ready to be merged. label Mar 4, 2026

Conversation

fabiendupont commented Feb 4, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Changes

Test coverage

Uh oh!

openshift-ci-robot commented Feb 4, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

fabiendupont commented Feb 13, 2026

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

p0lyn0mial Feb 19, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

p0lyn0mial left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

p0lyn0mial commented Feb 26, 2026

Uh oh!

openshift-ci bot commented Feb 26, 2026

Uh oh!

benluddy left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

openshift-ci bot commented Mar 4, 2026

Uh oh!

openshift-ci bot commented Mar 4, 2026

Uh oh!

fabiendupont commented Feb 4, 2026 •

edited

Loading

p0lyn0mial Feb 19, 2026 •

edited

Loading