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

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

Salsa as authentication provider for Debian

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

Contents

  Salsa as authentication provider for Debian Bastian Blank <waldi@debian.org> - 2020-04-06 18:00 +0200
    Re: Salsa as authentication provider for Debian Luca Filipozzi <lfilipoz@debian.org> - 2020-04-06 18:20 +0200
      Re: Salsa as authentication provider for Debian Enrico Zini <enrico@enricozini.org> - 2020-04-06 20:50 +0200
        Re: Salsa as authentication provider for Debian Luca Filipozzi <lfilipoz@debian.org> - 2020-04-06 21:20 +0200
          Re: Salsa as authentication provider for Debian Enrico Zini <enrico@enricozini.org> - 2020-04-07 10:40 +0200
            Re: Salsa as authentication provider for Debian Geert Stappers <stappers@debian.org> - 2020-04-07 11:30 +0200
            Re: Salsa as authentication provider for Debian Luca Filipozzi <lfilipoz@debian.org> - 2020-04-08 17:10 +0200
              Re: Salsa as authentication provider for Debian Enrico Zini <enrico@enricozini.org> - 2020-04-08 17:40 +0200
                Re: Salsa as authentication provider for Debian Luca Filipozzi <lfilipoz@debian.org> - 2020-04-08 18:00 +0200
                  Re: Salsa as authentication provider for Debian Enrico Zini <enrico@enricozini.org> - 2020-04-09 09:50 +0200
                    Re: Salsa as authentication provider for Debian Michael Lustfield <michael@lustfield.net> - 2020-04-09 12:20 +0200
                      Re: Salsa as authentication provider for Debian Enrico Zini <enrico@enricozini.org> - 2020-04-10 09:30 +0200
                  Re: Salsa as authentication provider for Debian Sam Hartman <hartmans@debian.org> - 2020-04-10 14:50 +0200
                    Re: Salsa as authentication provider for Debian Sam Hartman <hartmans@debian.org> - 2020-04-10 18:00 +0200
                      Re: Salsa as authentication provider for Debian Luca Filipozzi <lfilipoz@debian.org> - 2020-04-10 18:30 +0200
                        Re: Salsa as authentication provider for Debian Russ Allbery <rra@debian.org> - 2020-04-10 19:30 +0200
                          Re: Salsa as authentication provider for Debian Sam Hartman <hartmans@debian.org> - 2020-04-10 20:20 +0200
                            Re: Salsa as authentication provider for Debian Luca Filipozzi <lfilipoz@debian.org> - 2020-04-10 22:10 +0200
                              Re: Salsa as authentication provider for Debian Russ Allbery <rra@debian.org> - 2020-04-10 22:30 +0200
        Re: Salsa as authentication provider for Debian Michael Lustfield <michael@lustfield.net> - 2020-04-06 21:50 +0200
          Re: Salsa as authentication provider for Debian Enrico Zini <enrico@enricozini.org> - 2020-04-10 09:50 +0200
            Re: Salsa as authentication provider for Debian Enrico Zini <enrico@enricozini.org> - 2020-04-10 10:30 +0200
            Re: Salsa as authentication provider for Debian Felix Lechner <felix.lechner@lease-up.com> - 2020-04-10 21:50 +0200
              Re: Salsa as authentication provider for Debian kuLa <kula@kulisz.net> - 2020-04-11 08:30 +0200
              Re: Salsa as authentication provider for Debian Jonathan Carter <jcc@debian.org> - 2020-04-11 12:10 +0200
                Re: Salsa as authentication provider for Debian Michael Lustfield <michael@lustfield.net> - 2020-04-11 19:30 +0200
                  Re: Salsa as authentication provider for Debian Sam Hartman <leader@debian.org> - 2020-04-11 20:20 +0200
      Re: Salsa as authentication provider for Debian Bastian Blank <waldi@debian.org> - 2020-04-07 10:40 +0200
        Re: Salsa as authentication provider for Debian Luca Filipozzi <lfilipoz@debian.org> - 2020-04-08 17:30 +0200
          Re: Salsa as authentication provider for Debian Bastian Blank <waldi@debian.org> - 2020-04-10 12:20 +0200
            Re: Salsa as authentication provider for Debian Luca Filipozzi <lfilipoz@debian.org> - 2020-04-10 19:10 +0200
    Re: Salsa as authentication provider for Debian Holger Levsen <holger@layer-acht.org> - 2020-04-06 21:00 +0200
    Re: Salsa as authentication provider for Debian Xavier <yadd@debian.org> - 2020-04-07 12:40 +0200
      Re: Salsa as authentication provider for Debian Enrico Zini <enrico@enricozini.org> - 2020-04-07 14:10 +0200
        Re: Salsa as authentication provider for Debian Xavier <yadd@debian.org> - 2020-04-07 14:40 +0200
          Re: Salsa as authentication provider for Debian Enrico Zini <enrico@enricozini.org> - 2020-04-07 15:30 +0200
            Re: Salsa as authentication provider for Debian Xavier <yadd@debian.org> - 2020-04-07 15:40 +0200
              Re: Salsa as authentication provider for Debian Enrico Zini <enrico@enricozini.org> - 2020-04-07 16:10 +0200
                Re: Salsa as authentication provider for Debian Xavier <yadd@debian.org> - 2020-04-07 16:30 +0200
                  Re: Salsa as authentication provider for Debian Luca Filipozzi <lfilipoz@debian.org> - 2020-04-08 17:50 +0200
        Re: Salsa as authentication provider for Debian Michael Lustfield <michael@lustfield.net> - 2020-04-07 16:30 +0200
          Re: Salsa as authentication provider for Debian Enrico Zini <enrico@enricozini.org> - 2020-04-07 17:00 +0200
      Re: Salsa as authentication provider for Debian Luca Filipozzi <lfilipoz@debian.org> - 2020-04-08 17:40 +0200
        Re: Salsa as authentication provider for Debian Xavier <yadd@debian.org> - 2020-04-08 22:30 +0200
    Re: Salsa as authentication provider for Debian Paul Wise <pabs@debian.org> - 2020-04-07 17:30 +0200
      Re: Salsa as authentication provider for Debian Xavier <yadd@debian.org> - 2020-04-07 17:40 +0200
        Re: Salsa as authentication provider for Debian Sam Hartman <hartmans@debian.org> - 2020-04-07 19:00 +0200
          Re: Salsa as authentication provider for Debian Xavier <yadd@debian.org> - 2020-04-10 21:50 +0200
      Re: Salsa as authentication provider for Debian Enrico Zini <enrico@enricozini.org> - 2020-04-07 19:00 +0200
      Re: Salsa as authentication provider for Debian Bastian Blank <waldi@debian.org> - 2020-04-07 20:30 +0200
        Re: Salsa as authentication provider for Debian Paul Wise <pabs@debian.org> - 2020-04-08 08:00 +0200
          Re: Salsa as authentication provider for Debian Enrico Zini <enrico@enricozini.org> - 2020-04-08 11:40 +0200
    Re: Salsa as authentication provider for Debian Sam Hartman <hartmans@debian.org> - 2020-04-08 12:30 +0200
      Re: Salsa as authentication provider for Debian Luca Filipozzi <lfilipoz@debian.org> - 2020-04-08 18:00 +0200
      Re: Salsa as authentication provider for Debian Tollef Fog Heen <tfheen@err.no> - 2020-04-08 21:20 +0200
        Re: Salsa as authentication provider for Debian Steve McIntyre <93sam@debian.org> - 2020-04-08 21:40 +0200
        Re: Salsa as authentication provider for Debian Enrico Zini <enrico@enricozini.org> - 2020-04-09 09:30 +0200
          Re: Salsa as authentication provider for Debian Tollef Fog Heen <tfheen@err.no> - 2020-04-09 20:10 +0200
            Re: Salsa as authentication provider for Debian Enrico Zini <enrico@enricozini.org> - 2020-04-09 20:30 +0200
            Re: Salsa as authentication provider for Debian Sam Hartman <hartmans@debian.org> - 2020-04-09 23:30 +0200
              Re: Salsa as authentication provider for Debian Tollef Fog Heen <tfheen@err.no> - 2020-04-12 10:40 +0200
                Re: Salsa as authentication provider for Debian Enrico Zini <enrico@enricozini.org> - 2020-04-12 18:50 +0200
                  Re: Salsa as authentication provider for Debian Tollef Fog Heen <tfheen@err.no> - 2020-04-13 18:50 +0200
                    Re: Salsa as authentication provider for Debian Pirate Praveen <praveen@onenetbeyond.org> - 2020-04-13 19:50 +0200
    Re: Salsa as authentication provider for Debian Shengjing Zhu <zhsj@debian.org> - 2020-04-08 14:00 +0200
      Re: Salsa as authentication provider for Debian Shengjing Zhu <zhsj@debian.org> - 2020-04-08 14:20 +0200
        Re: Salsa as authentication provider for Debian Enrico Zini <enrico@enricozini.org> - 2020-04-08 15:00 +0200
      Re: Salsa as authentication provider for Debian Ulrike Uhlig <ulrike@debian.org> - 2020-04-08 14:20 +0200
        Re: Salsa as authentication provider for Debian Shengjing Zhu <zhsj@debian.org> - 2020-04-08 14:30 +0200
          Re: Salsa as authentication provider for Debian Enrico Zini <enrico@enricozini.org> - 2020-04-08 15:30 +0200
            Re: Salsa as authentication provider for Debian Sam Hartman <hartmans@debian.org> - 2020-04-08 16:10 +0200
              Re: Salsa as authentication provider for Debian Enrico Zini <enrico@enricozini.org> - 2020-04-08 16:30 +0200
            Re: Salsa as authentication provider for Debian Luca Filipozzi <lfilipoz@debian.org> - 2020-04-08 18:10 +0200
              Re: Salsa as authentication provider for Debian Enrico Zini <enrico@enricozini.org> - 2020-04-09 10:10 +0200
        Re: Salsa as authentication provider for Debian Ole Streicher <olebole@debian.org> - 2020-04-08 14:40 +0200
          Re: Salsa as authentication provider for Debian Enrico Zini <enrico@enricozini.org> - 2020-04-10 21:50 +0200
      Re: Salsa as authentication provider for Debian Enrico Zini <enrico@enricozini.org> - 2020-04-08 14:20 +0200
      Re: Salsa as authentication provider for Debian Bastian Blank <waldi@debian.org> - 2020-04-08 14:40 +0200
        Re: Salsa as authentication provider for Debian Shengjing Zhu <zhsj@debian.org> - 2020-04-08 14:50 +0200
          Re: Salsa as authentication provider for Debian Enrico Zini <enrico@enricozini.org> - 2020-04-08 15:00 +0200
            Re: Salsa as authentication provider for Debian Sam Hartman <hartmans@debian.org> - 2020-04-08 15:20 +0200
        Re: Salsa as authentication provider for Debian Julien Cristau <jcristau@debian.org> - 2020-04-10 21:50 +0200
          Re: Salsa as authentication provider for Debian Andrei POPESCU <andreimpopescu@gmail.com> - 2020-04-11 09:30 +0200
            Re: Salsa as authentication provider for Debian Julien Cristau <jcristau@debian.org> - 2020-04-11 19:30 +0200
              Re: Salsa as authentication provider for Debian Sam Hartman <hartmans@debian.org> - 2020-04-11 20:10 +0200
              Re: Salsa as authentication provider for Debian Andrei POPESCU <andreimpopescu@gmail.com> - 2020-04-12 07:30 +0200
                Re: Salsa as authentication provider for Debian Luca Filipozzi <lfilipoz@debian.org> - 2020-04-12 17:00 +0200
                  Re: Salsa as authentication provider for Debian Sam Hartman <hartmans@debian.org> - 2020-04-13 16:00 +0200
                    Re: Salsa as authentication provider for Debian Peter Palfrader <weasel@debian.org> - 2020-04-13 21:00 +0200
                      Re: Salsa as authentication provider for Debian Sam Hartman <hartmans@debian.org> - 2020-04-13 21:30 +0200

Page 4 of 5 — ← Prev page 1 2 3 [4] 5  Next page →

#11674

]] Sam Hartman 

> >>>>> "Tollef" == Tollef Fog Heen <tfheen@err.no> writes:
> 
>     Tollef> ]] Enrico Zini
>     >> For guest accounts opened by DSA directly, it can be pretty much
> 
> First, at this point in time I would be very skepticle of someone
> contributing to Debian enough to need porter box access but not having a
> salsa account.
> It's possible, but  that would be a yellow flag for me in evaluating
> such a request.

We quite regularly have upstreams getting access for weird architecture
failures.  There's no particular reason for those people to have salsa
accounts.

> However, as I read the guest account process, it has a number of manual
> steps where people are processing tickets.
> I suspect that DSA actually has a script or set of scripts that go
> create the guest account.

That varies.  It's LDAP, people sometimes use the ud-* suite of tools,
sometimes ldapvi.  Is salsa also going to check for debian.org accounts
when creating and renaming accounts on its side?

> Having these scripts check to see if the name is registered at salsa and
> requiring manual override to create an account if it conflicts with
> salsa and appears to belong to a different user is not, in my mind,
> making DSA's ldap subservient to the salsa LDAP.

(Salsa doesn't use LDAP, afaik)

It does to me, since suddenly we have to care about what's on salsa,
something we've never had to care about before.  It also breaks the
invariant people have been able to trust so far, that foo@salsa.d.o is
also foo@d.o (assuming both exist).  This will no longer hold true, and
I think we'll run into security problems down the line because of it.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

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

#11676

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

On Sat, Apr 11, 2020 at 09:47:39PM +0200, Tollef Fog Heen wrote:

> We quite regularly have upstreams getting access for weird architecture
> failures.  There's no particular reason for those people to have salsa
> accounts.

I understand those are temporary accounts. Do those cases need an
arbitrary name from the LDAP namespace?

Several places I worked with use a pool of time-limited accounts from a
guestNNN namespace, for example: that could address your use case
without overlapping with anything else.


> It does to me, since suddenly we have to care about what's on salsa,
> something we've never had to care about before.

As I said in 20200409181701.3qqsn5sqq3xbu2ia@enricozini.org, no, you
don't need to care about anything: you keep doing what you want, and we
deal with it.


So far, I only received requests to keep the status quo as it is
indefinitely, and very little in terms of counterprosals actionable now,
besides theoretical new software solutions to be explored, that would
address the problems I am having.

I want to be very clear on this: I have no intention of keeping the
status quo as it is now: either it becomes something that I can manage,
or I'll stop managing it.


Enrico

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

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

#11700

]] Enrico Zini 

> On Sat, Apr 11, 2020 at 09:47:39PM +0200, Tollef Fog Heen wrote:
> 
> > We quite regularly have upstreams getting access for weird architecture
> > failures.  There's no particular reason for those people to have salsa
> > accounts.
> 
> I understand those are temporary accounts. Do those cases need an
> arbitrary name from the LDAP namespace?
> 
> Several places I worked with use a pool of time-limited accounts from a
> guestNNN namespace, for example: that could address your use case
> without overlapping with anything else.

We have guest accounts that have been in use longer than the lifecycle
of some DD accounts, so while it would technically work, it wouldn't be
a particularly nice solution.  (You can of course say that requiring
non-DDs registering on salsa to have a -guest suffix isn't nice either,
something I can agree with.)

> > It does to me, since suddenly we have to care about what's on salsa,
> > something we've never had to care about before.
> 
> As I said in 20200409181701.3qqsn5sqq3xbu2ia@enricozini.org, no, you
> don't need to care about anything: you keep doing what you want, and we
> deal with it.

I think we in practice will want to do that in order to avoid triggering
bugs in software that assumes that user names are consistent.

> So far, I only received requests to keep the status quo as it is
> indefinitely, and very little in terms of counterprosals actionable now,
> besides theoretical new software solutions to be explored, that would
> address the problems I am having.

In case that was directed at me, rather than the wider world: I'm not
requesting you do one thing or another, I'm pointing out some possible
ramifications.

It's not clear to me why removing the -guest restriction has to happen
for sso.d.o to be using Salsa as an IdP, which seems to be your primary
goal?  That's my most immediate concern.  Switching to oauth2/OIDC seems
like a good idea, and assuming we can move to another broker somewhere
down the line, I have no problems with that happening.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

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

#11701

On Mon, Apr 13, 2020 at 6:39 pm, Tollef Fog Heen <tfheen@err.no> wrote:
> It's not clear to me why removing the -guest restriction has to happen
> for sso.d.o to be using Salsa as an IdP, which seems to be your 
> primary
> goal?  That's my most immediate concern.  Switching to oauth2/OIDC 
> seems
> like a good idea, and assuming we can move to another broker somewhere
> down the line, I have no problems with that happening.
> 

This was already answered here,

https://lists.debian.org/debian-project/2020/04/msg00031.html

On Wed, Apr 08, 2020 at 07:50:22PM +0800, Shengjing Zhu wrote:
 > 1. Can you still keep the "-guest" enforcement, so it's still easy to
 > recognize who is DD or not on salsa?

No.  The guest suffix was meant to avoid collisions with Debian
accounts.  And the tool used to enforce it is unmaintained.

Also the only place that can for sure answer if someone is DD is
nm.debian.org, not Salsa.

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

#11606

On Mon, Apr 6, 2020 at 11:58 PM Bastian Blank <waldi@debian.org> wrote:
[...]
> ## Highlevel plan
>
> - Salsa becomes primary source of user info and authentication for secondary
>   services via OpenID Connect (OAuth2), for both DDs and non-DDs, replacing
>   sso.debian.org.
> - Salsa allows user renames and drops namespace rules for users (i.e., no more
>   requirement for -guest suffix).
> - nm.debian.org uses Salsa usernames by default to populate LDAP usernames when
>   creating accounts, and stores OIDC subject to strongly correlate between
>   Salsa and Debian LDAP users.
>
> ## Fixed problems
>
> - We get a user source everyone can use both as service provider and user.
> - Users can rename themselves before becoming DDs, and retain all information
>   both on Salsa and on other services. This also works while transitioning
>   between non-DD and DD, and back.
>

1. Can you still keep the "-guest" enforcement, so it's still easy to
recognize who is DD or not on salsa?
2. For transition between non-DD and DD, could salsa admin rename the
username by requests?

For 1, I think it doesn't make the original plan more complicated.
For 2, I think it doesn't either, as you already plan to support renaming.

-- 
Shengjing Zhu

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

#11607

On Wed, Apr 8, 2020 at 7:50 PM Shengjing Zhu <zhsj@debian.org> wrote:
[...]
> 1. Can you still keep the "-guest" enforcement, so it's still easy to
> recognize who is DD or not on salsa?

The reason why I ask for this is because
1. If a -guest account is added to a project in salsa Debian group,
the group name is also shown on the personal profile.
2. Users can make their profile private, so you don't know what group
they belong to.
3. To search in the Debian group member page takes too many steps.

If there's an easy way I'm not aware of, then I'm fine with it.

-- 
Shengjing Zhu

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

#11615

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

On Wed, Apr 08, 2020 at 08:04:59PM +0800, Shengjing Zhu wrote:

> > 1. Can you still keep the "-guest" enforcement, so it's still easy to
> > recognize who is DD or not on salsa?
> 
> The reason why I ask for this is because
> 1. If a -guest account is added to a project in salsa Debian group,
> the group name is also shown on the personal profile.
> 2. Users can make their profile private, so you don't know what group
> they belong to.
> 3. To search in the Debian group member page takes too many steps.
> 
> If there's an easy way I'm not aware of, then I'm fine with it.

I checked with waldi, and with some extra work it is possible to add
some visible information to the user's page, synced from nm.debian.org,
about their official membership status.


Enrico

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

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

#11608

Hi!

On 08.04.20 13:50, Shengjing Zhu wrote:
> On Mon, Apr 6, 2020 at 11:58 PM Bastian Blank <waldi@debian.org> wrote:

> 1. Can you still keep the "-guest" enforcement, so it's still easy to
> recognize who is DD or not on salsa?

Could you explain a bit better why you think that this is needed?

I understand you want to recognize DDs from other contributors, but why?
Does it help you with permissions, does it help understand who someone
is, or is it a habit that has been there since Alioth?

ulrike

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

#11610

On Wed, Apr 8, 2020 at 8:13 PM Ulrike Uhlig <ulrike@debian.org> wrote:
>
> Hi!
>
> On 08.04.20 13:50, Shengjing Zhu wrote:
> > On Mon, Apr 6, 2020 at 11:58 PM Bastian Blank <waldi@debian.org> wrote:
>
> > 1. Can you still keep the "-guest" enforcement, so it's still easy to
> > recognize who is DD or not on salsa?
>
> Could you explain a bit better why you think that this is needed?
>
> I understand you want to recognize DDs from other contributors, but why?
> Does it help you with permissions, does it help understand who someone
> is, or is it a habit that has been there since Alioth?

For me, it's easier to trust a DD than a non-DD, so I'll grant a role
with higher permission if they request to join a team/project.

-- 
Shengjing Zhu

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

#11617

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

On Wed, Apr 08, 2020 at 08:25:06PM +0800, Shengjing Zhu wrote:

> > I understand you want to recognize DDs from other contributors, but why?
> > Does it help you with permissions, does it help understand who someone
> > is, or is it a habit that has been there since Alioth?
> 
> For me, it's easier to trust a DD than a non-DD, so I'll grant a role
> with higher permission if they request to join a team/project.

I think this has ups and downs.

Currently, if someone doesn't have -guest on Salsa, they are either
active DDs or locked accounts. The moment a non-"-guest" person loses
their DD status, their account gets locked.

This is currently causing trouble: when one loses DD status, suddenly
they lose access to all their repositories until they get readded to
everything with a new -guest account. For repositories that only they
controlled, this requires admin intervention and headaches.

This has happened, and it's serious enough to make Salsa not suitable
for hosting long-term projects at the moment: I don't want to build my
projects' ecosystem on something which locks me out the moment I decide
to go emeritus, or the moment I get my Debian membership temporarily
suspended for whatever reason.

I would argue that it would make more sense to grant roles and
permissions to people based on their past contributions and reputation,
rather than based on current status.

I agree that with the current proposal, the use case of "grant a person
permission based on their status, which is somehow revoked or blocked if
the status goes away" becomes something we might not be able to do.

In my opinion this change, rather than opening a new problem, fixes an
old, nasty one instead.


Enrico

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

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

#11618

>>>>> "Enrico" == Enrico Zini <enrico@enricozini.org> writes:


    Enrico> I agree that with the current proposal, the use case of
    Enrico> "grant a person permission based on their status, which is
    Enrico> somehow revoked or blocked if the status goes away" becomes
    Enrico> something we might not be able to do.

Fair enough.  But there is the use case of sanity check that foo is a dd
before granting them permissions today because I'm going to think about
it a lot more if they aren't a dd  is a valid use case.

Also, I do think there are some repos that we really only want a dd
writing to.  As an example, keyring-maint.  Now if something goes bad
for keyring maint we're going to notice it, and keyring maint would
certainly be in the loop if someone from keyring-maint retired.

I don't think it blocks your proposal, but I do think that having
something to audit repos and make sure only current dds have access to
certain repos is a valuable user no]eed.
And I think the current-status-permission check need is also valid and
probably more critical.

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

#11619

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

On Wed, Apr 08, 2020 at 10:05:19AM -0400, Sam Hartman wrote:

> I don't think it blocks your proposal, but I do think that having
> something to audit repos and make sure only current dds have access to
> certain repos is a valuable user no]eed.
> And I think the current-status-permission check need is also valid and
> probably more critical.

Sure. I seriously think we don't have enough audit tools in Debian, and
I'm strongly in favour of having more.

With regards of current-status-permission, I checked with waldi, and
with some extra work it is possible to add some visible information to
the user's page, synced from nm.debian.org, about their official
membership status: we can totally have that.


Enrico

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

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

#11627

On Wed, Apr 08, 2020 at 03:18:39PM +0200, Enrico Zini wrote:
> On Wed, Apr 08, 2020 at 08:25:06PM +0800, Shengjing Zhu wrote:
> 
> > > I understand you want to recognize DDs from other contributors, but why?
> > > Does it help you with permissions, does it help understand who someone
> > > is, or is it a habit that has been there since Alioth?
> > 
> > For me, it's easier to trust a DD than a non-DD, so I'll grant a role
> > with higher permission if they request to join a team/project.
> 
> I think this has ups and downs.

Another view point: I don't think that one's username should change as
one's role(s) with the organization changes. If we could avoid that...

-- 
Luca Filipozzi

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

#11633

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

On Wed, Apr 08, 2020 at 04:06:25PM +0000, Luca Filipozzi wrote:

> Another view point: I don't think that one's username should change as
> one's role(s) with the organization changes. If we could avoid that...

Agreed!


Enrico

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

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

#11611

Ulrike Uhlig <ulrike@debian.org> writes:
> On 08.04.20 13:50, Shengjing Zhu wrote:
>> On Mon, Apr 6, 2020 at 11:58 PM Bastian Blank <waldi@debian.org> wrote:
>
>> 1. Can you still keep the "-guest" enforcement, so it's still easy to
>> recognize who is DD or not on salsa?
>
> Could you explain a bit better why you think that this is needed?
>
> I understand you want to recognize DDs from other contributors, but why?
> Does it help you with permissions, does it help understand who someone
> is, or is it a habit that has been there since Alioth?

I don't know the exact proposed rules here, but I could imagine that
without these rules anyone cann fill the namespace of nice Debian user
names. And there is the danger that someone hijacks the user name of a
Debian user who is still not on Salsa. Or an emeritus name or so.

I would also like to have a visible distinction between "trusted" names
(where the owner is verified via key) and random names, in one way or
the other.

Cheers

Ole

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

#11658

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

On Wed, Apr 08, 2020 at 02:23:47PM +0200, Ole Streicher wrote:

> I don't know the exact proposed rules here, but I could imagine that
> without these rules anyone cann fill the namespace of nice Debian user
> names.

If you're talking spam account flooding the namespaces, they can be
cleaned up from time to time.

If you're talking about legitimate Debian contributors not yet
interested in becoming DDs, using up names that people interested now in
becoming DDs would like to have, I think it's not a problem if the
people who registered the name first gets to keep it.


> And there is the danger that someone hijacks the user name of a
> Debian user who is still not on Salsa. Or an emeritus name or so.

The proposed workflow is that:

 - you register a name on Salsa
 - after you go through nm.d.o, it becomes your name on LDAP

By default, when you become a DD you have the same username on Salsa,
and so it's taken by you and nobody can register it, even if you become
emeritus.

If you decide to rename your Salsa account, then yes somebody else can
take it, and it's fair enough. If somebody takes it over maliciously,
the account can be locked.

If you decide to rename your account but don't want somebody else to
register your old name, you can register it yourself after the rename,
to keep control of it.


> I would also like to have a visible distinction between "trusted" names
> (where the owner is verified via key) and random names, in one way or
> the other.

The official membership status synced from nm.debian.org can, with some
work, be made visible in the user's page.


Enrico

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

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

#11609

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

On Wed, Apr 08, 2020 at 07:50:22PM +0800, Shengjing Zhu wrote:

> 1. Can you still keep the "-guest" enforcement, so it's still easy to
> recognize who is DD or not on salsa?

I'll leave answering these questions to Waldi / Salsa admins.

I would like to stick to investing energy in solving problems that we
really have, though, so I'm curious: do you have specific reasons in
mind for asking to preserve the "-guest" enforcement on Salsa?


Enrico

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

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

#11612

Hi Zhu

On Wed, Apr 08, 2020 at 07:50:22PM +0800, Shengjing Zhu wrote:
> 1. Can you still keep the "-guest" enforcement, so it's still easy to
> recognize who is DD or not on salsa?

No.  The guest suffix was meant to avoid collisions with Debian
accounts.  And the tool used to enforce it is unmaintained.

Also the only place that can for sure answer if someone is DD is
nm.debian.org, not Salsa.

> 2. For transition between non-DD and DD, could salsa admin rename the
> username by requests?

No.

Bastian

-- 
I'm a soldier, not a diplomat.  I can only tell the truth.
		-- Kirk, "Errand of Mercy", stardate 3198.9

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

#11613

On Wed, Apr 8, 2020 at 8:33 PM Bastian Blank <waldi@debian.org> wrote:
>
> Hi Zhu
>
> On Wed, Apr 08, 2020 at 07:50:22PM +0800, Shengjing Zhu wrote:
> > 1. Can you still keep the "-guest" enforcement, so it's still easy to
> > recognize who is DD or not on salsa?
>
> No.  The guest suffix was meant to avoid collisions with Debian
> accounts.  And the tool used to enforce it is unmaintained.
>
> Also the only place that can for sure answer if someone is DD is
> nm.debian.org, not Salsa.
>

Sigh, but it makes sense too. Will nm.d.o have a field which reflects
the username on salsa?
Although it takes multi steps to figure out the user status when you
click a "Request to join" link sent by salsa.

--
Shengjing Zhu

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

#11614

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

On Wed, Apr 08, 2020 at 08:45:32PM +0800, Shengjing Zhu wrote:

> Sigh, but it makes sense too. Will nm.d.o have a field which reflects
> the username on salsa?

It finally will, yes! \o/

It's been quite painful not having that mapping so far.


Enrico

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

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

Page 4 of 5 — ← Prev page 1 2 3 [4] 5  Next page →

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

csiph-web