Re: Keysigning in times of COVID-19
Adrian Bunk dijo [Fri, Aug 07, 2020 at 04:46:18PM +0300]: > Why are you requiring key signing at all when it has no defined semantics? > > Many DDs check only the government issued photo ID for signing a key and > this is also how keysigning parties work, but if this is considered > optional there is do defined meaning to a signature. > > If you as DAM do not have a problem if DDs have own policies that do not > require checking a government issued photo ID, then I do not see why the > key signing requirement exists at all. FWIW, and as I said in my other mail - Each of the three keyring-maint members have different policies. The word "trust" also has many different meanings and values, but we treat it as a binary thing here - Do two people trust the person controlling 0xDEADBEEF to be Gunnar Wolf or not? If so, we accept. If not, we don't. And yes, we have made some exceptions and jumped through some hoops to adapt to reality, but that's the trust level we can impose without our requirements breaking down into chaos. We had quite a hard time in 2015 when we did the <2048b purge. But we managed not to loosen our requirements.
Re: Keysigning in times of COVID-19
Hello Enrico, and thanks for bringing the discussion over here. Enrico Zini dijo [Thu, Aug 06, 2020 at 05:54:21PM +0200]: > Hello, > > we have people approaching Debian with a lack of GPG signatures, and we > generally cannot ask them to travel and meet other developers in person > to get their key signed. > > Technically, we are not requiring that people meet a DD in person, only > that people have their key signed by a DD. > > Technically, every DD has their own policies for signing keys, which > could go from not requiring meeting in person at all, to requiring to > meet in person multiple times. It might require to check a government > issued photo ID, or it might not. > > Practically, I feel like most of the time people's policies match what > are the perceived expectations of the rest of the project. Meeting in > person has always been a good safe bet, if only for the reson that it's > been accepted without question for many years. > > It's time to review those expectations. > (...) Enrico brought up this topic to DPL, DAM, front-desk and keyring-maint about two weeks ago. I will copy over what I answered back then: We have been rehashing many of the (great) arguments you present every now and then since... At least, I remember the point being brought up after the Yuge KSP from HEL at DC5, and the Transnational Republic incident of DC6. Our guidelines have been for many many many years that "everybody is free to set their own policy — but please be sensible and careful". We have never sent out an official announcement, either from DAM or from keyring-maint, about it... but AIUI we have been basically in agreement and explicitly said so at KSP introductions (I have, repeatedly). We have often mentioned positive examples (i.e. pseudonymous community members we completely trust). We have mentioned the ease to acquire forged or plainly fake official-looking IDs. So, where do I stand? I try not to sign keys for people I cannot recognize without looking at their papers. That means, my signing resembles a lot my group of friends, the group of peple we meet year after year in DebConf, plus some others I've bumped into now and then. IDs? Show them to me, I don't really mind, I have done many signings without looking at IDs. I know first-hand¹ that forging them is very easy. I also know some of our friends have a made-up identity. Some of those identities are close to twenty years old, at least. That's worth the same as a birth-given name in my book... And yes, I have often refused to sign people's keys when they approach me at a DebConf if we have not held significative interactions in the past. I usually insist that I do not sign at a first meeting. Although, yes, if meeting somebody at other ocassions, specially given Latin America is a quite PGP-sparse region... I tend to be a bit more flexible, to aid people getting connected and start contributing. And... Well, to the point at hand: Yes, I do think we have to rethink our policies. I don't have an answer right now, and most likely, I won't sign any keys during this DebConf. But as more of our activities are conducted online, we will have to start trusting videoconferences to prove identities. (of course... given deepfakes have been getting better and better... who knows? :-\ ) ¹ If you must know, >25 years ago I paid for a passport I should not have received. My personal data was correct, but back then, my country required a military service "clearance" I didn't have. I am not proud of having paid for an illegal document, and would not do it again. But it's part of what I learnt, and I am sure my experience would not change _too much_ going to other countries. More money to spend, perhaps... signature.asc Description: PGP signature
Re: Keysigning in times of COVID-19
Hi Olek, On Sat, Aug 8, 2020 at 6:36 PM Olek Wojnar wrote: > > You are attributing motivations to me that I do not have. More significantly, you are not responsible for "our tendency to suck every discussion into such a long-term thing that it immobilizes us." Sam is right with his general observation, but the issue is social. We need fewer hurt feelings and more trust in each other. Debian is more than its parts. At the end of the day, we all want the same thing. Let's give the world a great operating system! Kind regards Felix Lechner
Re: Keysigning in times of COVID-19
On Sat, Aug 8, 2020 at 5:04 PM Sam Hartman wrote: > Until you have a concrete suggestion, you're derailing the discussion. > Enrico and a number of people sound like they would like a way forward > that works for people trying to become DMs today. > When I hear things like "eventually have a GR," that's on an entirely > different scope than they are asking about. Would it be a reasonable compromise to start a new thread rather than just quashing any deeper discussion? -- Eldon
Re: Keysigning in times of COVID-19
Sam, I do not appreciate your aspersions and I think your hostile attitude is completely uncalled for. I don't know why me sharing my thoughts on this subject has triggered you into lashing out. On Sat, Aug 8, 2020, 19:04 Sam Hartman wrote: > > Sometimes that is necessary; some ideas need to be stopped. > > I disagree that processing DMs today is such an idea. > You are attributing motivations to me that I do not have. Allow me to repeat myself, again: I see the question of real-life verification as central to the issue that was raised. I'm not the first to bring it up. I do not appreciate your dismissive attitude, it comes across as quite condescending. Last I checked, everyone in Debian was free to share their opinions, especially in response to a call for opinions. To connect the dots more obviously, if there is a consensus that a contributor's online identity and reputation is sufficient for Debian's purposes then that answers the original question and clarifies the project's position on the subject. I have no intention of continuing pointless quibbling. I have made my point. If other people agree, great. If they disagree, that's fine too. Let's just try to be civil and professional, ok?
Re: Keysigning in times of COVID-19
> "Olek" == Olek Wojnar writes: > TL;DR: While there may be improvements to be found in a > completely different approach to identity, let us not let the > scope of the discussion broaden that far, so we can make > progress today. Olek>I respectful disagree on this point. This conversation Olek> started with a question about how to verify identity without Olek> in-person interaction. The reason a number of people have Olek> seemingly broadened the scope (from my perspective, I clearly Olek> don't know people's actual motivations) is because that is the Olek> deeper question behind the original query. Until you have a concrete suggestion, you're derailing the discussion. Enrico and a number of people sound like they would like a way forward that works for people trying to become DMs today. When I hear things like "eventually have a GR," that's on an entirely different scope than they are asking about. It's possible no short-term solutions will emerge. And I don't mind people exploring longer-term things. What I mind a great deal is our tendency to suck every discussion into such a long-term thing that it immobilizes us. You are adding stop energy: you've broadened the scope to a question that you then say you cannot answer. Sometimes that is necessary; some ideas need to be stopped. I disagree that processing DMs today is such an idea.
Re: Keysigning in times of COVID-19
Hi Sam, On Sat, Aug 8, 2020, 11:46 Sam Hartman wrote: > > TL;DR: While there may be improvements to be found in a completely > different approach to identity, let us not let the scope of the > discussion broaden that far, so we can make progress today. > I respectful disagree on this point. This conversation started with a question about how to verify identity without in-person interaction. The reason a number of people have seemingly broadened the scope (from my perspective, I clearly don't know people's actual motivations) is because that is the deeper question behind the original query. > "Olek" == Olek Wojnar writes: > > Olek> Thanks to some great tools, it's fairly easy to > Olek> verify that they do indeed control the email addresses tied to > Olek> their key. That's what I care about at that point in time. > > For me, that's not nearly enough. > If all you want to do is verify that a particular point in time, an > email address belongs to a key, set up a service to do that. > I was referring to the caff package. When I sign a key I am signing a certification that I believe > 1) the key and > 2) the real world identity > > correspond to the digital identity in the FLOSS community represented by > the claimed email address. > That is how I have always done it as well but this conversation is making me rethink the *why* of that process. I don't want to throw out what we have without a viable suggestion that > the project can get behind. > Agreed. So, let's focus this thread on key signing and how to adapt that because > it's what we have today and because we're looking for some short-term > answers. > If you want to start a different thread proposing to revamp how we think > about identity, go for it. > Again, I disagree that these are distinct topics. I think they are intrinsically linked. There have been some good points so far about the value of having a real-world identity connected to your Debian identity for reasons of accountability and liability. There have also been good points about personal privacy. (Dissident Test, anyone?) I was just recently speaking with a prospective first-time contributor who was very excited about being involved in the project but was not comfortable sharing their real life identity. Do we turn people like that away or welcome their contributions into the project once we have validated their reliability and trustworthiness *in the scope of the Debian Project*? Do we absolutely *have* to have a real life identity connected to someone to sign their key? Or to accept a patch? Or a packaging job? Or permissions as a DM? I'm not advocating a position since I'm not 100% sure what the answer should be. But I think that these are important questions to ask ourselves and an important conversation to have. Perhaps this will eventually lead to a GR, or perhaps we'll develop a consensus here. But we absolutely need to be having this conversation and considering all points of view and repercussions. -Olek >
Re: Keysigning in times of COVID-19
TL;DR: While there may be improvements to be found in a completely different approach to identity, let us not let the scope of the discussion broaden that far, so we can make progress today. > "Olek" == Olek Wojnar writes: Olek> TL;DR: I think without some link back to real world Olek> identity, we open ourselves up to attacks where people build Olek> trust only to betray us. Olek>I agree with you that this is a potentially-serious Olek> problem. However, I'm not sure that keysigning is the right Olek> place to address it. I've seen a number of comments, including Olek> yours, seemingly conflate the trust we place in the validity Olek> of a cryptographic key and the trust we place in someone Olek> during the NM process. To some extent I've been sloppy because it's the end result I care about not where in the process particular steps happen. I'm happy to dig into my thoughts on the breakdown though. Olek> I think it is important to distinguish Olek> between the two. So, I don't really care (much) how Olek> technically competent or hard-working someone is when I sign Olek> their key. Agreed. I care to some extent how good of a job I think they will do in key management, and some of that is technical. Olek> Thanks to some great tools, it's fairly easy to Olek> verify that they do indeed control the email addresses tied to Olek> their key. That's what I care about at that point in time. For me, that's not nearly enough. If all you want to do is verify that a particular point in time, an email address belongs to a key, set up a service to do that. That would be a valuable service for many purposes, but don't waste my time signing stuff if that's all you want. Such a service would have an implicitly (or explicitly if it were documented) different certification process than my signatures. I argue Debian should not trust such a service for the identity verification part of our membership process. When I sign a key I am signing a certification that I believe 1) the key and 2) the real world identity correspond to the digital identity in the FLOSS community represented by the claimed email address. That is a statement that is deeper than simply that the email adress corresponds to the key. Olek> Now, if they want me to sponsor them in the NM process, that's Olek> when I am going to take a much closer look at their work and Olek> their attitude and determine if we should grant them the level Olek> of trust that goes with completing that process. Agreed. Olek> That is also Olek> where I humbly submit we should have some level of identity Olek> verification. I'm not sure what that should look like but the Olek> point is where it should take place. If we previously verified Olek> someone's identity and subsequently banned them from the Olek> project, the NM process seems like the logical place to ensure Olek> that such a person is not able to slip back into Olek> Debian. Centralized and standardized is much easier in a Olek> process administered by a few people (NM) than in a Olek> distributed process with substantial variability and no means Olek> of reliable QA (random keysigning party). -Olek It's hard to evaluate such a suggestion until you do know what such a process looks like. I think that what we have today by caring more about identity than simply keys belonging to email addresses works reasonably well. It may be that some identity verification process in NM works even better. I don't want to throw out what we have without a viable suggestion that the project can get behind. As an example, while copying government IDs and checking against some central service, possibly also using one of those identity verification services that looks at credit information etc, might (for many people in the US and Europe at least) be more effective than what we do, I have great confidence that would not be politically acceptable to the project. So, let's focus this thread on key signing and how to adapt that because it's what we have today and because we're looking for some short-term answers. If you want to start a different thread proposing to revamp how we think about identity, go for it. For me at least you'll need a concrete suggestion before I can approach that discussion. signature.asc Description: PGP signature
