Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.project > #11956 > unrolled thread

Keysigning in times of COVID-19

Back to article view | Back to linux.debian.project

Contents

  Keysigning in times of COVID-19 Enrico Zini <enrico@enricozini.org> - 2020-08-06 18:10 +0200
    Re: Keysigning in times of COVID-19 Roberto C. Sánchez <roberto@debian.org> - 2020-08-06 18:50 +0200
      Re: Keysigning in times of COVID-19 Federico Ceratto <federico.ceratto@gmail.com> - 2020-08-17 20:30 +0200
        Re: Keysigning in times of COVID-19 Jonas Smedegaard <dr@jones.dk> - 2020-08-17 21:10 +0200
          Re: Keysigning in times of COVID-19 Wouter Verhelst <wouter@debian.org> - 2020-08-19 16:20 +0200
            Re: Keysigning in times of COVID-19 rhkramer@gmail.com - 2020-08-19 18:10 +0200
              Re: Keysigning in times of COVID-19 Philip Hands <phil@hands.com> - 2020-08-20 10:20 +0200
                Re: Keysigning in times of COVID-19 Andrey Rahmatullin <wrar@debian.org> - 2020-08-20 10:50 +0200
                Re: Keysigning in times of COVID-19 Ansgar <ansgar@debian.org> - 2020-08-20 10:50 +0200
                Re: Keysigning in times of COVID-19 Jonas Smedegaard <dr@jones.dk> - 2020-08-20 12:20 +0200
                  Re: Keysigning in times of COVID-19 Russ Allbery <rra@debian.org> - 2020-08-20 19:30 +0200
                Re: Keysigning in times of COVID-19 Florian Weimer <fw@deneb.enyo.de> - 2020-08-23 23:10 +0200
    Re: Keysigning in times of COVID-19 Felix Lechner <felix.lechner@lease-up.com> - 2020-08-06 19:10 +0200
    Re: Keysigning in times of COVID-19 Johannes Schauer <josch@debian.org> - 2020-08-06 19:30 +0200
      Re: Keysigning in times of COVID-19 Holger Levsen <holger@layer-acht.org> - 2020-08-07 11:40 +0200
    Re: Keysigning in times of COVID-19 Jonas Smedegaard <dr@jones.dk> - 2020-08-06 19:40 +0200
    Re: Keysigning in times of COVID-19 Christian Kastner <ckk@debian.org> - 2020-08-06 23:40 +0200
    Re: Keysigning in times of COVID-19 Héctor Orón Martínez <hector.oron@gmail.com> - 2020-08-07 01:30 +0200
    Re: Keysigning in times of COVID-19 Alexandre Viau <aviau@debian.org> - 2020-08-07 09:30 +0200
      Re: Keysigning in times of COVID-19 Jonas Smedegaard <dr@jones.dk> - 2020-08-07 12:00 +0200
    Re: Keysigning in times of COVID-19 Didier 'OdyX' Raboud <odyx@debian.org> - 2020-08-07 12:00 +0200
    Re: Keysigning in times of COVID-19 Alberto Garcia <berto@igalia.com> - 2020-08-07 12:10 +0200
    Re: Keysigning in times of COVID-19 Adrian Bunk <bunk@debian.org> - 2020-08-07 16:10 +0200
      Re: Keysigning in times of COVID-19 Ulrike Uhlig <ulrike@debian.org> - 2020-08-07 18:50 +0200
      Re: Keysigning in times of COVID-19 Gunnar Wolf <gwolf@debian.org> - 2020-08-09 07:50 +0200
        Re: Keysigning in times of COVID-19 Adrian Bunk <bunk@debian.org> - 2020-08-10 20:00 +0200
    Re: Keysigning in times of COVID-19 Gunnar Wolf <gwolf@debian.org> - 2020-08-09 07:40 +0200
    Re: Keysigning in times of COVID-19 Jonathan McDowell <noodles@earth.li> - 2020-08-12 10:10 +0200
      Re: Expressing regrets for how I handled the transition to Identity Verification  in times of COVID-19 Sam Hartman <hartmans@debian.org> - 2020-08-12 14:30 +0200
    Re: Potential Summary: Keysigning in times of COVID-19 Sam Hartman <hartmans@debian.org> - 2020-08-12 14:10 +0200
      Re: Potential Summary: Keysigning in times of COVID-19 Jonas Smedegaard <dr@jones.dk> - 2020-08-12 14:30 +0200
      Re: Potential Summary: Keysigning in times of COVID-19 Ángel <debian-project@debian.16bits.net> - 2020-08-13 08:20 +0200
        Re: Potential Summary: Keysigning in times of COVID-19 Adam Borowski <kilobyte@angband.pl> - 2020-08-13 19:30 +0200
          Re: Potential Summary: Keysigning in times of COVID-19 Pirate Praveen <praveen@onenetbeyond.org> - 2020-08-13 20:20 +0200
            Re: Potential Summary: Keysigning in times of COVID-19 Adam Borowski <kilobyte@angband.pl> - 2020-08-13 21:10 +0200
              Re: Potential Summary: Keysigning in times of COVID-19 Steve McIntyre <steve@einval.com> - 2020-08-13 23:10 +0200
                Re: Potential Summary: Keysigning in times of COVID-19 Adrian Bunk <bunk@debian.org> - 2020-08-14 18:50 +0200
                  Re: Potential Summary: Keysigning in times of COVID-19 Jonas Smedegaard <dr@jones.dk> - 2020-08-14 23:00 +0200
                    Re: Potential Summary: Keysigning in times of COVID-19 Ángel <debian-project@debian.16bits.net> - 2020-08-14 23:10 +0200
                      Re: Potential Summary: Keysigning in times of COVID-19 Jonas Smedegaard <dr@jones.dk> - 2020-08-15 00:30 +0200
              Re: Potential Summary: Keysigning in times of COVID-19 Christian Kastner <ckk@debian.org> - 2020-08-13 23:10 +0200
                Re: Potential Summary: Keysigning in times of COVID-19 Adam Borowski <kilobyte@angband.pl> - 2020-08-14 00:40 +0200
          Re: Potential Summary: Keysigning in times of COVID-19 Ángel <debian-project@debian.16bits.net> - 2020-08-13 21:40 +0200
    Re: Keysigning in times of COVID-19 Pierre-Elliott Bécue <peb@debian.org> - 2020-08-12 17:30 +0200
      Re: Keysigning in times of COVID-19 Paul Wise <pabs@debian.org> - 2020-08-13 08:20 +0200
        Re: Keysigning in times of COVID-19 Sam Hartman <hartmans@debian.org> - 2020-08-13 14:00 +0200
          Re: Keysigning in times of COVID-19 Pierre-Elliott Bécue <peb@debian.org> - 2020-08-13 14:20 +0200
            Re: Keysigning in times of COVID-19 Guilhem Moulin <guilhem@debian.org> - 2020-08-13 14:50 +0200
              Re: Keysigning in times of COVID-19 Pierre-Elliott Bécue <peb@debian.org> - 2020-08-13 16:50 +0200
                Re: Keysigning in times of COVID-19 Ángel <debian-project@debian.16bits.net> - 2020-08-14 04:00 +0200
                  Re: Keysigning in times of COVID-19 Pierre-Elliott Bécue <peb@debian.org> - 2020-08-16 15:40 +0200
        Re: Keysigning in times of COVID-19 rhkramer@gmail.com - 2020-08-13 14:00 +0200
        Re: Keysigning in times of COVID-19 Pierre-Elliott Bécue <peb@debian.org> - 2020-08-13 14:20 +0200

Page 1 of 3  [1] 2 3  Next page →

#11956 — Keysigning in times of COVID-19

[Multipart message — attachments visible in raw view] — view raw

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.

For example, speaking of myself only, if my goal is to raise the cost of
impersonation or sock puppet identities, then probably signing someone's
key after having worked with them online for a significant time, would
require a much higher cost than showing up at a keysigning party with a
fake ID good enough to fool me.

Others may have other policies, and are likely to be acceptable.

As DAM, I would have a problem if someone automatically signed the keys
of every stanger who asked them nicely in an email. At the same time, I
am open to the idea of policies that do not require meeting people in
person.

I think the world has changed enough in the last months that currently
perceived project expectations about key signing are getting out of
alignment with practical realities, and it might be time to explore
other options.

I do not intend to ask people to break their sensible signing policies
so that people can get into Debian. I'm interested instead in exploring
what signing policies people may have, or may be considering, that have
been staying out of our narrative because we've always been having a
specific standard one that worked.

What do you think could be alternative key signing policies, that would
be acceptable to you, that would not require traveling and meeting face
to face?


Enrico

-- 
GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini <enrico@enricozini.org>

[toc] | [next] | [standalone]

#11957

On Thu, Aug 06, 2020 at 05:54:21PM +0200, Enrico Zini wrote:
> 
> What do you think could be alternative key signing policies, that would
> be acceptable to you, that would not require traveling and meeting face
> to face?
> 
What about an added dimension that may (or may not) affect the concept
of "alternative key signing policies"?

Perhaps instead of requiring "a valid DD signature" as the basis for
"important" project actions (e.g., uploading to the archive), we should
consider rather "degree of trust associated with a collection of one or
more signatures".

So, then a key not signed by any DD (directly or indirectly) might carry
a trust value of 0.  A key directly signed by 5 DDs, each of whose keys
are also directly signed by 5 other DDs, might have a trust value of 25
(or 5^2).  If the required trust value for an upload to the unstable
suite of the archive required a trust of 15, then the first key (trust
0) would not be able to upload while the second key (trust 25) would.
If someone only had a trust level of 7, they would need to find someone
(or more than one someone) to additionally sign an upload to bring the
aggregate trust level above 15.

The trust calculation may also account for the degree of connection.
E.g., the 5 DD x 5 DD example above might instead be calculated as 5 +
(5 x 1/2)^2 = 11.25, so that unique second degree signatures count half
as much as unique first degree signatures.

Of course, the concept of requiring multiple signatures does not work
for things like voting, but the trust concept could still be applied.
In effect, our current model requires a trust level of 1 on a GPG key in
order to be considered able to cast a valid vote.  This is in addition
to the requirement of having passed through the various qualifications
to be a DD and be accepted by the project.

In any event, it is just a random idea that I had.  It is not clear if
such an approach is even feasible or desirable.

Regards,

-Roberto

-- 
Roberto C. Sánchez

[toc] | [prev] | [next] | [standalone]

#12027

On Thu, Aug 6, 2020 at 5:40 PM Roberto C. Sánchez <roberto@debian.org> wrote:
> Perhaps instead of requiring "a valid DD signature" as the basis for
> "important" project actions (e.g., uploading to the archive), we should
> consider rather "degree of trust associated with a collection of one or
> more signatures".

Forking the conversation a bit, I'm wondering what is the real threat
that we want to mitigate.
I guess the main one is: "a malicious DD uploads a package containing
a backdoor"

I propose a crude risk metric for uploads that can be generated and
used automatically:

Risk multipliers:
- Package popcon: a backdoor in a popular packages has higher impact
- Change size in SLOC: makes it easier to sneak in a backdoor
- Is it a binary upload?
- Is it a NMU? Is it the first NMU of such DD against such package?
- Is the uploader a DD or DM?

Risk dividers:
- Number of signatures on the uploader's GPG key
- Number of days since the uploader's NM process (can make the
malicious DD way less effective)
- Number of packages maintained by the uploader (perhaps?)
- NMU delay in days (perhaps?)

Very high-risk uploads could require an approval from a second DD.
As an added benefit, this makes our workstations and GPG keys less
interesting targets for attackers.
It could make DDs less likely to be coerced by legal means, work
pressure, or other.
Perhaps it might also simplify the progress between sponsored
maintainer -> DM -> DD and
encourage good practices.

Any risk equation can be debated endlessly... but it seems like an
improvement over what we have.

Thanks!
--
Federico

[toc] | [prev] | [next] | [standalone]

#12028

[Multipart message — attachments visible in raw view] — view raw

Quoting Federico Ceratto (2020-08-17 20:17:49)
> On Thu, Aug 6, 2020 at 5:40 PM Roberto C. Sánchez <roberto@debian.org> wrote:
> > Perhaps instead of requiring "a valid DD signature" as the basis for
> > "important" project actions (e.g., uploading to the archive), we should
> > consider rather "degree of trust associated with a collection of one or
> > more signatures".
> 
> Forking the conversation a bit, I'm wondering what is the real threat
> that we want to mitigate.
> I guess the main one is: "a malicious DD uploads a package containing
> a backdoor"

Also: "a malicious DD votes twice"

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

[toc] | [prev] | [next] | [standalone]

#12029

On Mon, Aug 17, 2020 at 08:39:02PM +0200, Jonas Smedegaard wrote:
> Quoting Federico Ceratto (2020-08-17 20:17:49)
> > On Thu, Aug 6, 2020 at 5:40 PM Roberto C. Sánchez <roberto@debian.org> wrote:
> > > Perhaps instead of requiring "a valid DD signature" as the basis for
> > > "important" project actions (e.g., uploading to the archive), we should
> > > consider rather "degree of trust associated with a collection of one or
> > > more signatures".
> > 
> > Forking the conversation a bit, I'm wondering what is the real threat
> > that we want to mitigate.
> > I guess the main one is: "a malicious DD uploads a package containing
> > a backdoor"
> 
> Also: "a malicious DD votes twice"

If the term "malicious DD" is reasonable, we have a bigger problem than "votes
twice" or "uploads a backdoor".

aka, "a malicious DD exists" is already a problem.

-- 
To the thief who stole my anti-depressants: I hope you're happy

  -- seen somewhere on the Internet on a photo of a billboard

[toc] | [prev] | [next] | [standalone]

#12030

On Wednesday, August 19, 2020 09:33:04 AM Wouter Verhelst wrote:
> If the term "malicious DD" is reasonable, we have a bigger problem than
> "votes twice" or "uploads a backdoor".
> 
> aka, "a malicious DD exists" is already a problem.

Do you have a suggested solution?

I believe there are circumstances in which a non-malicious DD could evolve to 
a malicious DD.

Or that a malicious DD could be very hard to detect if he didn't want to be 
detected (e.g., sociopath / psychopath).

[toc] | [prev] | [next] | [standalone]

#12031

[Multipart message — attachments visible in raw view] — view raw

rhkramer@gmail.com writes:

> On Wednesday, August 19, 2020 09:33:04 AM Wouter Verhelst wrote:
>> If the term "malicious DD" is reasonable, we have a bigger problem than
>> "votes twice" or "uploads a backdoor".
>> 
>> aka, "a malicious DD exists" is already a problem.
>
> Do you have a suggested solution?
>
> I believe there are circumstances in which a non-malicious DD could evolve to 
> a malicious DD.
>
> Or that a malicious DD could be very hard to detect if he didn't want to be 
> detected (e.g., sociopath / psychopath).

Conjuring up a "mallicious DD" seems to carry with it the assumption
that only bad people do bad things, which seems naive to me.

This conversation reminds me of the trade-offs involved in airport
security.

One can decide to spend money on security theatre (e.g. expensive
scanners) or general resilience (e.g. more ambulances and emergency
responders). The former are much easier to point at, but the latter do
more to save lives because people having a medical emergency while
queing for checkin is _way_ more common than someone with actual
terrorist intent deciding to try to sneak an actual weapon through
security.

In this situation, tightening up our proceedures regarding keys strikes
me as much closer to the security theater end of the spectrum, while
efforts like Reproducible Builds are at the general resilience end.

If I were a sociopath contemplating sabotage in the Free Software
sphere, going to the effort of becoming a DD, even for the first time,
would be nowhere near the top of my list.

Does DAM actually have any cases at all where they suspect a previously
expelled DD of trying to sneak back into the project under a new ID?

If not, then either our proceedures are already broken enough that
temproarily slackening keysigning protocols won't make the slightest
difference, or the threat is probably not worth worrying about.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/    http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,    GERMANY

[toc] | [prev] | [next] | [standalone]

#12032

[Multipart message — attachments visible in raw view] — view raw

On Thu, Aug 20, 2020 at 10:05:42AM +0200, Philip Hands wrote:
> If I were a sociopath contemplating sabotage in the Free Software
> sphere, going to the effort of becoming a DD, even for the first time,
> would be nowhere near the top of my list.
Indeed, I would sabotage some upstream code directly.

-- 
WBR, wRAR

[toc] | [prev] | [next] | [standalone]

#12033

On Thu, 2020-08-20 at 10:05 +0200, Philip Hands wrote:
> Conjuring up a "mallicious DD" seems to carry with it the assumption
> that only bad people do bad things, which seems naive to me.
> 
> This conversation reminds me of the trade-offs involved in airport
> security.
> 
> One can decide to spend money on security theatre (e.g. expensive
> scanners) or general resilience (e.g. more ambulances and emergency
> responders)

The number of airplane hijackings has gone down significantly[1] while
the amount of air travel has increased by a lot (passenger-kilometers
per year by more than factor 10 or so between 1970 and 2010 from some
graph I found).  So it seems to be effective.

Maybe the "security theater" even pays for itself given planes are
fairly expensive? :-)

  [1]: https://www.statista.com/chart/4560/airliner-hijackings-have-become-rare-events/

> In this situation, tightening up our proceedures regarding keys strikes
> me as much closer to the security theater end of the spectrum, while
> efforts like Reproducible Builds are at the general resilience end.

One could just do both.  I think I have seen, for example, automated
external defibrillators in public buildings like airports.

> If I were a sociopath contemplating sabotage in the Free Software
> sphere, going to the effort of becoming a DD, even for the first time,
> would be nowhere near the top of my list.
> 
> Does DAM actually have any cases at all where they suspect a previously
> expelled DD of trying to sneak back into the project under a new ID?
> 
> If not, then either our proceedures are already broken enough that
> temproarily slackening keysigning protocols won't make the slightest
> difference, or the threat is probably not worth worrying about.

If a fire alarm wasn't triggered by a fire for some time, should it be
removed? Maybe the procedures just work reasonably well.

Ansgar

[toc] | [prev] | [next] | [standalone]

#12034

[Multipart message — attachments visible in raw view] — view raw

Quoting Philip Hands (2020-08-20 10:05:42)
> rhkramer@gmail.com writes:
> 
> > On Wednesday, August 19, 2020 09:33:04 AM Wouter Verhelst wrote:
> >> If the term "malicious DD" is reasonable, we have a bigger problem 
> >> than "votes twice" or "uploads a backdoor".
> >> 
> >> aka, "a malicious DD exists" is already a problem.
> >
> > Do you have a suggested solution?
> >
> > I believe there are circumstances in which a non-malicious DD could 
> > evolve to a malicious DD.
> >
> > Or that a malicious DD could be very hard to detect if he didn't 
> > want to be detected (e.g., sociopath / psychopath).
> 
> Conjuring up a "mallicious DD" seems to carry with it the assumption 
> that only bad people do bad things, which seems naive to me.
> 
> This conversation reminds me of the trade-offs involved in airport 
> security.
> 
> One can decide to spend money on security theatre (e.g. expensive 
> scanners) or general resilience (e.g. more ambulances and emergency 
> responders). The former are much easier to point at, but the latter do 
> more to save lives because people having a medical emergency while 
> queing for checkin is _way_ more common than someone with actual 
> terrorist intent deciding to try to sneak an actual weapon through 
> security.
> 
> In this situation, tightening up our proceedures regarding keys 
> strikes me as much closer to the security theater end of the spectrum, 
> while efforts like Reproducible Builds are at the general resilience 
> end.
> 
> If I were a sociopath contemplating sabotage in the Free Software 
> sphere, going to the effort of becoming a DD, even for the first time, 
> would be nowhere near the top of my list.
> 
> Does DAM actually have any cases at all where they suspect a 
> previously expelled DD of trying to sneak back into the project under 
> a new ID?
> 
> If not, then either our proceedures are already broken enough that 
> temproarily slackening keysigning protocols won't make the slightest 
> difference, or the threat is probably not worth worrying about.

Seems to me you are addressing only the "uploads a backdoor".

Any opinion on the "votes twice" part? Anyone?


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

[toc] | [prev] | [next] | [standalone]

#12035

Jonas Smedegaard <dr@jones.dk> writes:

> Any opinion on the "votes twice" part? Anyone?

How many decisions have we had that were decided by a slim enough margin
that you believe fraud could have changed the outcome?

What have we voted on that you think anyone would care sufficiently about
to do the tedious and time-consuming work required to get a fake identity
with voting privileges?

I'm dubious of the threat model.  Injecting malicious code into the
archive seems to have a far, far higher reward to effort ratio than voting
in our rare and generally not very close project votes.

-- 
Russ Allbery (rra@debian.org)              <https://www.eyrie.org/~eagle/>

[toc] | [prev] | [next] | [standalone]

#12036

* Philip Hands:

> If I were a sociopath contemplating sabotage in the Free Software
> sphere, going to the effort of becoming a DD, even for the first time,
> would be nowhere near the top of my list.

Even if you got a peer-reviewed research paper out of it?  (If I
recall correctly, academics already set up a fake Debian mirror and
wrote a paper about it.)

[toc] | [prev] | [next] | [standalone]

#11958

Hi Enrico,

On Thu, Aug 6, 2020 at 9:15 AM Enrico Zini <enrico@enricozini.org> wrote:
>
> What do you think could be alternative key signing policies
> ... that would not require ... meeting face to face?

Perhaps a video meeting on Jitsi [1] is acceptable? People could
present their IDs to the camera. Maybe the certification level in GPG
should be casual ('2') for such interactions.

Please note that our instructions may need to be updated. They state:
"You should never sign a key for somebody else you haven't met
personally." [2]

[1] https://jitsi.debian.social/
[2] https://www.debian.org/events/keysigning

Thanks for taking the initiative on such an important matter.

Kind regards
Felix Lechner

[toc] | [prev] | [next] | [standalone]

#11959

[Multipart message — attachments visible in raw view] — view raw

Hi Enrico,

thanks for bringing this up.

Quoting Enrico Zini (2020-08-06 17:54:21)
> What do you think could be alternative key signing policies, that would be
> acceptable to you, that would not require traveling and meeting face to face?

I'm currently in the situation of sponsoring a very skilled prospective new DM
with a couple of packages. My mentee is signing all their git commits and git
tags as well as their emails to me with the same GPG key. This has now been
going on for a few months. So I'm in the situation, that I know that somebody
owning a certain private key is either (correct me if I'm wrong):

 - doing a lot of good work
 - being impersonated by an evil third party that always intercepts their
   contributions to Debian (git commits to salsa) as well as their (encrypted!)
   emails to me and replaces the signature with their own

My question to you guys is: how valuable is it, that I (or anybody else) is
meeting the individual owning this key in person and indeed verifies (how
skilled are *you* in spotting a counterfeit ID?) that a nation state thinks
that the person of such name does really exist.

What added value does the connection to a government ID give to Debian?

Why would it be wrong of me to sign the key of this person? No matter who is
behind that key: the person with that key has shown to produce great
contributions for a couple of months *or* there is a really dedicated evil
person trying some scheme over a really long period of time with me. If the
latter is the case, would a person with that much commitment not also be able
to fool me with a fake national ID?

So in my opinion (and please correct my assumptions if they are wrong), an
acceptable key signing policy would also be one, where a prospective DM has
shown over several months to produce work that is always signed with the same
key and maybe even communicated (for example via email, maybe even encrypted)
using that GPG key.

Thanks!

cheers, josch

[toc] | [prev] | [next] | [standalone]

#11966

[Multipart message — attachments visible in raw view] — view raw

On Thu, Aug 06, 2020 at 08:44:57PM +0200, Giovanni Mascellani wrote:
> Not to mention that as far as I know there are already DDs whose key
> identity does not correspond to any government-given identity. So we
> already acknowledge that we don't really care about what is your "legal"
> name. 

this is factually incorrect: while there are DDs who don't go by their
government backed identity indeed, DAM or ftp master (dont rememeber which)
do know their government identity.


-- 
cheers,
	Holger

-------------------------------------------------------------------------------
               holger@(debian|reproducible-builds|layer-acht).org
       PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C

[toc] | [prev] | [next] | [standalone]

#11960

[Multipart message — attachments visible in raw view] — view raw

Quoting Enrico Zini (2020-08-06 17:54:21)
[...]

> 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.
> 
> For example, speaking of myself only, if my goal is to raise the cost 
> of impersonation or sock puppet identities, then probably signing 
> someone's key after having worked with them online for a significant 
> time, would require a much higher cost than showing up at a keysigning 
> party with a fake ID good enough to fool me.

[...]

> What do you think could be alternative key signing policies, that 
> would be acceptable to you, that would not require traveling and 
> meeting face to face?

A rule that I try to apply for my key-signing, and which I think ties 
into your interesting reflections here, is that I will sign the key of 
someone whom I feel I would be able to recognize if randomly bumping 
into them years later on a bus.

It forces me to try pay attention to the person for long enough that 
they make a (hopefully) lasting impression on me.  Often I suggest that 
we sit for a moment and they tell something about themselves.  Not an 
interview or a test, just as an aid in etching an impression.  Sometimes 
we end up hanging out for longer than "needed".  Sometimes the 
atmosphere is too hectic and we cannot find the calm to tune in - and 
then delay the "session".

I've practiced my rule mostly with in-person meetings - also because I 
enjoy meeting people face to face.  But a few times I have felt 
comfortable that I "knew" someone after working for some time with them 
online, without having had the opportunity to meet physically.

It feels reliable to me to trust a passport, and it feels unreliable to 
me to skip it.  But I find it helpful to try challenge that feeling and 
try peel off what is simply habit.


Thanks for bringing this up, Enrico,

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

[toc] | [prev] | [next] | [standalone]

#11961

On 2020-08-06 17:54, Enrico Zini wrote:
> What do you think could be alternative key signing policies, that would
> be acceptable to you, that would not require traveling and meeting face
> to face?

As food for thought, there was a longish thread "Why are in-person
meetings required for the debian keyring?" on -project a few years ago
with good inputs both for and against.

    https://lists.debian.org/debian-project/2015/02/msg00017.html

[toc] | [prev] | [next] | [standalone]

#11962

[Multipart message — attachments visible in raw view] — view raw

Hello,

El dj., 6 d’ag. 2020, 18:08, Enrico Zini <enrico@enricozini.org> va
escriure:

>
> What do you think could be alternative key signing policies, that would
> be acceptable to you, that would not require traveling and meeting face
> to face?
>

  - you know that person in the real world, or at least you have verified
and trusted their real world credentials somehow (*).

(*) Verification of real world credentials could be done by different
means, probably simplest would be having a video call (that would be fine
for me).

[toc] | [prev] | [next] | [standalone]

#11963

[Multipart message — attachments visible in raw view] — view raw

On 2020-08-06 11:54 a.m., Enrico Zini wrote:
> What do you think could be alternative key signing policies, that would
> be acceptable to you, that would not require traveling and meeting face
> to face?

Hello Enrico :)

Thank you for bringing this up.

On 2020-08-06 1:26 p.m., Johannes Schauer wrote:
> So in my opinion (and please correct my assumptions if they are
> wrong), an acceptable key signing policy would also be one, where a
> prospective DM has shown over several months to produce work that is
> always signed with the same key and maybe even communicated (for
> example via email, maybe even encrypted) using that GPG key.

This makes sense.

Whoever advocated for me to become a DD advocated for the person that
was signing patches with E301 54F5 429F FBB9 B22E 49C2 DA82 830E 3CCC
3A3A. They had never met me. It didn't matter. My key was added to the
keyring because whoever was signing emails and uploaded with that key
seemed to care enough about Debian and seemed to produce work that is
good enough to be let in the archive.

There were also DD signatures on my key at the time, but none of them
had worked with me. They only loosely verified that the awkward guy at
the coffee shop received or intercepted emails sent at
alexandre@alexandreviau.net.

I have recently advocated for somebody to become DM. I have some
indirect connection with him in the real world, but I have never met him
in person. Having his key signed is blocking his NM DM process.

I am sure that I "know" this guy. He signs all of his messages with the
same PGP key. He signs all of his patches with the same PGP key. He
cares about Debian. He asks good questions. If we meet at DebConf, I'll
be able to tell that its him. I'll point him to you guys so that you
know who he is.

We will organize a video call, just to meet outside of emails, but I
won't verify his ID, and I will sign his key so that we can move forward.

Feel free to attribute whatever value that you want to that signature. I
think that given my history with that person it holds much more values
than the 2-minutes KSP ones.

Cheers,

-- 
Alexandre Viau
aviau@debian.org

[toc] | [prev] | [next] | [standalone]

#11968

[Multipart message — attachments visible in raw view] — view raw

Quoting Alexandre Viau (2020-08-07 05:44:34)
> On 2020-08-06 11:54 a.m., Enrico Zini wrote:
> > What do you think could be alternative key signing policies, that would
> > be acceptable to you, that would not require traveling and meeting face
> > to face?
> 
> Hello Enrico :)
> 
> Thank you for bringing this up.
> 
> On 2020-08-06 1:26 p.m., Johannes Schauer wrote:
> > So in my opinion (and please correct my assumptions if they are
> > wrong), an acceptable key signing policy would also be one, where a
> > prospective DM has shown over several months to produce work that is
> > always signed with the same key and maybe even communicated (for
> > example via email, maybe even encrypted) using that GPG key.
> 
> This makes sense.
> 
> Whoever advocated for me to become a DD advocated for the person that
> was signing patches with E301 54F5 429F FBB9 B22E 49C2 DA82 830E 3CCC
> 3A3A. They had never met me. It didn't matter. My key was added to the
> keyring because whoever was signing emails and uploaded with that key
> seemed to care enough about Debian and seemed to produce work that is
> good enough to be let in the archive.
> 
> There were also DD signatures on my key at the time, but none of them
> had worked with me. They only loosely verified that the awkward guy at
> the coffee shop received or intercepted emails sent at
> alexandre@alexandreviau.net.
> 
> I have recently advocated for somebody to become DM. I have some 
> indirect connection with him in the real world, but I have never met 
> him in person. Having his key signed is blocking his NM DM process.
> 
> I am sure that I "know" this guy. He signs all of his messages with 
> the same PGP key. He signs all of his patches with the same PGP key. 
> He cares about Debian. He asks good questions. If we meet at DebConf, 
> I'll be able to tell that its him. I'll point him to you guys so that 
> you know who he is.
> 
> We will organize a video call, just to meet outside of emails, but I 
> won't verify his ID, and I will sign his key so that we can move 
> forward.
> 
> Feel free to attribute whatever value that you want to that signature. 
> I think that given my history with that person it holds much more 
> values than the 2-minutes KSP ones.

Advocacy and autenticity are separate things.

I can vouch for the person in control of E301 54F5 429F FBB9 B22E 49C2 
DA82 830E 3CCC 3A3A regarding quality of Debian work and understanding 
of Debian spirit, when I have seen some work and some personal 
reflections signed by that identifier.

I can autenticate the person in control of E301 54F5 429F FBB9 B22E 49C2 
DA82 830E 3CCC 3A3A when I somehow gain confidence of who that person is 
- maybe through signed work and reflections, maybe through governmental 
papers, maybe through physical/audio/video presence - more likely 
through a combination of most possible of those.

It is important for Debian that all members meat a certain level of 
competences and concensus of spirit (on Debian matters only).

...but it is also important for Debian that members each are represented 
through a single identifier - not multiple.

If only looking at work and reflections, I'd argue that it would be much 
much harder to notice if E301 54F5 429F FBB9 B22E 49C2 DA82 830E 3CCC 
3A3A was controlled not by an independent person but e.g. me.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | linux.debian.project

csiph-web