Hello, pá 11. 6. 2021 v 20:23 odesílatel Luke Hinds <[email protected]> napsal:
> On Fri, Jun 11, 2021 at 7:01 PM Miloslav Trmac <[email protected]> wrote: > >> pá 11. 6. 2021 v 18:54 odesílatel Luke Hinds <[email protected]> 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)? 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? Mirek
_______________________________________________ devel mailing list -- [email protected] To unsubscribe send an email to [email protected] 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/[email protected] Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
