tarball signing

[Harald Sitter]

On Sun, Aug 7, 2016 at 9:01 PM, David Faure <faure at kde.org> wrote:
> On mercredi 15 juin 2016 12:53:23 CEST Andre Heinecke wrote:
>> I'm using agent-forwarding through socat for that reason:
>>
>> Here is an example how I connect to <myserver>. The last command is
>> executed after ssh on the server.
>>
>> (while true; do socat TCP-LISTEN:16668,bind=127.0.0.1
>> UNIX-CONNECT:/home/aheinecke/.gnupg/S.gpg-agent.extra; done) & ssh
>> -R16668:localhost:16668 <myserver>
>> (while true; do  socat
>> UNIX-LISTEN:$HOME/.gnupg/S.gpg-agent,unlink-close,unlink-early
>> TCP4:localhost:16668; done) &
>
> So, I lost a few more hours on this, and still no go.
>
> $ (while true; do socat TCP-LISTEN:16668,bind=127.0.0.1 UNIX-CONNECT:
> $HOME/.gnupg/S.gpg-agent-extra; done) &
>
> (my local config has "-extra", while yours has ".extra")
>
> $ ssh -R16668:localhost:16668 scripty at l10n.kde.org
>
> scripty at rosetta ~ $ (while true; do  socat UNIX-LISTEN:$HOME/.gnupg/S.gpg-
> agent,unlink-close,unlink-early TCP4:localhost:16668; done) &
>
> All good until here, but:
>
> scripty at rosetta ~ $ gpg-connect-agent
> gpg-connect-agent: error sending standard options: Unknown error code
>
> scripty at rosetta ~ $ gpg2 --output /dev/null --sign -u 0x09B06E10  /dev/null
> gpg: skipped "0x09B06E10": No secret key
>
> Sigh.
>
> The server has OpenSSH_6.0p1, gpg (GnuPG) 2.0.19 and socat 1.7.1.3-1.4.

So I read up on this a bit and the way I see it this won't ever fly
with gpg<2.1 because in earlier versions the signing would always hit
the keyring [1] file on-disk. So, this is actually a two part problem:

- you need an agent socket forward from localhost to remote (openssh
6.7+ or manual socat socket forward [2])
- keyring needs to be available on remote (gpg2.1+ to forward keyring
itself via agent socket)

That said, you *could* copy your secring to the server to bypass
problem number 2. Why the manual socat socket failed for you I am not
sure as it works fine for me. It might be that a tiny bit went wrong
along the way, the socat method is fairly fragile. At any rate, I
think copying secrings around is a bit daft so the socket forwarding
is really the less concerning problem here.

IMO options at this point are:

1. Move release tarballing from rosetta to a server/container with
gpg2.1 (ideally this would be an ephemeral server in the cloud to give
less targetted attack surface)
2. Use a joint key that lives on rosetta until rosetta migrates to a
system with gpg2.1 at which point the agent forwarding can be
re-evaluated
3. Copy secrings (ugh) and use socat forwarded agent

I think option 2 would be perfectly acceptable as a stop-gap if you
need to stay on rosetta, after all, if one were to compromise the
server, one could poison the tarballs during creation and an off-site
signing key won't help much with that.

On a related note, we maybe should have a talk about not doing
tarballs on a general purpose server that isn't super hardened :P

[1] https://www.gnupg.org/faq/whats-new-in-2.1.html#nosecring
[2] http://www.openssh.com/txt/release-6.7
 * ssh(1), sshd(8): Add support for Unix domain socket forwarding.
   A remote TCP port may be forwarded to a local Unix domain socket
   and vice versa or both ends may be a Unix domain socket.

HS