Hacker News Reader

Comment by exacube | Hacker News Reader

Is the real identity of Jia Tan known, even by Lasse Collin?

I would think a "real identity" should be required by linux distros for all /major/ open source projects/library committers which are included in the distro, so that we can hold folks legally accountable

View on HN

Open source fundamentally does not work that way. There are many important open source contributors who work pseudonymously.

Google's Know, Prevent, Fix blog post floated the idea of stronger identity for open source in https://security.googleblog.com/2021/02/know-prevent-fix-fra... and there was very significant pushback. We learned a lot from that.

The fundamental problem with stronger identity is that spy agencies can create very convincing ones. How are distros going to detect those?

While "open source" fundamentally doesn't work that way, the point here is about maintainers, not regular contributors. Identity of new maintainers must be vetted (via in-person meetups and whatever other mechanisms) by other "trusted" maintainers whose identities are "verified".

I realize, it's a hard problem. (And, thanks for the link to the "Know, Prevent, Fix" post.)

PS: FWIW, I "win my bread" by working for a company that "does" open source.

Edit: Some projects I know use in-person GPG key signing, or maintainer summits (Linux kernel), etc. None of them are perfect, but raises the bar for motivated anonymous contributors with malicious intent, wanting to become maintainers.

I’ve worked with a few very talented pseudonymous developers on the Internet over the years. I can’t think of any way to vet their identities while maintaining their anonymity (well, it’s basically impossible by definition), plus if you’re talking about in-person meetups, traveling from, say, Asia to North America isn’t cheap and there could be visa issues. The distinction between maintainers and non-maintainers isn’t that meaningful because non-maintainers with frequent and high quality contributions will gain a degree of trust anyway. The attack we’re discussing isn’t about someone ramming obviously malicious code through as a maintainer, they passed or could have passed code review.

> traveling from, say, Asia to North America isn’t cheap and there could be visa issues.

And there are other reasons some people might not want to travel outside their nearby region. For instance, they might be taking care of an elderly relative. Or they might be the elderly relative, with travel counter-indicated for health reasons.

I'll bet many of them simply wouldn't want to.

I agree, these are all really valid reasons. FWIW, I myself have worked with "anonymous" maintainers and contributors that I've never met.

You make excellent points; I agree. Especially, a non-maintainer with a high-quality contribution gaining trust. Many times, (tired) maintainers are forced to "rubber-stamp" and merge such high-quality patches. It could be due to any number of (valid) reasons—a CVE fix, an involved performance fix that will take you weeks to load up on the context, enabling a hardware feature that's under semi-NDA, you just trust their work too well, maintainer fatigue, etc.

What I'm saying is, in context of critical-path software, the identity of maintainers vs non-maintainers matters more. I'm not naively claiming that it'll "solve" the problem at hand, just that it's another layer in defense. For a critical software, you shouldn't be able to simply submit a "patch"[1] such as:

  tests: Add-binary-blob-with-a-subtle-backdoor.xz

  Signed-off-by: "Anonymous Rabbit" <LittleBunny123@lolmail.com>

Commit it yourself, brazenly push it into Linux distros, and then anonymously sign off into the sunset with no trace. I'm sure you'll agree that there's a world of difference between a deeply entrenched, critical libray and a random user-space application.

It's a messy situation. How much, if at all, "clever tech" can mitigate this human "trust issue" is an open problem for now.

[1] https://git.tukaani.org/?p=xz.git;a=commitdiff;h=cf44e4b7f5d

I was initially thinking that one of the core non-tech causes of the was the single-person maintenance mode of the xz project.

But you have a point. As an agency you can seed two jiatan's to serve diligently for a couple of years following the strict 2-person code reviews and then still poison the project. On the other hand, if the xz build process was automated and transparent and release artifacts were reproducible and verifiable even in this poor condition of xz-utils as a project it would have been much harder to squeeze in a rogue m4/build-to-host.m4

The blog post clarified it's about maintainers of critical packages, not all contributors. This could be limited to packages with just one or two maintainers, especially newer ones. And they could remain somewhat anonymous, providing their information to trusted third parties only. If some maintainers don’t accept even this, their commits could be put into some special queue that requires additional people to sign off on them before they get accepted downstream. It's not a complete fix, but it should help.

My problem with stronger identity is it violates open source licenses.

Source code is provided without warranty and this statement is clear in the license.

Putting an verified identity behind the source code publish is basically starting to twist said said no-warranty. Fuck that.

What would prevent a known person from accepting a govt payout to sabotage their project, or to merge a plausible-looking patch? Relying on identity just promotes a type of culture of reputation over code review.

Nope, identities won’t solve it, you can have people coerced, blackmailed, threatened, or simply just a “front” while there’s a whole team of spies in the background. The process should be about what’s being pushed and changed in the code, but I would be lying to say I have a concrete concept how it is possible.

If this was done by a state actor then this policy wouldn't help at all. States have no shortage of identities to fake.

How would that even work? Are distros expected to code their own alternative versions of open source libraries where they can't get the maintainers to send their IDs? Or what stops from forged IDs being used?

This will never be accepted by the community.

Reply on news.ycombinator.com