4 ms·

It would appear that no one knows the RL identity of the bad actor? Or even vouches for them? It doesn't seem wise to accept contributions to projects which ma

It would appear that no one knows the RL identity of the bad actor? Or even vouches for them? It doesn't seem wise to accept contributions to projects which may have security implications from anons. Code contributions clearly can't or aren't independently validated.

thewavelength 3y ago
Please read this email [0] from the original author of xz. Try take his perspective in his described situation. I also recommend this summary [1]. [0] https://www.mail-archive.com/xz-devel@tukaani.org/msg00567.html https://www.mail-archive.com/xz-devel@tukaani.org/msg00567.h... [1] https://boehs.org/node/everything-i-know-about-the-xz-backdoor https://boehs.org/node/everything-i-know-about-the-xz-backdo...
- avsteele 3y ago
  I am not assigning any personal blame or making an accusation of bad judgement on the maintainer. Taking contributions from anons appears to be common. I am suggesting that should change.
  - lifthrasiir 3y ago
    Contributions from anons can and in most cases will be verified by maintainers. The actual problem here is appointing them as maintainers. EDIT: To be clear, this problem is not directed to the original xz maintainer, but more about how to prevent or reduce such appointments in the first place.
boomboomsubban 3y ago
What do you propose? What would constitute a meaningful verification of identity that wouldn't create a near insurmountable hurdle for newcomers or those unable to travel?
- redbar0n 3y ago
  Passkeys?
  - cpach 3y ago
    How? AFAIK a passkey is just a replacement for a password. If my passkey tells you I can authenticate as john.doe@gmail.com, how does that help with establishing trust and identity?
    - redbar0n 3y ago
      Maybe combined with biometrics like FaceID?
      - cpach 3y ago
        In Sweden we have the proprietary BankID system, which is linked to one’s ‘personnummer’. (The personnummer is similar to SSN and compulsory for all citizens.) https://www.bankid.com/en/foretag/secure-digital-identification https://www.bankid.com/en/foretag/secure-digital-identificat... I think India has something similar? Not sure if open source developers would be so keen on introducing requirements like that into the development process. Some developers want to keep a low profile and not reveal to much about their AFK identity. And nearly all tech for doing stuff like this is proprietary.
- avsteele 3y ago
  I would want to think it over but off the top of my head: GitHub could provide this as a service, perhaps using uploads of whatever state/national ID the user is coming from. Give a little 'verified ID' badge. All banks do things like this for new accounts. Granted this doesn't stop state-actors, but it should be effective against cyber criminals. I think a system where it was harder for unknowns/newcomers to contribute but had better security is a good tradeoff. Esp. since it is likely this incident is not unique.
- Barrin92 3y ago
  National ID or verification by an employer. Both are ubiquitous and probably strong enough to at the very least prevent a significant amount of impersonations or fake accounts, which seem to play a large part in legitimizing or disguising these attacks.
pera 3y ago
How would that help? In this case the adversary is likely to be a state actor/group with a significant amount of resources available (time, money, talent, secrecy, etc.) Consider also that in many countries the government can force a honest national to collaborate with them on introducing backdoors to any target. This can happen both in OSS and proprietary software projects btw
elric 3y ago
That's a kneejerk reaction that will likely have more negative consequences than positive ones, and it likely wouldn't even have helped in this case. Do you think that sophisticated actors, especially state level actors, aren't capable of giving fake IDs to people? Or to have a web of equally fake identities vouch for someone? Every project potentially has security implications. A package that's used for compression today could be linked to an SSH server tomorrow. Something as banal as a todo list could be a potential attack vector in the right hands. I don't know what the solution to this problem is. Better verification of dependencies, certainly, but how? More investment by corporate users of FOSS into security? But no matter what we do, "who's watching the watchmen" will remain a valid question. I'm actually quite impressed that this was found as quickly as it has, though it makes me wary that there might be other, as yet unfound, such attacks.
- avsteele 3y ago
  Your point is well-taken, but see my reply below. Stopping state-backed level actors might not be possible, but we can make it harder for cyber-criminals. Has it been shown this is by a state-level actor?
  - elric 3y ago
    > but we can make it harder for cyber-criminals Why? Still throwing out the baby with the bathwater. Is there a huge number of problematic open source commits by "cyber criminals"? Would this even stop them? Doubtful. Will this make it harder for bona fide people to contribute? Certainly.

thewavelength 3y ago

Please read this email [0] from the original author of xz. Try take his perspective in his described situation. I also recommend this summary [1]. [0] https://www.mail-archive.com/xz-devel@tukaani.org/msg00567.html https://www.mail-archive.com/xz-devel@tukaani.org/msg00567.h... [1] https://boehs.org/node/everything-i-know-about-the-xz-backdoor https://boehs.org/node/everything-i-know-about-the-xz-backdo...

avsteele 3y ago
I am not assigning any personal blame or making an accusation of bad judgement on the maintainer. Taking contributions from anons appears to be common. I am suggesting that should change.
- lifthrasiir 3y ago
  Contributions from anons can and in most cases will be verified by maintainers. The actual problem here is appointing them as maintainers. EDIT: To be clear, this problem is not directed to the original xz maintainer, but more about how to prevent or reduce such appointments in the first place.

boomboomsubban 3y ago

What do you propose? What would constitute a meaningful verification of identity that wouldn't create a near insurmountable hurdle for newcomers or those unable to travel?

redbar0n 3y ago
Passkeys?
- cpach 3y ago
  How? AFAIK a passkey is just a replacement for a password. If my passkey tells you I can authenticate as john.doe@gmail.com, how does that help with establishing trust and identity?
  - redbar0n 3y ago
    Maybe combined with biometrics like FaceID?
    - cpach 3y ago
      In Sweden we have the proprietary BankID system, which is linked to one’s ‘personnummer’. (The personnummer is similar to SSN and compulsory for all citizens.) https://www.bankid.com/en/foretag/secure-digital-identification https://www.bankid.com/en/foretag/secure-digital-identificat... I think India has something similar? Not sure if open source developers would be so keen on introducing requirements like that into the development process. Some developers want to keep a low profile and not reveal to much about their AFK identity. And nearly all tech for doing stuff like this is proprietary.
avsteele 3y ago
I would want to think it over but off the top of my head: GitHub could provide this as a service, perhaps using uploads of whatever state/national ID the user is coming from. Give a little 'verified ID' badge. All banks do things like this for new accounts. Granted this doesn't stop state-actors, but it should be effective against cyber criminals. I think a system where it was harder for unknowns/newcomers to contribute but had better security is a good tradeoff. Esp. since it is likely this incident is not unique.
Barrin92 3y ago
National ID or verification by an employer. Both are ubiquitous and probably strong enough to at the very least prevent a significant amount of impersonations or fake accounts, which seem to play a large part in legitimizing or disguising these attacks.

pera 3y ago

How would that help? In this case the adversary is likely to be a state actor/group with a significant amount of resources available (time, money, talent, secrecy, etc.) Consider also that in many countries the government can force a honest national to collaborate with them on introducing backdoors to any target. This can happen both in OSS and proprietary software projects btw

elric 3y ago

That's a kneejerk reaction that will likely have more negative consequences than positive ones, and it likely wouldn't even have helped in this case. Do you think that sophisticated actors, especially state level actors, aren't capable of giving fake IDs to people? Or to have a web of equally fake identities vouch for someone? Every project potentially has security implications. A package that's used for compression today could be linked to an SSH server tomorrow. Something as banal as a todo list could be a potential attack vector in the right hands. I don't know what the solution to this problem is. Better verification of dependencies, certainly, but how? More investment by corporate users of FOSS into security? But no matter what we do, "who's watching the watchmen" will remain a valid question. I'm actually quite impressed that this was found as quickly as it has, though it makes me wary that there might be other, as yet unfound, such attacks.

avsteele 3y ago
Your point is well-taken, but see my reply below. Stopping state-backed level actors might not be possible, but we can make it harder for cyber-criminals. Has it been shown this is by a state-level actor?
- elric 3y ago
  > but we can make it harder for cyber-criminals Why? Still throwing out the baby with the bathwater. Is there a huge number of problematic open source commits by "cyber criminals"? Would this even stop them? Doubtful. Will this make it harder for bona fide people to contribute? Certainly.