tarball signing

Harald Sitter sitter at kde.org
Mon Sep 12 10:43:23 UTC 2016

quick guide


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

More information about the release-team mailing list