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