On April 7, 2018 8:23:08 AM GMT+02:00, Pierre Neidhardt via aur-general wrote:

To perform the complete operation on soyuz, we need to forward the gpg-socket (and the SSH socket if different) to soyuz, which defeats the PGP / Web of Trust security model: for a person with root access to soyuz, the private key is only one passphrase away.

Thoughts?

Yes, truly defeats it. I explicitly do not recommend forwarding it to the build server. For not doing that, you will most likely need to download the final artifacts for signing. If I recall correctly we had a discussion on that topic with Bluewind, jelle and grazzolini and someone wanted to rephrase the section with better recommendations. Cheers, Levente

On 04/07/2018 07:55 AM, Levente Polyak via aur-general wrote:

On April 7, 2018 8:23:08 AM GMT+02:00, Pierre Neidhardt via aur-general wrote:

...

To perform the complete operation on soyuz, we need to forward the gpg-socket (and the SSH socket if different) to soyuz, which defeats the PGP / Web of Trust security model: for a person with root access to soyuz, the private key is only one passphrase away.

Thoughts?

Yes, truly defeats it. I explicitly do not recommend forwarding it to the build server. For not doing that, you will most likely need to download the final artifacts for signing. If I recall correctly we had a discussion on that topic with Bluewind, jelle and grazzolini and someone wanted to rephrase the section with better recommendations.

Cheers, Levente

I don't understand how it "defeats the PGP/Web of Trust model", if there is no way to get the key itself, and an attacker can only generate signatures, during a limited window of opportunity, *if* they can forge a valid request to *your* computer. I'm not sure how even the passphrase helps, not that an attacker should be able to exploit that in said limited window of opportunity... because from what I've seen of using the gpg-agent-extra forwarding, it tries to ask your gpg-agent for a signature, and then gpg-agent itself spawns the pinentry dialog *on your computer*. The only vulnerability I could see is if you have no passphrase (gpg-agent-extra IMHO should be smart enough to still ask yes/no for remote access) or you type in your password in a situation where it is the attacker's request, not your own. (But if you don't remember asking for it, why do you type your passphrase in? Or alternatively, why is failure to end up with a signature for what you wanted, not itself a red flag?) But I think the main issue with gpg forwarding was supposed to be losing your key to attacks which are not necessarily simultaneous with your SSH session... If you're really afraid of someone running as either your user, or some user with the power to hijack your SSH session, while you're trying to sign something, then they could just switch out your built files anyway. There's literally no solution there, except to build everything on your machine and not use soyuz at all. "clave" won't help either, because it's got the same fundamental problem of not actually being your trusted machine from beginning to end. -- Eli Schwartz Bug Wrangler and Trusted User

What's the best practice to disable password caching? Set the timeout to zero? Does anyone know if it's possible to have have a zero-timeout when on soyuz while having another timeout time locally? -- Pierre Neidhardt

Use the `ignore-cache-for-signing` option in gpg-agent. Unsure if you can enable this only for connections to soyuz.

But that's only for signing, so that won't do if I have subkeys used for other purposes under the same master key, right? -- Pierre Neidhardt

Morten Linderud writes:

What i have done now is to launch a second gpg-agent that only provides an -extra socket with no caching what so ever.

I thought of something along those lines. Can you detail the commands so that we can put that on the wiki? -- Pierre Neidhardt

On 04/08/2018 05:51 PM, Eli Schwartz via aur-general wrote:

On 04/08/2018 07:49 AM, Florian Pritz via aur-general wrote:

...

On 08.04.2018 05:01, Eli Schwartz via aur-general wrote:

...

If you're really afraid of someone running as either your user, or some user with the power to hijack your SSH session, while you're trying to sign something, then they could just switch out your built files anyway. There's literally no solution there, except to build everything on your machine and not use soyuz at all. "clave" won't help either, because it's got the same fundamental problem of not actually being your trusted machine from beginning to end.

Yes, the built files may not be trustworthy if an attacker is present, but the potential scope of this is limited to our package files.

The problem with agent forwarding is that people generally configure their agent to cache passwords so they don't have to unlock their keys all the time. With that in mind, an attacker can just request that the agent signs something after the package has been signed and there won't be any dialog popping up. That includes trust signatures on the attacker's key or just messages to prove that they are someone else.

Also people might have more than one key in their agent. If you have gpg and ssh keys in there, the attacker can just connect to other machines by using your forwarded agent's ssh key. Also, again there probably won't be a prompt since the password is usually cached.

Right, like I said/implied the problem was ill-defined. It's a configuration issue, not a conceptual problem with gpg forwarding being fundamentally a violation of PGP trust.

With the correct configuration, sure. But even then it still allows one to sign whatever the hack they want, (mail)texts requesting something like ssh key change or whatever like any arbitrary file one could imagine and grab the signature on the remote. It could even be made semi-stealthed to ask twice for a side-artifact and if not taking a careful notice about the lack of "wrong password" messages or whatever, most people will just enter the passphrase again and assume they mistyped. Not saying doing "harm" to a package that later gets locally signed and uploaded to the repo can't do more devastating havoc and gain access to the packagers key if installed on that very same machine... but people should also be aware it can aid to trivially get any text signed that makes f.e. some non-legitimate claims or requests look legitimate. Security and implications of threat models is always (additionally to hard facts) a personal thing of consideration what is acceptable and what not. People should always be made fully aware of the implications of acting in certain ways with their (distro) signing/shell keys. Speaking purely for me, my personal decision is to never build on remote machines and especially never sign anything on them. At the end, our reproducible builds efforts will (soon) help to detect such backdoored/altered packages uploaded to our tier-1 mirrors but it will not detect maliciously signed text messages or off-repo signed and exfiltrated packages that can later be used for a targeted MitM or malicious mirrors. So yes, if you ask me I still totally don't recommend to remote sign on a shared environment no matter how its configured... but if you feel the urge to do, then do it as good as possible. cheers, Levente