tarball signing

[Harald Sitter]

quick guide

https://gist.github.com/apachelogger/4aa69ad0637feedb330b3fadc7adea3a

with openssh 6.7 and gpg 2.1 it really is this simple (do note that
gpg2.1 needs to be on server and client!)

On Mon, Sep 12, 2016 at 12:33 PM, Harald Sitter <sitter at kde.org> wrote:
> On Sat, Sep 10, 2016 at 1:26 PM, David Faure <faure at kde.org> wrote:
>> On lundi 8 août 2016 17:07:41 CEST Harald Sitter wrote:
>>> 1. Move release tarballing from rosetta to a server/container with
>>> gpg2.1
>>
>> So, now we are trying this.
>>
>> Partial success, ssh says
>> "remote forward success"
>> and running gpg-connect-agent on the server works
>>  (and it triggers debug output in the ssh-forwarding terminal).
>>
>> However any gpg2 command on the server doesn't seem to use the agent.
>> --detach-sign leads to "No secret key"
>> --list-keys and --list-secret-keys show nothing.
>>
>> I added use-agent to ~/.gnupg/gpg.conf (but I think that's an outdated option
>> anyway), and I set default-key there, no improvement
>> ("gpg: all values passed to '--default-key' ignored", googling says this is a
>> consequence of "no secret key").
>
> Documentation is fairly lackluster, but from poking around I'd say
> that you need to add your public key on the server's keyring.
> Specifically [1] talks about private keys coming out of the agent
> while public ones come out of the keyring, supposedly gpg would first
> check if it even has a public key though, and in fact that what it
> looks like with debugging.
>
> I set my agent into `debug-level guru`, reload, forward, when
> reloading from the remote via `gpg-connect-agent reloadagent /bye` I
> see it correctly hitting the agent. When using gpg2 on the remote to
> sign or encrypt I do not see it hitting the local agent UNTIL I add my
> public key.
>
> example:
> https://gist.github.com/apachelogger/1347ffe9508e0c5be163d05827a97844
>
> So, assuming the socket forward works and `gpg-connect-agent
> reloadagent /bye` works from the remote, only three things come to
> mind that can be wrong:
>
> a) public key not available
> b) the remote server session actually has an agent running (which
> would be weird, but given gpg2 auto-starts an agent if it can't find a
> socket it's not impossible)
> c) no GUI pinentry is used. specifically when the agent would use
> curses pinentry it won't work since the prompt is on the local machine
> in whatever tty it was originally forked from (if any) this results in
> temporarily stuck gpg2 on remote though.
>
> On a related note gpg2 --list-secret-keys will not actually list the
> key UNLESS the public key is available.
>
> [1] https://www.gnupg.org/faq/whats-new-in-2.1.html#nosecring
>
> HS