Unfortunately I haven't had time to continue work on this, but did get to the
point where there are basic memory safe bindings for querying the database
which do not rely on librpm's memory and instead make copies of relevant data
to the Rust heap (while leaving the door open to query more
Thanks!
--
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-469283550___
Rpm-maint mailing list
Thanks for the heads up! We definitely should support SHA-256
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
For now I've moved everything under a GitHub organization:
https://github.com/rustrpm
The Rust bindings to librpm are now located at:
https://github.com/rustrpm/librpm-rs
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@dmach would you consider creating a repository under
https://github.com/rpm-software-management/ where I can push my Rust bindings?
Alternatively I could open a PR to
https://github.com/rpm-software-management/rpm containing them
Or if you'd like to wait until they're a bit more mature, I can
I think it's a bit hard to move things that way (without making me an admin),
but given it's a brand new repo I can either:
1) Just push all the same code to a newly created repo under
`rpm-software-management` or
2) Give someone admin access to `librpm-rs` so they can move it
--
You are
I've renamed the project to librpm.rs:
https://crates.io/crates/librpm
I've extracted it into its own Git repo here, with everything licensed as
LGPLv2.1+:
https://github.com/tarcieri/librpm-rs
I've also changed the binding to move everything relating to match iterators
and headers into an
@n3npq can't say I'm super thrilled with the prospects of replacing access to
an in-memory data structure with something based on XML
>As for handling tag data, you probably don't want to expose rpmtd to rust
>directly but convert to native representation [...]
> Worse, any data addition to a
@n3npq where is `rpmQuery` defined? (is it `rpmcliQuery`?)
This is all I could find, and it wasn't immediately obvious how to read results
from it:
http://ftp.rpm.org/api/4.12.0.1/group__rpmcli.html#ga2dbfa3886628a79646b2c286ea5c56d9
--
You are receiving this because you are subscribed to
@n3npq I am not... definitely good to know as the current code is bogus.
What'd be really helpful in regard to testing tag data is a tag type which
corresponds to each of the tag data types, particularly arrays/vectors of the
integer types.
--
You are receiving this because you are subscribed
@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
I've opened a PR which implements a bunch of @n3npq's suggestions:
https://github.com/iqlusion-io/crates/pull/28/files
Namely:
- No more `Database` type. Instead `db.rs` is a handful of static functions for
querying the database
- `TransactionSet` is no-longer part of the public API (although
@n3npq I'm working on simplifying the API and also switching from a
`StreamingIterator` to a regular `Iterator` by using reference counting on
header data. I had a question about this though:
> The trickiest problem with header tag data and MINMEM is that the header
> reference count sometimes
@n3npq yeah I've been meaning to add some sort of higher level facade around
`Header` which makes it easy to do the obvious things like get the package's
name and description, but I wasn't quite sure what it would look like yet.
@Conan-Kudo thanks!
--
You are receiving this because you are
Great! With that I can add a wrapper type for accessing it which acquires the
lock, and when dropped calls `rpmtsClean()` as the last thing before it
releases the lock.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
> What I am suggesting (but I know nothing serious about rust) is running an
> array of header references during an iteration using *Link() that have
> *Free() called when the rust Iterator goes out of scope.
Yep, that's exactly what I'd like to do.
--
You are receiving this because you are
> Do an additional ref++ using *Link() if you want to make a header persistent
> for further processing outside of an iteration (but don't forget the ref--
> using *Free() or you will have a huge memory leak ;-)
Are there any additional lifetimes to worry about here, e.g. the lifetime of
the
Aha, so if I call this:
http://rpm5.org/docs/api/group__header.html#g4f07e8040ed3195e374a44919ffe97c2
...and `headerFree()` on drop, it sounds like I could switch to a normal Rust
iterator which iterates over immutable references.
--
You are receiving this because you are subscribed to this
@n3npq a few questions about something you said earlier:
> RPM object (like ts, h, db) is ref-counted, but the counter increment is not
> atomic.
When are the reference counts incremented/decremented, and can I bump them
externally? If so, I could have Rust increment the reference count when
I would have used `rpm`, unfortunately someone else took it for something
completely unrelated (and won't give it up, I already asked):
https://crates.io/crates/rpm
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
> These days, we tend to call it librpm rather than rpmlib
Haha oh really! What's great about that is I started down the road of naming
things `librpm` then changed to `rpmlib` after noticing all the references to
it: https://crates.io/crates/librpm-sys
I can re-release the crate as `librpm`
Thanks for all of the feedback @n3npq! I will go through it and try to fix up
my library accordingly.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Yep, I'll go through and fix things up to use that instead.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Hello,
I've written a nascent Rust binding for rpmlib:
https://crates.io/crates/rpmlib
First of all, I would love any feedback. This is my first deep dive into the
internals of RPM, and while I found ample documentation about certain things, a
lot of what I was doing was guesswork.
I'm also
24 matches
Mail list logo
