[aur-general] Build packages without Arch on pkgbuild.com

[Levente Polyak]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.archlinux.org/pipermail/aur-general/attachments/20180408/0df4c4cb/attachment-0001.asc>