Re: [Rpm-maint] [rpm-software-management/rpm] Avoid negating an attacker-controlled signed integer (#1502)
@DemiMarie pushed 1 commit. 447faa1df796d99c9b76c7b592176998ed7ffbd4 Negate the trailer offset after division -- You are receiving this because you are subscribed to this thread. View it on GitHub: https://github.com/rpm-software-management/rpm/pull/1502/files/2d164139ec400e642af141dd684282eb67f3fa1b..447faa1df796d99c9b76c7b592176998ed7ffbd4 ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Make Lua a hard requirement for rpm (#1527)
@Conan-Kudo approved this pull request. -- 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/pull/1527#pullrequestreview-583694750___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Move transaction processing to a subprocess (#1526)
> > Using the RPM transaction APIs from such a process is currently Undefined > > Behavior. > > All such environments you listed also provide a way to constrain threading > behavior when you need to, because it's unrealistic to actually _mandate_ > that at the layers below it. Even Python, Perl, and Ruby have this. I know > Java _definitely_ does. > > The phrase "undefined behavior" (in title case or no) isn't enough in itself > to justify breaking the librpm architecture. Java, at least, does not support programs that call chdir(), much less chroot(). https://github.com/rpm-software-management/rpm/issues/1483#issuecomment-768456090 is an example of this being a problem in the real world. -- 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/1526#issuecomment-773513670___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Move transaction processing to a subprocess (#1526)
> Using the RPM transaction APIs from such a process is currently Undefined > Behavior. All such environments you listed also provide a way to constrain threading behavior when you need to, because it's unrealistic to actually _mandate_ that at the layers below it. Even Python, Perl, and Ruby have this. I know Java _definitely_ does. The phrase "undefined behavior" (in title case or no) isn't enough in itself to justify breaking the librpm architecture. -- 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/1526#issuecomment-773510992___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Move transaction processing to a subprocess (#1526)
Also, Rust, Java, .NET, glib, and several other languages, runtimes, and frameworks **require** that **all** code must be thread-safe, full stop. A Java or .NET VM will *always* have multiple threads running, and a GTK or QT application must assume that it will. Using the RPM transaction APIs from such a process is currently Undefined Behavior. Rust programs are not all multi-threaded, but Rust libraries are required to work in multithreaded programs, which means that the librpm.rs bindings are probably unsound. -- 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/1526#issuecomment-773509614___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Move transaction processing to a subprocess (#1526)
I (and rpm-ostree) want to be able to run a transaction from a multi-threaded parent process. This is only possible if the actual transaction is done in a child process managed by librpm. -- 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/1526#issuecomment-773506392___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Move transaction processing to a subprocess (#1526)
What scenario do you want to embed librpm that requires this that would _also_ do transactions? Because pretty much all MT-safe operations would generally not require doing transactions... -- 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/1526#issuecomment-773505019___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Move transaction processing to a subprocess (#1526)
Not really. The difference is that the subprocess would be created and managed by librpm itself. That means that librpm *itself* is thread-safe, which is a hard requirement for embedding librpm in certain scenarios. -- 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/1526#issuecomment-773504013___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Make Lua a hard requirement for rpm (#1527)
@pmatilai pushed 1 commit. f56e52d1b1fea74a147e5032ec7019a9d771c442 Make Lua a hard requirement for rpm -- You are receiving this because you are subscribed to this thread. View it on GitHub: https://github.com/rpm-software-management/rpm/pull/1527/files/cba7240e327714733833eeb27b5f5cb66b8b1545..f56e52d1b1fea74a147e5032ec7019a9d771c442 ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Make Lua a hard requirement for rpm (#1527)
More and more macros, scriptlets and other functionality has been getting built around Lua, to the point that it has in practise been required for several years now. Maintaining the pretense of being optional comes at a cost in holding back developments and having to check for that theoretical special case. Lets make it a hard requirement and embrace it some more! You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/1527 -- Commit Summary -- * Make Lua a hard requirement for rpm -- File Changes -- M INSTALL (11) M Makefile.am (3) M build/Makefile.am (7) M build/parsePreamble.c (2) M build/parseScript.c (5) M build/spec.c (2) M configure.ac (17) M lib/rpmds.c (2) M lib/rpmrc.c (4) M lib/rpmscript.c (4) M luaext/Makefile.am (4) M rpmio/Makefile.am (15) M rpmio/macro.c (7) M tests/atlocal.in (5) M tests/rpmbuild.at (8) M tests/rpmbuildid.at (2) M tests/rpmmacro.at (23) M tests/rpmreplace.at (1) M tests/rpmscript.at (2) M tests/rpmvercmp.at (1) M tests/rpmverify.at (2) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/1527.patch https://github.com/rpm-software-management/rpm/pull/1527.diff -- 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/pull/1527 ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: switch to override %config file behavior (#1522)
Yup, that's exactly the use-case I was referring to. -- 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/1522#issuecomment-773264267___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: switch to override %config file behavior (#1522)
> * when uninstalling something, you often want the configs gone too Having something along the lines of a "purge" mode would make some sense. It would be very appealing for mass system management purposes to be able to do 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/1522#issuecomment-773248772___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RPM with Copy on Write (#1470)
Based on a quick look at rpm2extents.c: - In principle, the digest capability of rpm fd currently in rpmio_internal.h should in fact be public, it just needs a saner API (I don't recall the exact details but there was something in there that is not acceptable for a public API at all) - Working with fundamental rpm package elements (lead, signature, header and payload) would seem like a fairly reasonable thing to be able to do with librpm. (Some of) the existing internal API's would not make sense to expose as-is, but in principle opening that up to a degree would be welcome. They were closed off back in the day because they exposed far too much crazy internals, but for example rpmlead.h is probably quite close to exposable again. ... which AFAICS leaves just the hashing bits, which is something I don't see us exposing in the API (simply because it's a rather special piece and not just a header you'd make available), but that's also by far the easiest part to replace with something else. -- 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/pull/1470#issuecomment-773242323___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Dynamic Spec generation (#1485)
And yeah, docs + a test-case or two needed. Once that is there we can do a fine-comb review, but generally this is so remarkably tiny amount of code that I wouldn't expect any major issues there. -- 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/pull/1485#issuecomment-773216642___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Dynamic Spec generation (#1485)
@pmatilai commented on this pull request.
> @@ -1118,3 +1146,25 @@ rpmSpec rpmSpecParse(const char *specFile,
> rpmSpecFlags flags,
{
return parseSpec(specFile, flags, buildRoot, 0);
}
+
+rpmRC parseGeneratedSpecs(rpmSpec spec)
+{
+
+ARGV_t argv = NULL;
+int argc = 0;
+int i;
+
+char * specPattern = rpmGenPath("%{u2p:%{_builddir}}", spec->buildSubdir,
"__rpmbuild_*.specpart");
"__rpmbuild_*.specpart" still looks quite the eyesore to me. These are not rpm
internal things, but files we expect others to produce. I'd think "*.specpart"
would be enough to differentiate from other stuff.
Also there's still the option of creating a special directory (".rpmbuild" or
such in the builddir) which could be used for such things, including but not
limited to debuginfo filelists, to avoid cluttering the main build directory
(that gets requested separately every now and then). Such a thing doesn't have
to be part of this PR, but should need to be done before a public release.
--
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/pull/1485#pullrequestreview-583255087___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
