On Fri, Jun 11, 2021 at 8:09 PM Miloslav Trmac <mitr@xxxxxxxxxx> wrote:
Hello,pá 11. 6. 2021 v 20:23 odesílatel Luke Hinds <lhinds@xxxxxxxxxx> napsal:On Fri, Jun 11, 2021 at 7:01 PM Miloslav Trmac <mitr@xxxxxxxxxx> wrote:pá 11. 6. 2021 v 18:54 odesílatel Luke Hinds <lhinds@xxxxxxxxxx> napsal:Why is this useful? You get a timestamped / tamper resistance record of all signing events. This is very useful for understanding the exact blast radius of a key compromise and monitoring for suspicious events. Most of the time you will not interact with the tlog, it would sit off to side hashing in entries, so it would make no changes to a maintainers working flow or not being in any build path where it could cause an outage.That seems to suggest that ordinary clients pulling updates would not depend on finding a Rekor entry (and the “not being in any build path” wording even suggests that builds (composes?) would not send anything to Rekor ??!), and in that case…I may not have articulated this well. My main point was this is not an inline / gating system, whereby if rekor has a system outage its not going to stop the entire build chain. I saw this as folks always get nervous about adding new actors to a build pipeline. "would not send anything to Rekor ??!), and in that case…" no, that is very far from the case :)I don’t understand at all. Would the build usually send things to Rekor, or not? If not, what‘s the value of Rekor? If yes, and that process failed, would the build fail or not? Or are you differentiating between a build (which would not create consumable signatures) and a compose/publish step (which could fail if Rekor is unavailable)?
Yes it would. Forget my earlier wording, it was not helpful. I was just trying to state if it's in collection only mode (and not a queryable system for entry by clients), then it would not cause other systems to backup with quotes etc.
It's the sort of system most would not be aware of, unless something awful happens, and then it has a lot of value, as you have an immutable record of events.… creating the immutable record is entirely optional, in particular the attacker doesn’t have to do this to attack a consumer successfully. The record would only exist if the attacker could trigger an existing build/signing system to build/sign a malicious artifact, without having full control over the build/signing system — and in that case any other logging solution from that build/signing system (just send it to a write-only log host) would have very similar security properties, it seems to me.I don't understand where you're getting entirely optional from?My attack scenario is that an attacker $somehow obtains a signature of a malicious RPM (by building it in Koji directly, attacking Koji to get it built, stealing the private key and signing it itself), and then publishes that malicious RPM on an attacker-controller mirror/server for a victim to update to. At least in the “stolen private key” scenario, and maybe in the others (see questions above), the attacker can just not upload any entry to Rekor. What forces the attacker to upload an entry? If the attacker doesn’t have to enter anything into Rekor, what is the value? The only way this makes sense to me is to make proof of Rekor inclusion a required component of signature verification, for everyone. Is that the proposal?
Sorry, I understand now (long week), so what you describe is the ideal implementation, which is where clients verify for inclusion ("Am I seeing what everyone else is seeing") , or discoverability as the certificate transparency folks call it. This is exactly what browsers do with certificate transparency. They have a header 'Expect-CT' [0] , if no entry / cert chain is in the log and they are in enforcement mode, they reject a visit to the site . This way it negates the 'just don't put it in the log' concern. This is what we do in sigstore, if no software signing materials are in the transparency log, it's not a valid signing and it's rejected - as there is no transparency watcher of the event.
_______________________________________________Mirek
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
