[Rpm-maint] [rpm-software-management/rpm] RPM with Copy on Write (#1470)

[chantra]

> You mention the need for the file to be seekable.

Ha. Yeah, so in order to be able to verify a transcoded file, you need to be able to seek in the file (the footer contains the magic + metadata).

So, something like:
```
cat mytranscoded.rpm | rpmkeys -Kv -
```
would not work, but 
So, something like:
```
rpmkeys -Kv - <mytranscoded.rpm
or
rpmkeys -Kv mytranscoded.rpm
```
does. `dnf` currently use the latter approach.

> That is definitely a step forward, especially if the hashing is performed in the parent process. I imagine SECCOMP_SET_MODE_STRICT would be pretty hard to break out of, and would dramatically reduce my worries about this patch. Is setting up SECCOMP_SET_MODE_STRICT before decompression a viable option?

`rpm2extents` in essence reads from stdin and writes to stdout so it should be pretty easy to sandbox. There is likely a bit more to it dues to expectations from the rpm library, but as much as privileges, it needs none. I have not looked into the specifics here yet, but from a high-level, it should be reasonably easy.

> What if RPM CoW is merged but not enabled by default? Once signature validation is up to par with standard RPM it can be enabled by default.

As it is, RPM CoW only gets enabled when [dnf-plugin-cow](https://github.com/facebookincubator/dnf-plugin-cow/) is enabled.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1470#issuecomment-1034302352
You are receiving this because you are subscribed to this thread.

Message ID: <rpm-software-management/rpm/pull/1470/c1034302352 at github.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20220209/d0e368a4/attachment-0001.html>