GPG signing RPM packages : must not have subkeys

GPG signing RPM packages : must not have subkeys

[Loic Dachary]

Hi Martin,

It turns out that the key created by 

KEY="$HOME/.ceph-workbench/release-team-key.asc"
if ! test -f $KEY ; then
  printf "Key-Type: 1\nKey-Length: 2048\nSubkey-Type: 1\nSubkey-Length: 2048\nName-Real: Release Team\nName-Email: contact@ceph.com\nExpire-Date: 0" | GNUPGHOME=~/.ceph-workbench gpg --batch --gen-key
  GNUPGHOME=~/.ceph-workbench gpg --export --armor > $KEY
fi

cannot be used to verify RPM packages: rpm -K on the signed package claims the 69C8876E key is missing. It turns out to be related to the subkey. 

--------------------------------------------
pub   2048R/B8F1ACED 2016-03-11
      Key fingerprint = 7FEB E845 6F19 153B AAFC  2810 4597 2ACD B8F1 ACED
uid                  A Contributor <generous@ceph.com>
sub   2048R/69C8876E 2016-03-11

rpm -K complains that the 69C8876E key is not available. After removing the subkey 69C8876E with gpg --edit-key and signing the RPM again, rpm -K is happy. This does not make any sense to me and I suspect there is an expert explanation that justify this behavior. The sensible way out seems to create a passwordless key with no subkey to avoid that problem. Do you happen to know how that can be done ?

Cheers

-- 
Loïc Dachary, Artisan Logiciel Libre
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: GPG signing RPM packages : must not have subkeys

[Martin Palma]

If I remember it right I read somewhere that verification with
sub-keys is not implemented in rpm.

To create a passwordless key with no subkey you can simple leave out
the Subkey-Type and Subkey-Length I think:


KEY="$HOME/.ceph-workbench/release-team-key.asc"
if ! test -f $KEY ; then
  printf "Key-Type: 1\nKey-Length: 2048\nName-Real: Release
Team\nName-Email: contact@ceph.com\nExpire-Date: 0" |
GNUPGHOME=~/.ceph-workbench gpg --batch --gen-key
  GNUPGHOME=~/.ceph-workbench gpg --export --armor > $KEY
fi

Can you verify that?

Best,
Martin

On Tue, Mar 15, 2016 at 6:28 PM, Loic Dachary <loic@dachary.org> wrote:
> Hi Martin,
>
> It turns out that the key created by
>
> KEY="$HOME/.ceph-workbench/release-team-key.asc"
> if ! test -f $KEY ; then
>   printf "Key-Type: 1\nKey-Length: 2048\nSubkey-Type: 1\nSubkey-Length: 2048\nName-Real: Release Team\nName-Email: contact@ceph.com\nExpire-Date: 0" | GNUPGHOME=~/.ceph-workbench gpg --batch --gen-key
>   GNUPGHOME=~/.ceph-workbench gpg --export --armor > $KEY
> fi
>
> cannot be used to verify RPM packages: rpm -K on the signed package claims the 69C8876E key is missing. It turns out to be related to the subkey.
>
> --------------------------------------------
> pub   2048R/B8F1ACED 2016-03-11
>       Key fingerprint = 7FEB E845 6F19 153B AAFC  2810 4597 2ACD B8F1 ACED
> uid                  A Contributor <generous@ceph.com>
> sub   2048R/69C8876E 2016-03-11
>
> rpm -K complains that the 69C8876E key is not available. After removing the subkey 69C8876E with gpg --edit-key and signing the RPM again, rpm -K is happy. This does not make any sense to me and I suspect there is an expert explanation that justify this behavior. The sensible way out seems to create a passwordless key with no subkey to avoid that problem. Do you happen to know how that can be done ?
>
> Cheers
>
> --
> Loïc Dachary, Artisan Logiciel Libre
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: GPG signing RPM packages : must not have subkeys

[Loic Dachary]

Hi Martin,

It works indeed ! Thanks :-)

Cheers

On 15/03/2016 20:25, Martin Palma wrote:
> If I remember it right I read somewhere that verification with
> sub-keys is not implemented in rpm.
> 
> To create a passwordless key with no subkey you can simple leave out
> the Subkey-Type and Subkey-Length I think:
> 
> 
> KEY="$HOME/.ceph-workbench/release-team-key.asc"
> if ! test -f $KEY ; then
>   printf "Key-Type: 1\nKey-Length: 2048\nName-Real: Release
> Team\nName-Email: contact@ceph.com\nExpire-Date: 0" |
> GNUPGHOME=~/.ceph-workbench gpg --batch --gen-key
>   GNUPGHOME=~/.ceph-workbench gpg --export --armor > $KEY
> fi
> 
> Can you verify that?
> 
> Best,
> Martin
> 
> On Tue, Mar 15, 2016 at 6:28 PM, Loic Dachary <loic@dachary.org> wrote:
>> Hi Martin,
>>
>> It turns out that the key created by
>>
>> KEY="$HOME/.ceph-workbench/release-team-key.asc"
>> if ! test -f $KEY ; then
>>   printf "Key-Type: 1\nKey-Length: 2048\nSubkey-Type: 1\nSubkey-Length: 2048\nName-Real: Release Team\nName-Email: contact@ceph.com\nExpire-Date: 0" | GNUPGHOME=~/.ceph-workbench gpg --batch --gen-key
>>   GNUPGHOME=~/.ceph-workbench gpg --export --armor > $KEY
>> fi
>>
>> cannot be used to verify RPM packages: rpm -K on the signed package claims the 69C8876E key is missing. It turns out to be related to the subkey.
>>
>> --------------------------------------------
>> pub   2048R/B8F1ACED 2016-03-11
>>       Key fingerprint = 7FEB E845 6F19 153B AAFC  2810 4597 2ACD B8F1 ACED
>> uid                  A Contributor <generous@ceph.com>
>> sub   2048R/69C8876E 2016-03-11
>>
>> rpm -K complains that the 69C8876E key is not available. After removing the subkey 69C8876E with gpg --edit-key and signing the RPM again, rpm -K is happy. This does not make any sense to me and I suspect there is an expert explanation that justify this behavior. The sensible way out seems to create a passwordless key with no subkey to avoid that problem. Do you happen to know how that can be done ?
>>
>> Cheers
>>
>> --
>> Loïc Dachary, Artisan Logiciel Libre
> --
> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

-- 
Loïc Dachary, Artisan Logiciel Libre
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: GPG signing RPM packages : must not have subkeys

[Martin Palma]

Perfekt!! :-)

On Wed, Mar 16, 2016 at 8:55 AM, Loic Dachary <loic@dachary.org> wrote:
> Hi Martin,
>
> It works indeed ! Thanks :-)
>
> Cheers
>
> On 15/03/2016 20:25, Martin Palma wrote:
>> If I remember it right I read somewhere that verification with
>> sub-keys is not implemented in rpm.
>>
>> To create a passwordless key with no subkey you can simple leave out
>> the Subkey-Type and Subkey-Length I think:
>>
>>
>> KEY="$HOME/.ceph-workbench/release-team-key.asc"
>> if ! test -f $KEY ; then
>>   printf "Key-Type: 1\nKey-Length: 2048\nName-Real: Release
>> Team\nName-Email: contact@ceph.com\nExpire-Date: 0" |
>> GNUPGHOME=~/.ceph-workbench gpg --batch --gen-key
>>   GNUPGHOME=~/.ceph-workbench gpg --export --armor > $KEY
>> fi
>>
>> Can you verify that?
>>
>> Best,
>> Martin
>>
>> On Tue, Mar 15, 2016 at 6:28 PM, Loic Dachary <loic@dachary.org> wrote:
>>> Hi Martin,
>>>
>>> It turns out that the key created by
>>>
>>> KEY="$HOME/.ceph-workbench/release-team-key.asc"
>>> if ! test -f $KEY ; then
>>>   printf "Key-Type: 1\nKey-Length: 2048\nSubkey-Type: 1\nSubkey-Length: 2048\nName-Real: Release Team\nName-Email: contact@ceph.com\nExpire-Date: 0" | GNUPGHOME=~/.ceph-workbench gpg --batch --gen-key
>>>   GNUPGHOME=~/.ceph-workbench gpg --export --armor > $KEY
>>> fi
>>>
>>> cannot be used to verify RPM packages: rpm -K on the signed package claims the 69C8876E key is missing. It turns out to be related to the subkey.
>>>
>>> --------------------------------------------
>>> pub   2048R/B8F1ACED 2016-03-11
>>>       Key fingerprint = 7FEB E845 6F19 153B AAFC  2810 4597 2ACD B8F1 ACED
>>> uid                  A Contributor <generous@ceph.com>
>>> sub   2048R/69C8876E 2016-03-11
>>>
>>> rpm -K complains that the 69C8876E key is not available. After removing the subkey 69C8876E with gpg --edit-key and signing the RPM again, rpm -K is happy. This does not make any sense to me and I suspect there is an expert explanation that justify this behavior. The sensible way out seems to create a passwordless key with no subkey to avoid that problem. Do you happen to know how that can be done ?
>>>
>>> Cheers
>>>
>>> --
>>> Loïc Dachary, Artisan Logiciel Libre
>> --
>> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
>
> --
> Loïc Dachary, Artisan Logiciel Libre
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html