<div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, 14 Apr 2024, 13:12 Martin Guy via cfarm-users, <<a href="mailto:cfarm-users@lists.tetaneutral.net">cfarm-users@lists.tetaneutral.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Il 14/04/24 13:46, Jonathan Wakely via cfarm-users ha scritto:<br>
> On Sun, 14 Apr 2024, 12:15 Baptiste Jonglez via cfarm-users, <br>
> <<a href="mailto:cfarm-users@lists.tetaneutral.net" target="_blank" rel="noreferrer">cfarm-users@lists.tetaneutral.net</a>> wrote:<br>
><br>
>     On 09-04-24, David Malcolm via cfarm-users wrote:<br>
>     > I was wondering if the compile farm has any policies/procedures for<br>
>     > aging out long-dormant users (to minimize exposure in case of stolen<br>
>     > credentials).<br>
><br>
>     Good question.  We have no such policy currently.<br>
><br>
<br>
I don't see any advantage, other than saving a little disc space, but <br>
probably little.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Disc space is a constant problem on the popular cfarm machines!</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
It's no more likely that someone who's not used the compile farm in a <br>
while would have their keys copied unknown to them than it is that an <br>
active user's keys could be compromised, in fact less, </blockquote></div></div><div dir="auto"><br></div><div dir="auto">You don't need to copy keys if you can get access with a little social engineering.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">and anyone <br>
wanting to abuse the compile farm only has to ask for an account, </blockquote></div></div><div dir="auto"><br></div><div dir="auto">The threat model is not "somebody gets a new account" it's "somebody gets access to an account that doesn't belong to them".</div><div dir="auto"><br></div><div dir="auto">If you could convince the admins that you own the account "jwakely" but you've lost your ssh keys and need a new one to be added to the account, you could login as me. If my account had any signing keys or private keys on cfarm machines, or stored passwords for mail relays or websites, they would be compromised.</div><div dir="auto"><br></div><div dir="auto">If it's an old, inactive account, it might be easier to say "I am this person, but I've had to change email address in the two years since I last logged in". Maybe the attacker even managed to get ownership of the <a href="mailto:jwakely.gcc@gmail.com">jwakely.gcc@gmail.com</a> address after I stopped using it. If the old account had been purged from the systems, the attack simply doesn't work.</div><div dir="auto"><br></div><div dir="auto">Now maybe you could argue it's not a very credible threat (I would be silly to store private keys or passwords on cfarm machines). But I don't agree that it's more likely to happen for active users, since they're more likely to either keep hold of their email address, or update their cfarm access after learning they've been compromised. </div><div dir="auto"><br></div></div>