On Fri, Jun 11, 2021 at 7:01 PM Miloslav Trmac <mitr@xxxxxxxxxx> wrote:
Hello,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 :)
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?
_______________________________________________So what’s the new security property? It’s not that we have a full record, if I understand the proposal correctly (maybe I don’t); it’s not that anyone can on-line query whether an artifact is the latest currently signed version (for that, clients can already use HTTPS to get the metalink data IIRC).This would only make sense if a proof of presence in the Rekor log were a required part of signature verification by all clients — and that would still only give us an audit log, it would not actually prevent clients from installing the maliciously-signed RPM (the current metalinks sort-of do that already, sure). Given the above discussion about signing metadata, presumably a much smaller change, what makes such a Rekor integration more likely to get done?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
