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…
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.
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
