Re: [Rpm-maint] [rpm-software-management/rpm] OpenPGP: Function `pgpParsePkts` supports only "PGP PUBLIC KEY BLOCK" block, "PGP SIGNATURE" is needed (Issue #2512)

2023-11-29 Thread Panu Matilainen
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 mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


Re: [Rpm-maint] [rpm-software-management/rpm] OpenPGP: Function `pgpParsePkts` supports only "PGP PUBLIC KEY BLOCK" block, "PGP SIGNATURE" is needed (Issue #2512)

2023-11-29 Thread Panu Matilainen
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 differences 
in the backends as long as the internal one is there, so it seems to me the 
sooner we get rid of it the better it is for everybody, ultimately.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2512#issuecomment-1831737612
You are receiving this because you are subscribed to this thread.

Message ID: ___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


Re: [Rpm-maint] [rpm-software-management/rpm] OpenPGP: Function `pgpParsePkts` supports only "PGP PUBLIC KEY BLOCK" block, "PGP SIGNATURE" is needed (Issue #2512)

2023-05-21 Thread Jaroslav Rohel
@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` which internally calls `pgpParsePkts` to 
parse the ASCII armored OpenPGP signature. 

I created the code based on the description in the "rpmgpg.h" header file and a 
bit of librpm reverse engineering. It's not very nice, but somehow it works. 
The code also implements a keyring.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2512#issuecomment-1556255299
You are receiving this because you are subscribed to this thread.

Message ID: ___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


Re: [Rpm-maint] [rpm-software-management/rpm] OpenPGP: Function `pgpParsePkts` supports only "PGP PUBLIC KEY BLOCK" block, "PGP SIGNATURE" is needed (Issue #2512)

2023-05-21 Thread Jaroslav Rohel
@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]
name=google-chrome
baseurl=https://dl.google.com/linux/chrome/rpm/stable/x86_64
skip_if_unavailable=True
gpgcheck=1
gpgkey=https://dl.google.com/linux/linux_signing_key.pub
enabled=1
repo_gpgcheck=1
```
`gpgkey` is a URL to a file containing multiple blocks of ASCII armored public 
keys (there can be multiple URLs.)
The repository contains a "repomd.xml" file and a "repomd.xml.asc" file. **The 
"repomd.xml.asc" file is an ASCII armored OpenPGP signature that librepo needs 
to load in order to verify the "repomd.xml" file.**

Librepo uses GpgMe. We now have a high priority to remove the dependency on 
GpgMe. That's why I created a new implementation in the librepo that uses the 
librpm API instead of GpgMe. Now it works (with some problems that I described 
in issues, but it works).
If the `pgpParsePkts` function does not support ASCII armored signature 
parsing, how do I load it in the librepo? New better function? Okay, but we 
need it quickly.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2512#issuecomment-1556250287
You are receiving this because you are subscribed to this thread.

Message ID: ___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


Re: [Rpm-maint] [rpm-software-management/rpm] OpenPGP: Function `pgpParsePkts` supports only "PGP PUBLIC KEY BLOCK" block, "PGP SIGNATURE" is needed (Issue #2512)

2023-05-21 Thread Jaroslav Rohel
@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 returned enum.
Or something like "NOT_IMPLEMENTED" is also understandable. But 
`PGPARMOR_NONE`?. I deduce from the description of the function that this is 
not the expected result for the signature.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2512#issuecomment-1556243863
You are receiving this because you are subscribed to this thread.

Message ID: ___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


Re: [Rpm-maint] [rpm-software-management/rpm] OpenPGP: Function `pgpParsePkts` supports only "PGP PUBLIC KEY BLOCK" block, "PGP SIGNATURE" is needed (Issue #2512)

2023-05-19 Thread Neal H. Walfield
@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:
https://github.com/rpm-software-management/rpm/issues/2512#issuecomment-1554609544
You are receiving this because you are subscribed to this thread.

Message ID: ___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


Re: [Rpm-maint] [rpm-software-management/rpm] OpenPGP: Function `pgpParsePkts` supports only "PGP PUBLIC KEY BLOCK" block, "PGP SIGNATURE" is needed (Issue #2512)

2023-05-19 Thread Michael Schroeder
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 view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2512#issuecomment-1554578304
You are receiving this because you are subscribed to this thread.

Message ID: ___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


Re: [Rpm-maint] [rpm-software-management/rpm] OpenPGP: Function `pgpParsePkts` supports only "PGP PUBLIC KEY BLOCK" block, "PGP SIGNATURE" is needed (Issue #2512)

2023-05-19 Thread Jaroslav Rohel
@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, contains an entry for the signature `PGPARMOR_SIGNATURE` (and 
other entries). And the function is described: "Parse armored OpenPGP packets 
from a file." And it returns "type of armor found".
In fact, it only parses one type `PGPARMOR_PUBKEY`.

```
/** \ingroup rpmpgp
 * Parse armored OpenPGP packets from a file.
 * @param fnfile name
 * @param[out] pkt  dearmored OpenPGP packet(s) (malloced)
 * @param[out] pktlen   dearmored OpenPGP packet(s) length in bytes
 * @return  type of armor found
 */
pgpArmor pgpReadPkts(const char * fn, uint8_t ** pkt, size_t * pktlen);
```

```
PGPARMOR_MESSAGE=  1, /*!< MESSAGE */
PGPARMOR_PUBKEY =  2, /*!< PUBLIC KEY BLOCK */
PGPARMOR_SIGNATURE  =  3, /*!< SIGNATURE */
PGPARMOR_SIGNED_MESSAGE =  4, /*!< SIGNED MESSAGE */
PGPARMOR_FILE   =  5, /*!< ARMORED FILE */
PGPARMOR_PRIVKEY=  6, /*!< PRIVATE KEY BLOCK */
PGPARMOR_SECKEY =  7  /*!< SECRET KEY BLOCK */
```

-- 
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2512#issuecomment-1554461685
You are receiving this because you are subscribed to this thread.

Message ID: ___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


Re: [Rpm-maint] [rpm-software-management/rpm] OpenPGP: Function `pgpParsePkts` supports only "PGP PUBLIC KEY BLOCK" block, "PGP SIGNATURE" is needed (Issue #2512)

2023-05-19 Thread Michael Schroeder
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 subscribed to this thread.

Message ID: ___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


Re: [Rpm-maint] [rpm-software-management/rpm] OpenPGP: Function `pgpParsePkts` supports only "PGP PUBLIC KEY BLOCK" block, "PGP SIGNATURE" is needed (Issue #2512)

2023-05-18 Thread Demi Marie Obenour
> 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 bugs that almost certainly won’t be 
fixed.  To give just one example, revocation handling is not implemented at all.

> Or will an external implementation ("rpm-sequouia" backend) be required in 
> future versions (e.g. next Fedora)?

It’s already the default in Fedora 38.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2512#issuecomment-1553680881
You are receiving this because you are subscribed to this thread.

Message ID: ___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


[Rpm-maint] [rpm-software-management/rpm] OpenPGP: Function `pgpParsePkts` supports only "PGP PUBLIC KEY BLOCK" block, "PGP SIGNATURE" is needed (Issue #2512)

2023-05-18 Thread Jaroslav Rohel
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 works with 
"rpm-sequoia" backend. The problem is with internal librpm implementation.

Is there a plan to add support for ASCII armored PGP signatures to librpm's 
internal implementation? Or will an external implementation ("rpm-sequouia" 
backend) be required in future versions (e.g. next Fedora)?

-- 
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2512
You are receiving this because you are subscribed to this thread.

Message ID: ___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint