On Dec 28, 2007, at 12:30 PM, Ralf S. Engelschall wrote:

> On Fri, Dec 28, 2007, Jeff Johnson wrote:
>
>> [...]
>> 1) PEM encoding is what gpg refers to as "armored"? Or are you  
>> chasing
>> X.509 certificate signing (which has been on my todo list for  
>> years, I
>> don't
>> know of any application other than gnutls that handles both OpenPGP
>> and X.509 certs).
>
> Yes, X.509 certs usually use PEM representation, too. But I just mean
> the PGP PEM format which is what GnuPG calls "armored" and produces  
> for
> instance with "gpg --clearsign <file>". The detached variant is what
> "gpg --detach-sign --armor <file>" produces:
>

Yah, but different BEGIN/END keyword markers in X.509 PEM than in  
OpenPGP
armoring. The base64 is easy, but the keywords need to be mapped onto  
what
was parsed.

> | $ echo "test" >test
>
> | $ gpg --detach-sign --armor --output - test
> | -----BEGIN PGP SIGNATURE-----
> | Version: GnuPG v2.0.8 (FreeBSD)
> |
> | iEYEABECAAYFAkd1MO8ACgkQbnRKy6nAnjAokACcC8V1LJmVRAXRoSfCAPDbzkFd
> | q94An0UAHHUuYNnbn7uaP/X6U4h7OKQh
> | =Z0YQ
> | -----END PGP SIGNATURE-----
>
> | $ gpg --clearsign --output - test
> | -----BEGIN PGP SIGNED MESSAGE-----
> | Hash: SHA1
> |
> | test
> | -----BEGIN PGP SIGNATURE-----
> | Version: GnuPG v2.0.8 (FreeBSD)
> |
> | iEYEARECAAYFAkd1MQAACgkQbnRKy6nAnjApEgCdHooiYVciNZKaVp4OycxNYraI
> | JUkAn0dhJV53vDZgWXxjnw18o/mhgv23
> | =vKXz
> | -----END PGP SIGNATURE-----
>
>> 2) If "cleartext" signing is what gpg refers to as "one-pass"
>> signatures, there's a slew of added complexity because of the need to
>> handle embedded compression within the one-pass signature.
>
> I don't know about the term "one-pass", but cleartext is the second
> variant above. But I think it is fully ok (and for my situation also
> fully sufficient) if we can verify the second variant above which is
> just a cleartext signature of a plain text file. There is no  
> compression
> or anything else involved.
>

Perfect.

Got it. Simple detached signature appended to plain text. The parser
in rpm will extract the detached PEM/armored concatenated piece  
easily. I've never
bothered to save the plain text yet in rpm, won't be hard.

>> [...]
>> Largely straightforward logic even if the side effects of the chosen
>> API are perhaps easier to implement with some flags instead.
>
> Feel free to adjust. I just wanted to give you the minimum requires
> functionality. The actual API style is arbitrary.
>
>>> 2. the "gnupg(<datafile>)[ = <fingerprint>]" implementation
>>>    should be changed to gnupg(<datafile>[,<sigfile>])[ =
>>>    [<pubkeyfile>:]<fingerprint>]" and implemented via a call to
>>>    rpmCheckPgpSignatureOnFile().
>>
>> Why change? Adding another name space is trivial ...
>
> Well, it would be backward-compatible, wouldn't it?
> But a different namespace is also ok, but which one?
>

Hehe, names is always hardest. I'm just reluctant to trash
already implemented functionality for Newer! Better! Bestest!
before anyone has actually used the original implementation.

Kinda like wiki's ;-)


>> There are also syntax issues with ',' (and other embedded white  
>> space),
>> and ':' tricking the data through the existing parseSpec()  
>> implementation.
>
> Yes, sorry, comma is bad, I know. Then use the colon as in:
> gnupg(<datafile>[:<sigfile>])[ = [<pubkeyfile>:]<fingerprint>]
>

Colons have some minor issues too "E:..." parsing. But as long
as not a digit string, colon's can be used in EVR.

>> [...]
>> Are you trying for signature verification of some/all package files
>> through Lua serialization into an arbitrary tag?
>> [...]
>
> No, I just need to on-the-fly verify a few text-files staying on the
> Nofilesystem. need to put anything into a tag or such a thing -- at
> least not to my current plans ;-)
>

Got it. I got a shot at implementing in rpm-5.0, we'll see ...

73 de Jeff