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

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

Re: Keysigning in times of COVID-19

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

Contents

  Re: Keysigning in times of COVID-19 Gerardo Ballabio <gerardo.ballabio@gmail.com> - 2020-08-07 10:40 +0200
    Re: Keysigning in times of COVID-19 Jonas Smedegaard <dr@jones.dk> - 2020-08-07 11:10 +0200
      Re: Keysigning in times of COVID-19 Sam Hartman <hartmans@debian.org> - 2020-08-07 21:40 +0200
        Re: Keysigning in times of COVID-19 Jonas Smedegaard <dr@jones.dk> - 2020-08-07 22:50 +0200
          Re: Keysigning in times of COVID-19 Sam Hartman <hartmans@debian.org> - 2020-08-08 00:00 +0200
            Re: Keysigning in times of COVID-19 Jonas Smedegaard <dr@jones.dk> - 2020-08-08 04:00 +0200
        Re: Keysigning in times of COVID-19 Cindy Sue Causey <butterflybytes@gmail.com> - 2020-08-07 23:30 +0200
        Re: Keysigning in times of COVID-19 Olek Wojnar <olek@debian.org> - 2020-08-08 04:00 +0200
          Re: Keysigning in times of COVID-19 Sam Hartman <hartmans@debian.org> - 2020-08-08 18:30 +0200
            Re: Keysigning in times of COVID-19 Olek Wojnar <olek@debian.org> - 2020-08-08 22:50 +0200
              Re: Keysigning in times of COVID-19 Sam Hartman <hartmans@debian.org> - 2020-08-09 01:10 +0200
                Re: Keysigning in times of COVID-19 Olek Wojnar <olek@debian.org> - 2020-08-09 03:40 +0200
                  Re: Keysigning in times of COVID-19 Felix Lechner <felix.lechner@lease-up.com> - 2020-08-09 07:40 +0200
                  Re: Keysigning in times of COVID-19 Sam Hartman <hartmans@debian.org> - 2020-08-09 15:10 +0200
                    Re: Keysigning in times of COVID-19 Holger Levsen <holger@layer-acht.org> - 2020-08-10 12:00 +0200
                      How to Value a Community Sam Hartman <hartmans@debian.org> - 2020-08-10 14:20 +0200
                Re: Keysigning in times of COVID-19 Eldon Koyle <ekoyle@gmail.com> - 2020-08-09 06:20 +0200

#11964 — Re: Keysigning in times of COVID-19

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.

I agree that it would be ok to sign that key.

However, suppose that the key gets lost or compromised.
Then the prospective DM creates a new key and asks you to sign it.
How would you verify that the person that shows up with the new key is
the same person that you have been working with?

I can't think of an answer that doesn't require connecting the person
to a verified personal identity (that may or may not be a
government-certified name).

Gerardo

[toc] | [next] | [standalone]

#11965

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

Quoting Gerardo Ballabio (2020-08-07 10:34:20)
> 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.
> 
> I agree that it would be ok to sign that key.
> 
> However, suppose that the key gets lost or compromised.
> Then the prospective DM creates a new key and asks you to sign it.
> How would you verify that the person that shows up with the new key is
> the same person that you have been working with?
> 
> I can't think of an answer that doesn't require connecting the person
> to a verified personal identity (that may or may not be a
> government-certified name).

If ok for first round of several months collaboration was conducted 
without ties to governmental papers, then continuation should as well.

If you are not confident that the person is the same from coding style, 
text-chatting style, mimics in videochat etc., then apply same 
requirement as you did for first round: Trust only after several months 
of collaboration tied to the _new_ key.


 - 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]

#11972

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

TL;DR: I think without some link back to real world identity, we open
ourselves up to attacks where people build trust only to betray us.

>>>>> "Jonas" == Jonas Smedegaard <dr@jones.dk> writes:

    Jonas> Quoting Gerardo Ballabio (2020-08-07 10:34:20)
    >> Johannes Schauer wrote:
    Jonas> If ok for first round of several months collaboration was
    Jonas> conducted without ties to governmental papers, then
    Jonas> continuation should as well.

    Jonas> If you are not confident that the person is the same from
    Jonas> coding style, text-chatting style, mimics in videochat etc.,
    Jonas> then apply same requirement as you did for first round: Trust
    Jonas> only after several months of collaboration tied to the _new_
    Jonas> key.

Jonas, first thanks for describing your rule about interacting with
someone enough that you'd recognize them later.

I think that makes sense.  I'm uncomfortable though with the idea that
someone could get their key signed by doing good work, lose the key and
get another key signed later by again doing good work.
That opens up attacks that I care about in our model of trust.

The threat I care about that I hope key signing will help protect us
from is the threat of someone intentionally decreasing the integrity of
Debian.  That is, someone includes malicious code (or similarly
undermines our reputation).

In my mind, we want to require

1) That someone builds up a significant positive reputation

and

2) That  it would be costly for them to burn that reputation to maount
an attack.

In this model the advantage of trying to tie a key back to a real-world
identity is that we only get one of those.
No matter how much good work I do in the future, I cannot escape a
betrayal of trust if we tie it back to Sam Hartman.

But if we don't tie it back, let's say I do a year's worth of good work
as DebianDude and eventually get my key signed.
I can burn that reputation for an attack, having lost a year, but not
lost my future possibility of spending another year and getting trusted
again (possibly for another attack).

An attacker might be much more willing to burn their DebianDude
reputation than their Sam Hartman reputation.


Now, that real world identity might not even need to be a real name.
If you're going to recognize the person, know that you've already signed
their key, that's probably enough.
You can think think about whether this is a legitimate and harmless
identifier change or whether this is an attempt to cause harm.  But you
can consider all the identities you've known and link it back to the
person.
For me, that linking is key to key signing being valuable.

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

#11973

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

Quoting Sam Hartman (2020-08-07 21:14:10)
> 
> TL;DR: I think without some link back to real world identity, we open
> ourselves up to attacks where people build trust only to betray us.
> 
> >>>>> "Jonas" == Jonas Smedegaard <dr@jones.dk> writes:
> 
>     Jonas> Quoting Gerardo Ballabio (2020-08-07 10:34:20)
>     >> Johannes Schauer wrote:
>     Jonas> If ok for first round of several months collaboration was
>     Jonas> conducted without ties to governmental papers, then
>     Jonas> continuation should as well.
> 
>     Jonas> If you are not confident that the person is the same from
>     Jonas> coding style, text-chatting style, mimics in videochat etc.,
>     Jonas> then apply same requirement as you did for first round: Trust
>     Jonas> only after several months of collaboration tied to the _new_
>     Jonas> key.
> 
> Jonas, first thanks for describing your rule about interacting with
> someone enough that you'd recognize them later.
> 
> I think that makes sense.  I'm uncomfortable though with the idea that
> someone could get their key signed by doing good work, lose the key and
> get another key signed later by again doing good work.
> That opens up attacks that I care about in our model of trust.

I agree.

I feel that you are somewhat quoting me out of context:

For the record, I do *not* find "several months of [remote] 
collaboration" adequate for trusting an identity.  I simply repeated 
that criterium from the previous poster - the point I wanted to make was 
not to confirm the _concrete_ presented criterium, but instead that 
whatever criteria was adequate first time you met someone should be 
adequate the next time as well.

Yes, we should try be aware of the risk of betrayal - but that can 
equally well happen at first encounter (I don't know everyone in Debian 
so some could fool me arguing they were "new").  And it can happen with 
a faked name and faked passport (I expect it to be *cheap* to fake a 
passport when not validating by looking up a central database).


 - 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]

#11975

>>>>> "Jonas" == Jonas Smedegaard <dr@jones.dk> writes:

    Jonas> I feel that you are somewhat quoting me out of context:

    Jonas> For the record, I do *not* find "several months of [remote]
    Jonas> collaboration" adequate for trusting an identity.  I simply
    Jonas> repeated that criterium from the previous poster - the point
    Jonas> I wanted to make was not to confirm the _concrete_ presented
    Jonas> criterium, but instead that whatever criteria was adequate
    Jonas> first time you met someone should be adequate the next time
    Jonas> as well.

I'm sorry.
I was aware I was doing this and suspected that you might not agree with
the original criteria.  I failed to make that clear in my message.
I wasn't sure where to jump in and apparently chose poorly.

Thanks for calling me on this.

--Sam

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

#11976

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

Quoting Sam Hartman (2020-08-07 23:29:23)
> >>>>> "Jonas" == Jonas Smedegaard <dr@jones.dk> writes:
> 
>     Jonas> I feel that you are somewhat quoting me out of context:
> 
>     Jonas> For the record, I do *not* find "several months of [remote]
>     Jonas> collaboration" adequate for trusting an identity.  I simply
>     Jonas> repeated that criterium from the previous poster - the point
>     Jonas> I wanted to make was not to confirm the _concrete_ presented
>     Jonas> criterium, but instead that whatever criteria was adequate
>     Jonas> first time you met someone should be adequate the next time
>     Jonas> as well.
> 
> I'm sorry.
> I was aware I was doing this and suspected that you might not agree with
> the original criteria.  I failed to make that clear in my message.
> I wasn't sure where to jump in and apparently chose poorly.
> 
> Thanks for calling me on this.

I was not offended, just felt the need to clarify when you "put it out 
on display".

Thanks,

 - 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]

#11974

On 8/7/20, Sam Hartman <hartmans@debian.org> wrote:
>
> TL;DR: I think without some link back to real world identity, we open
> ourselves up to attacks where people build trust only to betray us.


Hi, Everyone.. I've tried to follow some of this conversation but keep
getting distracted. I haven't known where to chime in with Real World
experience, either.

My interest in this is that I *have* been impersonated online. It
matters because I'm trying to work my way through a package that was
abandoned, apparently because so many things have been being upgraded
and refined within Debian the last few years..

So, in my case, what had happened was....

Perps, a very local group that operates across the United States,
created a Twitter account [0] using.. my full name.. my avatar.. my
personal images including that large header image.. AND my complete
textual bio such as it was at that moment in time.

Twitter took that fake account down so fast when I contacted them that
I didn't get a printscreen as some kind of proof. The original
homepage for it is still out there gathering cyber dust.

So, you know... Full blown, malicious impersonation is very real for
some of us out here. Only reason I ever found out was because Google
Alerts brought my own name back to my inbox one day.

As another instance showing Debian does need to keep things in check,
I just tripped over something from last year. It appears to
potentially still be a possible active case so I'm not going to share
that much of the details right now.

The guy's no longer around.... but someone posted something cryptic on
his social networking.. after he was gone. It's possible he used
something like Hootsuite or something to leave a timed post set for
the Future. Only time will tell on that..

He was a techie.. possibly building himself a notable reputation
around the Internet. He followed very few people.. but he picked at
least one *I* know from online interactions..

Am still in the process of trying to figure out who's who and doing
what with the remnants of his presence left on the Internet.
Meanwhile, I swear I've been back to Debian's Developers at least
once.. or maybe more. I don't know if I'm reading something wrong...
or if it's my system glitching at just the wrong time.. or what.

The disconnect that repeatedly landed me at a Debian email address was
happening somewhere between his old profile, his followers, and who he
followed. I wasn't copying an email address when the Debian one kept
appearing (at least 4 or 5 times). I haven't proven to myself quite
how that happened, yet, but I do have one clue that needs followed up
(in my brain, grin).

Date of last activity for some bits of that other case goes back to
just before that Twitter account was created in my full likeness. Only
difference in my own case was the perps gave their physical location
as West Virginia instead of Georgia.

Oh, and my account was NOT hacked. It was instead replicated visually
then placed under a completely new account name... that had my very
real name attached.

I'm signing off here for now. Too much going in too many directions. I
will most certainly be trying to find the right way to bring it up
with full details if that other case really, in fact, seems to have
some kind of 100% reproducible identity weirdness leading to Debian's
front door....

Hugging you all for all the hard work you do. I wouldn't be able to do
any of what I do without this kind of project being available...

Cindy.... :)

[0] Suspended Twitter account placeholder for studebarke (I'm "Studebaker")
https://twitter.com/studebarke

-- 
Cindy-Sue Causey
Talking Rock, Pickens County, Georgia, USA

* runs with birdseed *

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

#11977

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

Hi Sam,

On Fri, Aug 7, 2020 at 3:39 PM Sam Hartman <hartmans@debian.org> wrote:

>
> TL;DR: I think without some link back to real world identity, we open
> ourselves up to attacks where people build trust only to betray us.
>

I agree with you that this is a potentially-serious problem. However, I'm
not sure that keysigning is the right place to address it. I've seen a
number of comments, including yours, seemingly conflate the trust we place
in the validity of a cryptographic key and the trust we place in someone
during the NM process. I think it is important to distinguish between the
two.

So, I don't really care (much) how technically competent or hard-working
someone is when I sign their key. Thanks to some great tools, it's fairly
easy to verify that they do indeed control the email addresses tied to
their key. That's what I care about at that point in time.

Now, if they want me to sponsor them in the NM process, that's when I am
going to take a much closer look at their work and their attitude and
determine if we should grant them the level of trust that goes with
completing that process. That is also where I humbly submit we should have
some level of identity verification. I'm not sure what that should look
like but the point is where it should take place. If we previously verified
someone's identity and subsequently banned them from the project, the NM
process seems like the logical place to ensure that such a person is not
able to slip back into Debian. Centralized and standardized is much easier
in a process administered by a few people (NM) than in a distributed
process with substantial variability and no means of reliable QA (random
keysigning party).

-Olek

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

#11978

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

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 <olek@debian.org> 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.

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

#11979

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

Hi Sam,

On Sat, Aug 8, 2020, 11:46 Sam Hartman <hartmans@debian.org> 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 <olek@debian.org> 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

>

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

#11980

>>>>> "Olek" == Olek Wojnar <olek@debian.org> 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.

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

#11981

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

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 <hartmans@debian.org> 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?

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

#11983

Hi Olek,

On Sat, Aug 8, 2020 at 6:36 PM Olek Wojnar <olek@debian.org> 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

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

#11986

>>>>> "Olek" == Olek Wojnar <olek@debian.org> writes:

    Olek>    Sam, I do not appreciate your aspersions and I think your

Hi.
It sounds like you are hearing me as disagreeing with *you* and not with
some combination of your ideas and how they are presented.
I'd like to offer to sit down virtually and work through this.
I don't want to come across as hostile, and I hope that we would both
choose to avoid frustration or worse building between us.

However my experience is that mailing lists are not the best media for
working through things when perceptions of hostility get involved.
If you'd be open I propose that we get together on IRC or phone (with a
third party if that would make you feel more comfortable) and see if we
can work to a place where you feel valued, even if we don't get to a
place where we are in agreement on everything.
After I'd be happy to come back to the list, express any regrets and
summarize what I've learned about how to approach this situation without
creating negative feelings.

If you are open to this, let's coordinate a time off-list.

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

#11987

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

On Sun, Aug 09, 2020 at 08:51:30AM -0400, Sam Hartman wrote:
> It sounds like you are hearing me as disagreeing with *you* and not with
> some combination of your ideas and how they are presented.
> I'd like to offer to sit down virtually and work through this.
> I don't want to come across as hostile, and I hope that we would both
> choose to avoid frustration or worse building between us.
> 
> However my experience is that mailing lists are not the best media for
> working through things when perceptions of hostility get involved.
> If you'd be open I propose that we get together on IRC or phone (with a
> third party if that would make you feel more comfortable) and see if we
> can work to a place where you feel valued, even if we don't get to a
> place where we are in agreement on everything.
> After I'd be happy to come back to the list, express any regrets and
> summarize what I've learned about how to approach this situation without
> creating negative feelings.
> 
> If you are open to this, let's coordinate a time off-list.

Sam, you accused Olek of derailing the situation, which (AFAICS) he disagrees
with, and now you are "offering" to solve this problem by Olek investing 
more time to solve a problem that doesnt also in my book doesnt exist.

btw, I could also say you Sam are derailing Enricos thread as well, voila.

Olek replied how/when keysigning is important to them, with a concrete use-case
(sponsoring uploads), which IMO is a very fine use case of key signing
and I am puzzled about your response of cornering into counceling his behaviour.


-- 
cheers,
	Holger

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

There are no jobs on a dead planet.

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

#11988 — How to Value a Community

>>>>> "Holger" == Holger Levsen <holger@layer-acht.org> writes:


    Holger> Sam, you accused Olek of derailing the situation, which
    Holger> (AFAICS) he disagrees with, and now you are "offering" to
    Holger> solve this problem by Olek investing more time to solve a
    Holger> problem that doesnt also in my book doesnt exist.

    Holger> btw, I could also say you Sam are derailing Enricos thread
    Holger> as well, voila.

I show value for the community by being willing to dedicate my time and
energy when people are upset and hurt by what I've done.
I try to show that I value them by being willing to put in my time to
hear them and learn from them.
I do not try to force this.
But that's how I show that I value them as members of the community and
how I show that I value building a community that works together rather
than snipes at each other.

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

#11982

On Sat, Aug 8, 2020 at 5:04 PM Sam Hartman <hartmans@debian.org> wrote:
<snip>
> 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.
<snip>

Would it be a reasonable compromise to start a new thread rather than
just quashing any deeper discussion?

-- 
Eldon

[toc] | [prev] | [standalone]

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

csiph-web