From kde-release-team Mon Aug 08 15:07:41 2016 From: Harald Sitter Date: Mon, 08 Aug 2016 15:07:41 +0000 To: kde-release-team Subject: Re: tarball signing Message-Id: X-MARC-Message: https://marc.info/?l=kde-release-team&m=147066890017564 On Sun, Aug 7, 2016 at 9:01 PM, David Faure 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 . 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 >> (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@l10n.kde.org > > scripty@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@rosetta ~ $ gpg-connect-agent > gpg-connect-agent: error sending standard options: Unknown error code > > scripty@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