Added --client-signing-algorithms flag

[ret2libc]

Summary

Add --client-signing-algorithms flag to rekor-server to restrict the set of client keys accepted by a Rekor instance. See #1724 .

This work depends on sigstore/sigstore#1601

Release Note

Documentation

[codecov]

Codecov Report

Attention: Patch coverage is 50.00000% with 53 lines in your changes missing coverage. Please review.

Project coverage is 49.88%. Comparing base (488eb97) to head (e2e4a9b).
Report is 306 commits behind head on main.

Files with missing lines	Patch %	Lines
pkg/api/entries.go	45.83%	31 Missing and 8 partials ⚠️
pkg/api/api.go	50.00%	7 Missing and 5 partials ⚠️
cmd/rekor-server/app/root.go	80.00%	1 Missing and 1 partial ⚠️

Additional details and impacted files

@@             Coverage Diff             @@
##             main    #1974       +/-   ##
===========================================
- Coverage   66.46%   49.88%   -16.58%     
===========================================
  Files          92      192      +100     
  Lines        9258    24857    +15599     
===========================================
+ Hits         6153    12401     +6248     
- Misses       2359    11341     +8982     
- Partials      746     1115      +369     

Flag	Coverage Δ
e2etests	46.68% <50.00%> (-0.88%)	⬇️
unittests	41.77% <7.54%> (-5.92%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[ret2libc]

--- FAIL: TestJAR (0.07s)
    e2e_test.go:33: Using config file:%!(EXTRA string=/tmp/rekor_test.9ofp49.rekor.yaml)
        [POST /api/v1/log/entries][400] createLogEntryBadRequest  &{Code:400 Message:error processing entry: getting verifiers: jar v0.0.1 entry not initialized}
        warning: GOCOVERDIR not set, no coverage data emitted

Apparently the e2e test does not fill the Signature part of the JARModel:

	if v.JARModel.Signature == nil || v.JARModel.Signature.PublicKey == nil || v.JARModel.Signature.PublicKey.Content == nil {
		return nil, errors.New("jar v0.0.1 entry not initialized")
	}

Shall this be handled or is the signature always expected to be present?

[haydentherapper]

Signature should be present, it's required to validate a new jar entry -

rekor/pkg/types/jar/v0.0.1/entry.go

Line 248 in d596e9d

if v.JARModel.Signature == nil || v.JARModel.Signature.Content == nil {

[bobcallaway]

what if err != nil?

[ret2libc]

refactored this a bit, let me know if it's better!

[bobcallaway]

this feels like it should be inside types.CreateVersionedEntry instead of in the API layer; wdyt?

[ret2libc]

Maybe, but it uses api.algorithmRegistry and nothing in pkg/types use api. Would that be fine anyway?

[ret2libc]

@bobcallaway @haydentherapper shall we start with hashedrekord entries only? If we want to add support for other types I guess we need to change the schemas similarly to what we did for hashedrekord.

[woodruffw]

My 0.02c is that it's fine to start here: my understanding is that the long term plan is to remove a lot of the non-hashed entries with Rekor v2 anyways, plus this flag is primarily for test deployment purposes anyways 🙂.

[bobcallaway]

code looks fine. I would like to see some e2e tests that show it works before merging.

[ret2libc]

@bobcallaway I added an e2e test, though I don't see it running in the CI. Could it be because it's not in main yet?

[bobcallaway]

@bobcallaway I added an e2e test, though I don't see it running in the CI. Could it be because it's not in main yet?

It requires build so it won't show up in the list until that is done since it's a new job.

https://github.com/sigstore/rekor/actions/runs/13202747393/job/36858854058?pr=1974