Oh no, not another debuginfo issue... :see_no_evil:
But okay, that new escaped global assumes that %debug_package is always invoked
from the specpart thing. I didn't expect anything to manually invoke
%debug_package except to override it, but of course something does - of course
it does.
So
Why are the following two test cases expected to fail? I see that the test case
is introduced because of
https://github.com/rpm-software-management/rpm/issues/1800. I think people
expect to see that the test case is successfully executed (that is, "missing
/usr/bin/hello" is displayed in the co
Hashing by keyid is not an issue, assuming it to be an unique identifier is. We
can teach the keyring to expect multiple keys per keyid instead, nothing in the
API deals with keyids so this should be largely an internal matter. The
gpg-pubkey entries are a bigger and more visible issue.
--
Rep
It looks like https://translate.fedoraproject.org/projects/rpm/rpm-l10n/en/ is
using an up to date .pot file, but, for example,
https://translate.fedoraproject.org/projects/rpm/rpm-l10n/pl/ is not. I guess
something is not quite right with RPM’s Weblate configuration?
--
Reply to this email di
While RC1 just barely cooled off, a number of QoL fixes have landed upstream,
some of which are too useful to miss the 4.20.0 window, so here goes RC2. This
is the final planned RC so if no significant issues are found, we'll declare it
final in the coming weeks.
Most notably in this release,
While RC1 just barely cooled off, a number of QoL fixes have landed upstream,
some of which are too useful to miss the 4.20.0 window, so here goes RC2. This
is the final planned RC so if no significant issues are found, we'll declare it
final in the coming weeks.
Most notably in this release, "%a
It's a different kind of invasive if the output keeps changing.
One important thing here is that there needs to be a clear and easy mapping
from the message(s) to what we import to the database, and vice versa.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-softwa
There's another option: we use fingerprints when available and long key IDs
otherwise. I think this would be a less invasive change. What do you think?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3292#issuecomment-2340504380
You are
We want to move to full fingerprint sure, but since it appears we can't do that
without changes to rpm-sequoia (and the legacy parser) we might as well do this
as an interim step to find out what exactly (if anything) breaks. It'll be a
good while before the change (in either shape) hits the end
Merged #3289 into rpm-4.20.x.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3289#event-14197455309
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
That still prevents signing v4 content in FIPS mode, which seems somehow
backwards.
I don't think this is an urgent issue by any means, just an ugly wart that
we'll want to deal with somehow going forward. Being explicit about it would be
a start anyhow, the current silent behavior is nasty.
-
#3280 is good to have in there to make signing with Sequoia nicer - that works
fine in 4.20 already if you just configure it just so.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3289#issuecomment-2340363632
You are receiving this beca
Internally it looks like most places are just using the Key ID. Especially the
rpmkeyring is using it as a key in the hash of all Pubkeys. If we don't have
any hope to move that to Fingerprints as the v3 signatures won't offer them
anyway, we might need to go down another route and just verify s
This is only a one-liner config change but with rather huge consequences.
Details in the commits but this will render rpm content built with older than
v4.14 unverifiable by digest only, and thus uninstallable, *by default*.
Such content can still be verified by signatures though, so once we fli
> I am currently still digging through the backends to see what would be needed
> to get them.
The relevant function is `pgpDigParamsSignID`. Unfortunately, v3 signature
packets don't include the fingerprint, but only the (long) key ID. In
practice, this is only a hint: we only know that the
Thanks for the detailed explanation, @pmatilai.
> If MD5 verification is disabled, then we'll merrily verify and sign a package
> with corrupt MD5 hash, because that hash just isn't interesting to us
What about refusing to sign if a disabled element is present? That is, if the
package has an M
If you are considering breaking the output format, then I would strongly
encourage you to just use the full fingerprint.
A key ID is only 64-bits. Happily, the security of key IDs does not depend on
collision resistance, [which has already been demonstrated to be
broken](https://nullprogram.co
OK, sketched a patch for moving from short to long Key IDs in the messages:
#3292. This is trivial to do but may be not trivial to deal with.
Moving to Fingerprints is not quite as trivial. We do have the means to get
Fingerprints from PGP keys but so far we lack that for signatures. I am
curre
Yeah, there were many test & docs commits which aren't strictly necessary but
then, won't hurt either.
Except maybe #3280 isn't something we need in 4.20 right now, it also refactors
stuff a bit, but it'll make backporting easier in this space, I guess.
--
Reply to this email directly or view
Here how dropping the Short PGP KEy IDs in favor of long ones would look like.
We still need to discuss if this really is a change we want in this magnitue or
if we need to keep the old behavior at some places.
You can view, comment on, or merge this pull request online at:
https://github.com/
Closed #3272 as completed via #3287.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/3272#event-14196505993
You are receiving this because you are subscribed to this thread.
Message ID:
___
R
Merged #3287 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3287#event-14196505677
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint mail
@pmatilai approved this pull request.
That was a few more commits than I thought it would be, but some of the
otherwise smallish fixes were multiple commits and then pulling these (like the
CI update) does make sense. So, looks fine to me.
--
Reply to this email directly or view it on GitHub
That's basically what it does (refuse to sign if verification fails), but
things get weird when you start disabling elements. I ran into this when
disabling the verification of MD5 digests, related to #1292.
If MD5 verification is disabled, then we'll merrily verify and sign a package
with cor
If a signature header element is corrupted, otherwise invalid, or violates a
policy, then the signer probably shouldn't be signing it. How about the
following: if there are any signature header elements that can't be verified,
`rpmsign` should complain and refuse to generate a sign.
--
Reply
Signing can leave an invalid digest in the package if we're not verifying it,
this seems broken:
Steps to reproduce:
1. take hello-2.0-1.x86_64.rpm from the test-suite and corrupt its md5 hash in
the signature header with `dd if=/dev/zero of=hello-2.0-1.x86_64.rpm
conv=notrunc bs=1 seek=333 cou
26 matches
Mail list logo
