5 ms·

I'm starting to feel that one of the lessons here is that individuals invited into trusted positions should be identifiable. Jia Tan is not a real person. We do

I'm starting to feel that one of the lessons here is that individuals invited into trusted positions should be identifiable. Jia Tan is not a real person. We don't know who they are, so there is no way to hold them accountable.

armada651 3y ago
As much as I support the privacy of maintainers I do feel like this is necessary to raise the bar for these types of social engineering attacks. However that would've likely done little to impede this attack if it is backed by organized crime or by a state as is being speculated. It is trivially easy for those types of actors to simply use a stolen identity or create an entirely plausible one out of thin air.
- sedatk 3y ago
  Such identity checks would also hurt honest contributors who want to hide their identity for other, legitimate reasons.
- avsteele 3y ago
  It is trivially easy for those types of actors to simply use a stolen identity or create an entirely plausible one out of thin air. Can you provide a historical example of when something like that has happened? It sounds like hyperbole to say that it is 'easy' (even for a state) to impersonate a real-life identity or create one for a professional developer with a multi-year work history.
fulafel 3y ago
Reputation works with pseudonymous identities too, and those have security upsides (eg can't be as easily pressed into service of others by extortion or rubber hose). And of course privacy is a value in itself.
- dist-epoch 3y ago
  You can build multiple pseudonymous identities in parallel. If one is burned, it doesn't matter, you still have 9 other.
- solatic 3y ago
  Think of it like politics: politicians are public figures who, by virtue of becoming a public figure, give up many of their rights to privacy. Why? Because they have power, and the public has a right to know who exercises that power. For security-hardened distributions, I can easily imagine a security control where contributor identity must be public and publicly verifiable, and to reject code which cannot be reliably attributed. Don't like it? Contribute to software with less impact instead.
teddyh 3y ago
No. <https://geekfeminism.fandom.com/wiki/Who_is_harmed_by_a_%22Real_Names%22_policy%3F https://geekfeminism.fandom.com/wiki/Who_is_harmed_by_a_%22R...>
- slavik81 3y ago
  I despise real name policies on social networks, but it's a very different thing to be anonymous while in a position of public trust.
  - JonChesterfield 3y ago
    "built a compression lib some people used" seems a stretch for "position of public trust". How about some responsibility for the IBM devs who could have contributed to the library they decided to paste into sshd?
arp242 3y ago
While all of this is of course quite serious, we also need to remember that these types of things are actually fairly rare. Last major one was that JS event-stream thing, and that was in 2018 (5 and a half years ago). I don't think this is really a structural problem requiring these kind of sweeping changes; it's just an occasional rare incident.
- secondcoming 3y ago
  No, the problem is that we don’t know how common it is. We only know about the ones found.
  - arp242 3y ago
    Or there isn't anything else to be found. It's more or less impossible to prove the absence of these type of bugs, so you can always say "we only know about the ones found" because that will always be true. Either way, you're going to have to do better than "this could perhaps possibly maybe be a more common problem" if you want such a huge sweeping change as maintainers of open source projects to "be identifiable". What does that even mean in practical terms? They upload their passports? To who? Who and how do they verify this? How do we prevent edited passports? What about privacy? etc. etc. etc. All for something we don't even know is a problem.
- qsi 3y ago
  As far as we know, they're rare...
AtNightWeCode 3y ago
Humans can always be compromised. This specific case can only be solved by improved tooling, workflows, visibility, runtime environments and so on.

armada651 3y ago

As much as I support the privacy of maintainers I do feel like this is necessary to raise the bar for these types of social engineering attacks. However that would've likely done little to impede this attack if it is backed by organized crime or by a state as is being speculated. It is trivially easy for those types of actors to simply use a stolen identity or create an entirely plausible one out of thin air.

sedatk 3y ago
Such identity checks would also hurt honest contributors who want to hide their identity for other, legitimate reasons.
avsteele 3y ago
It is trivially easy for those types of actors to simply use a stolen identity or create an entirely plausible one out of thin air. Can you provide a historical example of when something like that has happened? It sounds like hyperbole to say that it is 'easy' (even for a state) to impersonate a real-life identity or create one for a professional developer with a multi-year work history.

fulafel 3y ago

Reputation works with pseudonymous identities too, and those have security upsides (eg can't be as easily pressed into service of others by extortion or rubber hose). And of course privacy is a value in itself.

dist-epoch 3y ago
You can build multiple pseudonymous identities in parallel. If one is burned, it doesn't matter, you still have 9 other.
solatic 3y ago
Think of it like politics: politicians are public figures who, by virtue of becoming a public figure, give up many of their rights to privacy. Why? Because they have power, and the public has a right to know who exercises that power. For security-hardened distributions, I can easily imagine a security control where contributor identity must be public and publicly verifiable, and to reject code which cannot be reliably attributed. Don't like it? Contribute to software with less impact instead.

teddyh 3y ago

No. <https://geekfeminism.fandom.com/wiki/Who_is_harmed_by_a_%22Real_Names%22_policy%3F https://geekfeminism.fandom.com/wiki/Who_is_harmed_by_a_%22R...>

slavik81 3y ago
I despise real name policies on social networks, but it's a very different thing to be anonymous while in a position of public trust.
- JonChesterfield 3y ago
  "built a compression lib some people used" seems a stretch for "position of public trust". How about some responsibility for the IBM devs who could have contributed to the library they decided to paste into sshd?

arp242 3y ago

While all of this is of course quite serious, we also need to remember that these types of things are actually fairly rare. Last major one was that JS event-stream thing, and that was in 2018 (5 and a half years ago). I don't think this is really a structural problem requiring these kind of sweeping changes; it's just an occasional rare incident.

secondcoming 3y ago
No, the problem is that we don’t know how common it is. We only know about the ones found.
- arp242 3y ago
  Or there isn't anything else to be found. It's more or less impossible to prove the absence of these type of bugs, so you can always say "we only know about the ones found" because that will always be true. Either way, you're going to have to do better than "this could perhaps possibly maybe be a more common problem" if you want such a huge sweeping change as maintainers of open source projects to "be identifiable". What does that even mean in practical terms? They upload their passports? To who? Who and how do they verify this? How do we prevent edited passports? What about privacy? etc. etc. etc. All for something we don't even know is a problem.
qsi 3y ago
As far as we know, they're rare...

AtNightWeCode 3y ago

Humans can always be compromised. This specific case can only be solved by improved tooling, workflows, visibility, runtime environments and so on.