If what you mean is that the payload shouldn't be used before it's been checked
against a digest in the cryptographically verified header, then yes. The
question is what quantifies as "used".
The payload data needs to go somewhere while we're calculating the digest, in
which case we could "stream" it to Btrfs in it's compressed, yet-to-be-verified
form via `BTRFS_IOC_ENCODED_WRITE`. However, doing so would allow any
concurrent (pre-verification) reads to effectively fuzz the btrfs/zstd
decompression code path.
One protection mechanism might be to write out the payload in its regular
(compressed) form before attempting to *switch* those regular extents to
compressed extents on btrfs via some new `copy_file_range()` flag. The
regular->compressed extent switch would only be attempted following successful
payload verification.
I'm very much open to any other suggestions :-)
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2057#discussioncomment-9270320
You are receiving this because you are subscribed to this thread.
Message ID:
<rpm-software-management/rpm/repo-discussions/2057/comments/9270...@github.com>
_______________________________________________
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
