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