On Fri, Jun 11, 2021 at 7:01 PM Miloslav Trmac <[email protected]> wrote:
> Hello, > 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 :) > >> 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 -- [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 >
_______________________________________________ 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
