Yup. There's no promise that any old rpm version will be able to handle v6
packages. Rpm is backwards, not forwards compatible.
Quoting the [roadmap
announcement](https://github.com/rpm-software-management/rpm/discussions/2015):
> It also means that the last v4 release is expected to handle v6
Nope. Rpm is better off not knowing the damnest thing about OpenPGP format. An
external helper would be considered a stop-gap measure for those
unable/unwilling to use rpm-sequoia for some reason, nothing more.
Another possibility (and these aren't exclusive) is to split the existing
parser to
If RPM goes this route, it should keep a small part of the internal parser.
Specifically, it should keep the checks that the signature is a single OpenPGP
signature packet of the correct type. This is a workaround for a known and
unfixed denial-of-service vulnerability in GnuPG that I
I've filed https://github.com/rpm-software-management/rpm/issues/2423
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2368#issuecomment-1462417844
You are receiving this because you are subscribed to this thread.
Message ID:
@dmnks pushed 56 commits.
53733da3609df63557c035717faa18249cc6523e Make %_smp_mflags build rather than
parse time determined
df6359235215095f6a93993393320f59aad2cec8 Fix rpmkeys type confusion test.
8c7029da19ffe724001be361456725374fa5e47e Enable malloc checking with random
perturb in the
OK, changes pushed, dropping the following ones:
b0c9b3d87 Calculate number of threads to use during build, not spec parse
d0867bcea Fix OpenMP enablement in librpmbuild (broken by cmake transition)
37ec18d86 Fix silent wait when missing input RPM package
The second one is a noop without the
This is a forwards compatibility issue with RPMv6 - existing versions of `rpm`
will fail to parse packages produced with a zeroed out "Lead" section.
https://github.com/rpm-software-management/rpm/blob/4afe2d14d33db82ccb41c0a8d5eb1a4db90762fc/lib/rpmlead.c#L98-L105
--
Reply to this email
> I'll have to reach out to the GCC maintainers to clarify what's going on
> there.
Reported upstream as https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109081
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2412#issuecomment-1462220351
Oh, and I'll also drop b0c9b3d87 since that's not needed to fix the intended
regression, as per #2344.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2406#issuecomment-1462018833
You are receiving this because you are subscribed to this
Should we also consider #2408?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2406#issuecomment-1461930609
You are receiving this because you are subscribed to this thread.
Message ID: ___
I went through another round of this at #2422. The bottom line is that rpmlog()
can get called in so many places that we can't control (Lua scriptlets, macros,
API users to name a few) that this can't be fixed by avoiding what hurts.
We need to make rpmlog() fork-safe, somehow.
--
Reply to
Closed #2422.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2422#event-8707023066
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint mailing list
Having gone through these, this doesn't feel any more right. And it isn't,
because rpmlog() can get called from multiple less obvious places like Lua
scriptlets, macros etc that can happen in any number of places. Not to mention
any users outside rpm itself.
This needs a different solution.
@pmatilai pushed 2 commits.
c4b38c696d76494461077d62f265c62901ba48c1 Fix rpmlog() getting called after
fork in rpmfcExec()
660c5cff390a7009faa6ba26370304c473cd39e9 Fix scriptlet execution calling
rpmlog() after fork
--
View it on GitHub:
I decided to go through the picks once again and *actually* view them from the
"is this an important bugfix" perspective, and removed a couple of less
important commits as a result, namely these:
c4eb357fe Drop a leftover mcheck.h include
4eb26a828 Drop redundant _GNU_SOURCE definitions from
@dmnks pushed 80 commits.
506d4e600de99a010884724b782b1538e51f66bf Permit building rpm from git without
pandoc
d964136eb221306cb3c1c2e0a2ce3bb06c295308 Add a handler for libselinux log
messages (RhBug:2123719, RhBug:2050774)
c5b73532e98cca1a00f0804da94a64c404d0cdb7 Split testing population
Not too late, really, it's actually just in time! Let's pick these `rpmsign`
fixes too, then, they seem to be important enough for some folks and are
regression fixes so typically a good choice for a maintenance update. Thanks
for the note, @eaon!
--
Reply to this email directly or view it on
@pmatilai pushed 1 commit.
8d8753de75894f301ec1489de82a047266199e12 Fix rpmlog() getting called after
fork in rpmfcExec()
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2422/files/b2e0747b59e78e928562792fd29b306fb319b6f8..8d8753de75894f301ec1489de82a047266199e12
You
Calling rpmlog() after fork is undefined behavior because of the locking it
does, and non-sensical as well, as any warnings and errors it catches end up in
the wrong process. Just print to stderr instead, and improve the messages while
at it: handle possible popt parse error separately, and
Commit 2d418ad3c11bcf0261d0022ac177d13284a8d5fb added a safety catch for
runaway children from package scriptlets, but we have many other ways to run
Lua scriptlets too, and runaway children are equally harmful in them all. Catch
them all centrally by wrapping lua_pcall() instead.
Besides
> Absolute symlinks are downright dangerous in combination with chrooted
> content. The absolute link okay inside the chroot of course, but have you
> never, ever looked at eg /var/lib/mock/ stuff without chrooting into it?
You mean that outside of chroot, they point to system locations? What
While we try to protect rpm from these footguns, it'd be better to not have
them at all.
rpm.execute() which we have for five years now is a far saner interface for
executing helpers, both to the user and rpm itself.
--
Reply to this email directly or view it on GitHub:
22 matches
Mail list logo
