tarball signing

[Harald Sitter]

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