Open jas4711 opened 1 year ago
I ran into another problem where rekor refused an upload where the public key sent had a /signature/ from an Ed25519 key.
I believe the solution here should be:
1) Rekor should find out the PGP key IDs used to sign the artifact, from the signature file. 2) These keys should be extracted from the public key sent to rekor. 3) The public keys should be minimized to not contain unrelated information, compare 'gpg --export-options export-minimal --export'. 4) The public keys should be sorted in some canonical order.
Then that should be what goes into the "public key" field and stored in the rekor log.
There is a corner-case: what if the artifact was signed by many signers, but the provided public key file did not contain all public keys for those signatures. I think that should be rejected: if several keys signed the artifact, the public keys for ALL those keys should be sent into rekor. An alternative approach is to accept at least ONE key matching the signature, and not care if others are missing. This is the current behaviour, but it feels sub-optimal.
Hi. I'm using rekor-cli v1.1.0 and I'm working on transparency for trisquel/ubuntu/debian/etc-style apt archives and noticed the following problem. It seems the rekor server accepts and stores unrelated keys when accepting a PGP signature.
Compare this session:
And look at what's stored in the log:
The following more minimal upload results in a smaller key:
Compare log output:
Am I missing something, or shouldn't the server strip any non-related keys before adding them to the log?