[Rpm-maint] [rpm-software-management/rpm] Rust bindings for rpmlib (#429)

[Tony Arcieri]

@pmatilai using "owned" memory instead of borrowed, in Rust terminology, is an alternative, and one that could potentially eliminate any possible use-after-free vulnerabilities.

However, building zero copy APIs on top of things like `HEADERGET_MINMEM` is something of Rust's raison d'etre, and one for which it has a number of neat tricks, like the `StreamingIterator` I was using previously. That approach would cause the compiler to reject any programs where the match iterator's `next()` method is called while there are still references sourced from the previous header are still alive. I'm not sure in what other languages something like that is even possible, especially as a compile-time guarantee.

The PR I just linked goes from the very conservative memory model I was just describing to one that makes many more assumptions which I'm not entirely sure are correct. As you note I may be incorrectly handling string arrays.

Perhaps there's a happy medium that more tightly bounds the lifetimes and then makes fewer assumptions. I can at least guarantee the following in the current binding based on the Rust lifetimes:

- Nothing will ever outlive the global transaction set
- MatchIterators acquire a global mutex and do not release it until they have been "dropped"
- Headers increment the reference count with `headerLink` and do not decrement it until they are "dropped". They are `!Sync` and `!Send` (i.e. not thread safe or moveable between threads) and therefore "pinned" to the thread in which they are created (the same goes for MatchIterators)
- Tag data is guaranteed to never outlive the header from which it is fetched, ensuring the header's reference count is never decremented (via `headerFree`) until there are no longer references to its tag data (this is enforced via a [Rust lifetime](https://github.com/iqlusion-io/crates/blob/master/rpmlib/src/td.rs#L11) but is a fairly similar approach to what you'd use in a GC'd language by having tag data mark the header from which it is fetched).

> FWIW, I don't see a reason why the bindings could not be "hosted" in the rpm-software-management group, it'd be only a good thing to have these things under the same umbrella.

That'd be great. I've been thinking about splitting the current code into its own repo and relicensing it as LGPL 2.1+ to move towards something like that.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/429#issuecomment-381610231
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20180416/0d5fb04e/attachment.html>