[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Salsa update: no more "-guest" and more

On 2020-04-28 14:32:55 +0200 (+0200), Bernd Zeimetz wrote:
> On 2020-04-28 14:27, PICCA Frederic-Emmanuel wrote:
> > Is it possible to use it's ssh key in order to  have acces to
> > the salsa api ? I mean instead of the token, which looks to me
> > quite fragile compare to ssh via a gpg card and the gpg agent.
> The api works with a token - and without 2fa. That will not change
> if you enforce 2fa.
> If you use ssh, you can create an own account for the ssh key and
> give it very special permissions, if you need it for automatic
> pushes or similar things.

So to summarize, 2FA in Salsa may protect against someone losing
control of their WebUI credentials, but does nothing to secure
against theft of API keys they've generated, nor of an SSH key
persisted/forwarded in an agent or left lying around unencrypted (or
easily guessed because someone made unfortunate choices when
patching a random number generator).

Before adding security controls, it's a good idea to assess your
threat model. Is it the same as projects which experienced high
profile compromises like the Linux kernel archive or Matrix, where
the attackers leveraged stolen SSH keys to gain a foothold? What is
Salsa hosting which would be sensitive if altered? Source code. And
how are those alterations normally applied? Git over SSH. (Granted,
there's discussion of using its WebUI to authenticate sessions for
other project systems, so that does potentially change the risks

I agree that having 2FA support in Salsa is great, but providing it
for those who want to rely on it for their accounts is different
from unilaterally forcing it on all users even if they find it a
significant additional inconvenience for little actual benefit.
Thankfully, it sounds like the Salsa admins plan to keep use of 2FA
Jeremy Stanley

Attachment: signature.asc
Description: PGP signature

Reply to: