Demi Marie Obenour

> Just for the record: I've discussed this issue with @pmatilai and @dmnks from the RPM team and they said they would prefer a different language than Rust in order...

C++ isn’t memory safe, though. See Chromium’s “doom zone”: parsing untrusted input in a memory-unsafe language with high privilege is a bad idea. Rust avoids this by virtue of being...

> Alright, I'll bite let's discuss. > > @DemiMarie: > > > C++ isn’t memory safe, though. See Chromium’s “doom zone”: parsing untrusted input in a memory-unsafe language with high...

@lukash Thank you for your extremely well-reasoned comments.

Update: The code is now public: https://github.com/QubesOS/RPM-Oxide. It is not used in production yet, but the plan is to use it to sanitize RPMs before they are installed in the...

> Cool. The idea makes sense. I'd be interested in trying to ship this in rpm-ostree today, though it'd need to be something like an optional/experimental flag. We'd need to...

@j-mracek deltarpm does not have any signature verification functionality. Verification can be handled by librpm itself, as with normal RPMs.

These are not mutually exclusive. The hash has two major advantages: - It works for all data, not just GPG keys. - It protects against exploitable vulnerabilities in GPG’s public...

To elaborate, parsing a general key is significantly more complex than parsing a signature, and is therefore more likely to have exploitable vulnerabilities. I would be fine with a `gpgkeyhash=`...

> I need to debug this a bit, but a [recent run](https://github.com/google/sandboxed-api/runs/5186121656?check_suite_focus=true) of the Fedora build behaves (AFAICT) the same. Looking at [sandboxed_api/sandbox2/stack_trace.cc:142](https://github.com/google/sandboxed-api/blob/38eea151a686e9b2ab50e69c64f79b0fe79578de/sandboxed_api/sandbox2/stack_trace.cc#L142), we're probably just missing `/lib` and `/lib64`...