Closed #2512 as completed.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2512#event-11095282424
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
Considering that the internal parser is on its way out, and changing
rpm-sequoia to reject data that the return values suggest the function
supports, breaking librepo in the process... I think the only reasonable thing
is to just leave it all as it is. There are and will be significant
@nwalfield
Here is the PR https://github.com/rpm-software-management/librepo/pull/275 . It
contains commit that moves the original implementation of OpenPGP using GpgMe
into "gpg_gpgme.c" file and creates a new based on librpm API in the
"gpg_rpm.c" file.
There is a function `check_signature`
@nwalfield
> Why does librepo need to parse signature files?
Librepo is used to download data from rpm repositories (metadata, packages,
...). Repository metadata can be signed with an OpenPGP signature. And librepo
can verify them.
Sample on an existing repository:
```
[google-chrome]
@mlschroe
Sorry, I'm not a great English speaker, but I assume that when the function is
described as `Parse armored OpenPGP packets from a file.` and returns `type of
armor found`, it will return `PGPARMOR_SIGNATURE` after finding the signature.
Especially when that value is part of the
@jrohel: Why does librepo need to parse signature files? Can you point me to
the code that relies on this behavior, please.
@mlschroe: I agree. rpm-sequoia probably should reject these signatures.
--
Reply to this email directly or view it on GitHub:
I dunno about that "fine" and "incomplete". You're asking to *remove* an extra
check in the internal pgp parser.
So maybe the sequoia code is incomplete.
Basically the API is missing a type argument to tell the parser if it should
test for a certain armor.
--
Reply to this email directly or
@mlschroe
In this case, sequoia is fine. But the internal implementation is incomplete.
But in my opinion, there was no pressure to complete the support. We used GpgMe
instead of this API.
Details:
The `pgpReadPkts` function returns the `pgpArmor` enum, which since its
creation in 2001,
I'd argue that either rpm-sequoia or the internal implementation should be
fixed. I'm not sure which is correct.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2512#issuecomment-1554228061
You are receiving this because you are
> Is there a plan to add support for ASCII armored PGP signatures to librpm's
> internal implementation?
Highly unlikely. The internal implementation is only for backwards
compatibility with environments that for some reason are not willing to use the
Sequoia implementation. It has known
I am preparing a new backend for OpenPGP support in librepo
https://github.com/rpm-software-management/dnf5/issues/438 . Instead of GpgMe,
it uses the librpm library API. The goal is to get rid of the dependency on
GpgMe.
I need support for loading ASCII armored PGP signatures. I found it
11 matches
Mail list logo
