Some have rolled their eyes at the "paranoid" requirement from the #Debian community of in-person gpg key signing as a step to become a Debian developer, and it's often been a real barrier.

But I'm reminded of it at the #OSSummit keynote today as the #Linux Foundation's Jim Zemlin talks about the xz vulnerability and identity verification of developers.

It was never paranoia. It doesn't solve everything, and people can still be dishonest, but it was never excessive paranoia.

@pleia2 to be honest, i don't see the point of it. a threat actor can send somebody from their group to go get their signing key signed by other developers, after all.
@ariadne It's true, but there are a lot of additional barriers there, including visas, travel, and generally the extra layer of complexity that representing yourself in person brings (basically all the reasons people have brought up against it over the years). This may not mean much when a huge investment is made by a state actor already, but it's something.

@pleia2 @ariadne I guess the concern would be that a nation state actor with significant resources has much *more* of an ability to deal with most of those barriers than a genuine volunteer contributor usually does.

(While someone without such resources mostly isn't going to be doing an elaborate long-term attack like this.)

So it's not paranoid, but it's unclear how much it would help.

@ids1024 @pleia2 @ariadne You have to come out into the open. Meet people who might then be able to identify you. So it fixes an identity more to one person.

@waldi @ids1024 @pleia2 does it though? i am sure an alphabet soup agency can just designate one physical person to run point on any in-person interactions with the APT.

i guess i am just not convinced that this has any meaningful defense against APTs who can likely issue fake travel docs any time they want.

what the cross-signing *does* help with is ensuring that no single party controls all of the signing keys used for Debian. but in practice, the reason why that is important is largely tied to how Debian-like distributions ingest source code to create debs.

(and nothing stops an APT from just going through mentors.debian.org just like nothing stops an APT from just submitting PRs to aports and finding a useful person to unwittingly merge them into Alpine)

@ariadne @waldi @pleia2 It would probably be most useful if the people meeting had communicated a lot online. In the case of xz, if "Jia Tan" met in person with Lasse Collin, and they talked much about plans with xz, it may become suspicious if "Jia" doesn't act very knowledgeable about xz, or even their own work, and speaks quite differently from how they do online.

So it may be hard to send someone else. Which is at least some kind of barrier.

I'm not familiar with how this works in Debian.

@ids1024 @ariadne @waldi @pleia2 There are definitely people in Debian who'll only sign keys of people they know non-superficially (i.e. not just waving a passport at them or something). Practices vary, though - it's a big project.
@cjwatson @ids1024 @waldi @pleia2 yeah like every other web of trust system it ultimately comes down to a decision made by the individual participant in any given moment.
@ariadne @ids1024 @pleia2 Sure, they can and will do that. But now you have one person that needs to reasonably well know all that stuff. If you only communicate nonverbally, you can use the support group for backup if the one doing the communication does not have all that knowledge.
@waldi @ids1024 @pleia2 it's ok, neuralink will probably solve for this problem within a decade

@waldi @ids1024 @pleia2 @ariadne someone has to come out in the open. It seems almost certain that the xz attack was a team effort, and by an organization with large resources. A single person showing up and being reasonably convincing is not the highest bar in the world, and moreover the attacker has much to gain by constraining your thinking to associating them with one identity.

It's not a sure bet on their part, but then neither was their technique to get commit bits.

@pleia2

I don't think enough people understand the stakes here. Open source software, and Debian by extension, are used globally in every aspect of infrastructure. The attack surface is just immense.

Countermeasures only seem extreme when people fail to realize the stakes.

@pleia2 The #FSF Copyright Assignment that the #GNU project uses and was designed to serve the exact purpose as well. And we have been harping about this for quite sometime .. go figure.
@amszmidt @pleia2 Really? Why would a copyright assignment be necessary for that? I was under the impression it was meant to centralize license enforcement. If the goal was verification of identity, they could've just done something similar to the DCO (not that that existed yet, but they could have invented it).

@nasado @pleia2 The copyright assignment requires the developer to be identified, and verified using an ID/passport/... in the case of any copyright issues. You'd communicate name, address, phone number, etc as well.

The DCO is not sufficient for that kind of information, since anyone can just email a reply.

@amszmidt @pleia2 That's not what I mean. I mean that there's no reason you need to actually reassign copyright to do all of that verification.
@nasado @pleia2 There is also no reason to do in-person GPG signatures to verify either, there are plenty of other ways. This is just one, having an actual legal framework where the copyright assignee becomes responsible for the code that they contribute keeps the riff-raft away.

@amszmidt @pleia2

Who exactly do you mean by "riff-raff"?

@nasado @pleia2 Jia Tan and other unserious actors. Are we reading and replying to the same thread?
@amszmidt @pleia2 "Riff-raff" is a real strange word to use, is all. So is "unserious", for that matter. Anyway, the point is, you can do all the verification and come out the other end with something like a DCO but more thoroughly checked. Reassigning the copyright is unnecessary for that purpose. And the copyright assignee "becoming responsible for" the code doesn't mean anything -- they become socially responsible for it when they distribute it, and legally nobody is responsible thanks to the standard disclaimers in virtually every FOSS license.
@nasado @pleia2 no you cannot. That’s the whole point. DCO are not a physical link between the individual and what is being submitted. GPG signing or actual verification of legal documentation is. A DCO is beyond easy to fake, and would have not helped anything in the xz case, where a CA or GPG check in person would have raised the bar much higher. You are confusing differnt topics.
@amszmidt @pleia2 I've been clear from the beginning that I'm talking about something *like* the DCO -- as in, something that verifies the developer's identity without requiring copyright assignment. I am not saying they could just use the actual DCO procedure. If the FSF wants copyright, they probably have to do the extensive verification, but that doesn't mean that if they want the verification they have to get copyright assigned.
@nasado @pleia2 something like that doesn’t exists. The CA purpose is to verify that you are you and have the right to contribute the change without any copyright issues. That there is an assignment (and a give back on that) is beside the point. I’m muting you now, since I do t think there is much point in continuing this.
@pleia2 Originally, GPG signing was *meant* to be done in person once you have verified the other person's identity. This is not paranoia; This is the intended, and safest, way of verification.

@pleia2
There's no substitute for in-person vetting. Fortunately, with PGP< one can sign the public keys of others, adding assurance for not-in-person trust.

What @[email protected] says is true. But that's a known aspect of public key trust: it cannot prove the integrity of the key owner, merely assure the identity. One then must recognize good/bad behavior of that actor and take note.

@pleia2 I hope any identity verification steps would have alternative avenues available for checking trustworthiness. I discuss some possibilities in

https://www.harihareswara.net/posts/2024/trust-new-maintainer/

@pleia2 I would argue that in-person verification is simply not enough against a state actor. They would think nothing of spending time and money to cultivate a believable individual persona with a verifiable backstory that would survive any cursory verification.
@pleia2 It is a barrier that a lot of people cannot cross for financial and disability reasons. And something I'm quite sure is pretty easily surmounted by actual bad actors who want a backdoor for whatever reason. I think this is security theatre I'm sorry, and like most of that it just decreases accessibility.