<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:small"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Sep 7, 2024 at 9:34 PM efc--- via cryptography <<a href="mailto:cryptography@metzdowd.com">cryptography@metzdowd.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
On Sat, 7 Sep 2024, Christian Huitema wrote:<br>
<br>
> relying on mega-scalers has its own problems: it contributes to more <br>
> concentration on the Internet, and even if we believe that these big <br>
> mixers are not somehow doing surveillance capitalism, they become an <br>
> attractive point for legal attacks. So maybe as a general practice we <br>
> ought to rely on a large number of medium size relays, instead of just a <br>
> few big ones.<br>
<br>
One question when it comes to public encrypted services that I think is<br>
neglected, is project and legal governance.<br>
<br>
Companies can easily be shut down, or opened up by law enforcement.<br>
Individual programmers can be threatened, open source projects can be<br>
infiltrated.<br>
<br>
Once you're in the inside, it is way easier to attack a project.<br>
<br>
How would you protect against those types of attacks? Is there anything<br>
organizational or legal, one can do, to reduce the possibility of those<br>
things?<br></blockquote><div> </div><div><div class="gmail_default" style="font-size:small">We have seen a number of infiltration efforts and they all have the whiff of being a nation state actor.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Bottom line being that only a nation state actor is likely to have the patience required for the insanely long kill chains involved. Like eight steps just to compromise SSH which is merely a stepping stone to compromise other things.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">There are two cases of note:</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">1) Infiltration</div><div class="gmail_default" style="font-size:small">2) Compromise of a contributor's machine.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Infiltration is an attack which is probably only feasible for nation state actors. Not least because anyone who infiltrates an open source project is likely to have some individuals with a very personal interest in taking them down hard. It is also pretty difficult to maintain. So not saying it doesn't happen just that compromising a machine is easier.</div></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">For the second case, what I would like open source projects to start doing is signing every commit with a key tied to the specific development machine. So if Fred's old PC is compromised and some malicious updates are added, we can instantly identify the commits from that specific device.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">To make that happen, it would be helpful for GitHub to make the ability to use SSH key signing keys a free feature rather than restricting it to the enterprise tier.</div><div> </div></div></div>