Re: GPG signing RPM packages : must not have subkeys

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Perfekt!! :-)

On Wed, Mar 16, 2016 at 8:55 AM, Loic Dachary <loic@xxxxxxxxxxx> 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@xxxxxxxx\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@xxxxxxxxxxx> 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@xxxxxxxx\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@xxxxxxxx>
>>> 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@xxxxxxxxxxxxxxx
>> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [CEPH Users]     [Ceph Large]     [Information on CEPH]     [Linux BTRFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux