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:

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

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,

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