[Rpm-maint] [rpm-software-management/rpm] API improvement to accommodate for RPM CoW (PR#1470) (Discussion #2057)

[Demi Marie Obenour]

@ddiss: From my perspective, plugins should not deal with untrusted input, so “used” means “passed to the plugin”.  This means that data must be buffered in memory until it can be cryptographically verified.  This is not possible with the current digest format, but a new format can support very efficient streaming verification, requiring only _O(log N)_ or even _O(1)_ space.

A simple design is something like this:

```c
struct signed_block {
    uint16_t size; // size of this block, limited to 64KiB
                   // but must be at least 1KiB (except last block)
    char hash[64]; // Hash of the next block, or all zeros for EOF
    char payload[]; // size - 64 bytes
};
```

With this proposal, the payload digest only covers the first block in the payload.  Once the first block is hashed, the payload is released to the plugin, while the hash is stored by RPM to verify the next block.

Another option is to use per-block hashes stored in the RPM header.  This bloats the RPM header, but allows for hash generation and verification to happen in parallel.  Assuming a 1MiB block size, a 1TiB RPM (which is absolutely massive), a 512-bit hash, and the use of a byte array tag in the header (more efficient than a string array), this would require ((2<sup>40</sup> ÷ 2<sup>20</sup>) × (512 ÷ 8)) = 64MiB of space in the header, which is well within the limit of 256MiB.

Whichever solution is chosen, RPM should provide a way to calculate a hash of the package that includes everything except the payload, and which returns an error if there is no payload digest.  This can be included in metadata.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2057#discussioncomment-9280355
You are receiving this because you are subscribed to this thread.

Message ID: <rpm-software-management/rpm/repo-discussions/2057/comments/9280355 at github.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20240430/5247df36/attachment-0001.html>