[arch-dev-public] sign packages on alderaan

[Dan McGee]

On Fri, Nov 11, 2011 at 5:56 PM, Ionut Biru <ibiru at archlinux.org> wrote:
> On 11/12/2011 01:43 AM, Ray Rashif wrote:
>> On 12 November 2011 07:35, Dan McGee <dpmcgee at gmail.com> wrote:
>>> On Fri, Nov 11, 2011 at 5:31 PM, Ray Rashif <schiv at archlinux.org> wrote:
>>>> On 31 October 2011 02:06, Florian Pritz <bluewind at xinu.at> wrote:
>>>>> So far the only solution is to download the finished package, sign it
>>>>> locally using gpg --detach-sign <file> and then uploading the signature
>>>>> back to pkgbuild.com so commitpkg will find it.
>>>>
>>>> Did something change WRT this workflow now? I'm getting
>>>> signature-incorrect from commitpkg. I did sign like this 2 times
>>>> before (opencv and cinelerra-cv), so it did work recently. gpg
>>>> --verify outputs:
>>>>
>>>> gpg: Can't check signature: public key not found
>>>>
>>>> But this is normal, and the public key was not there for the previous
>>>> 2 times. Or was gpg --verify not there in commitpkg before? Do I now
>>>> need to import my public key on alderaan?
>>>
>>> Is your key in your keychain on alderaan? Probably not from what this
>>> looks like. Easy to check- `gpg --list-keys 0xfoobar`.
>>>
>>> -Dan
>>>
>>
>> Nope. That was what I was asking - whether I need to add it. The last
>> 2 times that I pushed signed packages from alderaan I didn't do
>> anything gpg-related remotely.
>>
>> Anyway, imported the key now so all is good again.
>>
>>
>> --
>> GPG/PGP ID: C0711BF1
>
> don't import any key on alderaan.

Hmm?

He is trying to *verify*, meaning he needs his *public* key. This has
nothing to do with signing or private keys. It make a heck of a lot
more sense bandwidth-wise for him to upload the signature file to
alderaan than upload both the package and signature from his local
machine, so why should he not be able to do that? The `gpg --verify`
call is there to make sure developers don't accidentally upload
mismatched packages and corresponding signature files, which could
easily happen when doing test builds and --nosign, etc.

-Dan