Re: [Rpm-maint] [rpm-software-management/rpm] Binary PGP keys cannot be imported (Issue #2689)

2023-10-04 Thread Panu Matilainen
Oh right, so there was a concrete reason for not allowing binary certificates 
in the current API.

Wherever new APIs are needed, just do what makes most sense to you. No reason 
to hang with the old ad-hoc API and its naming.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2689#issuecomment-1746378294
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] Binary PGP keys cannot be imported (Issue #2689)

2023-10-03 Thread Neal H. Walfield
I think we need to introduce a new interface.

`rpmkeys` imports keys using [the `doImport` 
function](https://github.com/rpm-software-management/rpm/blob/1c98b67911e19a5f92c7fa4492aaa1000a06edad/lib/rpmchecksig.c#L27).

That function looks for ASCII armor blocks, and the uses 
[`pgpParsePkts`](https://github.com/rpm-software-management/rpm/blob/master/rpmio/rpmpgp_internal.c#L1331)
 to parse the certificate.  `pgpParsePkts` takes a NUL-terminated string as 
input.

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

This means that even if we were willing to change the semantics of the 
function, we can't because a binary OpenPGP packets may contain embedded NULs.

As such, we need a new interface, in which the length is passed explicitly.  
Perhaps:

```
pgpArmor pgpParsePkts2(const uint8_t *maybe_armor, size_t maybe_armor_len, 
uint8_t ** pkt, size_t * pktlen);
```

Since we are parsing the data anyway in order to figure out its type, I'd 
rather just immediately return an array of `PgpDigParamsObj`, one for each 
object found.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2689#issuecomment-1746176336
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] Binary PGP keys cannot be imported (Issue #2689)

2023-10-03 Thread Neal H. Walfield
That behavior was inherited from the internal backend.  I don't see a reason 
not to support raw (not ASCII armored) certificates. We have to make sure 
embedded null characters are correctly handled, though. (I need to check the 
API).

-- 
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2689#issuecomment-1744940566
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] Binary PGP keys cannot be imported (Issue #2689)

2023-10-03 Thread Panu Matilainen
Rpm has always intentionally rejected non-ASCII formats, so in that sense it's 
a feature.
I suppose the Sequoia backend could trivially support binary formats too, I 
don't have any strong opinion on this.

@nwalfield , thoughts?

-- 
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2689#issuecomment-1744898600
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