Feature: harden against material leaks

[laurentsimon]

Feature: harden against material leaks

[ianlewis]

1. GITHUB_TOKEN which allows requesting certs from Fulcio. Not sure yet what we can do here, besides hardening our implementation and verifying that the keys don't leak in coredump, in logs, etc. Somehow we'd like to add scope to the GITHUB_TOKEN to be one-time-use only, but that would require support from GitHub. Maybe something we can propose to them. Let me know if you have other ideas.

GITHUB_TOKEN gets scrubbed from logs at least. Is there a way that we could leak it in a coredump? If something crashes we would have to extract the coredump somehow for it to leak no?

2. The signing key: shall we enforce, during verification, that there exists a single rekor entry with the certificate?

I'm not sure I follow. How does verifying there exists a single rekor entry with the cert prevent leaks of the private signing key?

Maybe this issue is mostly subsumed by #897? Is there anything we need to do for this issue?

[laurentsimon]

1. GITHUB_TOKEN which allows requesting certs from Fulcio. Not sure yet what we can do here, besides hardening our implementation and verifying that the keys don't leak in coredump, in logs, etc. Somehow we'd like to add scope to the GITHUB_TOKEN to be one-time-use only, but that would require support from GitHub. Maybe something we can propose to them. Let me know if you have other ideas.

GITHUB_TOKEN gets scrubbed from logs at least. Is there a way that we could leak it in a coredump? If something crashes we would have to extract the coredump somehow for it to leak no?

yes, it's hard to account for all scenario. It could also be a leak internal to GH, their SREs, etc.

2. The signing key: shall we enforce, during verification, that there exists a single rekor entry with the certificate?

I'm not sure I follow. How does verifying there exists a single rekor entry with the cert prevent leaks of the private signing key?

if the token does not leak, but the key+cert does, someone could sign arbitrary data. Our generators sign a single blob with a cert, so we could detect the leak by verifying that only a single signature exists for each certificate.

[ianlewis]

Our generators sign a single blob with a cert, so we could detect the leak by verifying that only a single signature exists for each certificate.

Ok, I see. Basically you want to detect if someone used our generator to sign a second malicious artifact after the original was created? If the key itself was leaked couldn't they theoretically just use it without using our generators and creating another rekor entry?

[laurentsimon]

not our generator, but the cert we used. We would detect the double sign for a single cert and find out. The assumption being that we do an online verification