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)?
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 -- 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
