Re: [nm-admin] Identification step in the current scheme (Re: Fear the new maintainer process)
On Thu, 3 Aug 2000, Anand Kumria wrote:
> On Wed, Aug 02, 2000 at 07:35:40PM +0000, Dale Scheetz wrote:
> > On Wed, 2 Aug 2000, Matthew Vernon wrote:
> > > Dale Scheetz writes:
> > >
> > > > It comes down to: Can you do "normal" things that may be required by the
> > > > task at hand? Scanning a passport seems to be a reasonable skill to
> > > > require of incoming members. Isn't it?
> > >
> > > No. Why should being a debian developer require you to be able to get
> > > hold of a scanner?
> > Why should we require them to have access to a computer?
> > We don't require this. We do require them to be "competent" enough to be
> > able to crate an image file from a document. Consider this a technical
> > performance test. "Can the applicant provide a specific document in
> > digital format, properly signed?"
> This requirement that they provide an image is only for the new-maintainer
> process. Debian, as a project, requires people to be competent enough to
> sign things (generally packages).
I agree, so what?
> > This just doesn't seem to be the onerous task that several have made it
> > out to be. It's just another requirement for becoming a member. Why not
> Why do you continue to confuse the issue by bringing in the onerous task
> furphy? It is all about trust.
Well, I agree that I trust a keysigner, and that trust allows me to accept
the signed image from the applicant. But it is also about capabilities,
our capability to identify our members.
I just can't understand the reluctance to satisfy this requirement except
that it is viewed by some as being too hard. I cannot, for the life of me,
figure out what harm there might be to the passport holder if I happen to
have a digitized copy of his passport. Can someone explain to me just why
the passport holder should feel threatened by the existance of an
"uncontroled" copy of his passport?
> To wit:
> Applicant A Applicant B
> - has public key - has public key, signed by Wichert*
> - has image signed by - has no image file
> own public key
> The current procedure says that Applicant A has fullfilled the identity
> requirements. Applicant B has not.
Applicant A has NOT fulfilled the identity requirements!!!!
Applicant A must, in addition to the above, provide a real, live, contact
who can verify the picture against the name.
We don't require this for applicant B, as the keysigning supplies the
real, live, contact and the act of signing the key is a verification that
the viewed person is also the named person.
The image file satisfied our need as a group to be able to identify our
Yes, I would like to see every member have a photo on record, but I'm only
working on new maintainers. I already have over 100 applicants to deal
with and I'm not sure I could deal with an additional 400, which is what
would happen if we require all current maintainers to go through the
The idea that we should not require anything in the future that hasn't
been required in the past declares that no progress can be made without
starting over from scratch. Maybe we have reached this point. I hope not.
> [*] I use Wichert as an example because there are (at least) two applicants
> in the queue for fit this criteria. But the public key could be signed
> by any existing Debian developer.
Wichert is an exceptionally poor example, as he is both the AM and the
keysigner (not something that happens very often), _and_ he is in physical
contact with the applicant during the application process. These are
extremely nice circumstances, but they aren't typical, and we shouldn't
decide policy based on special cases.
> 1. the new-maintainer process does not trust existing developers;
> having your key signed by an existing developer counts for nothing
You continue to pound this false drum, and I for one am tired of hearing
Having your key signed by a developer allows us to accept your photo image
without recourse to a personal contact for verification, as is the case
with the unsigned key.
We don't even need to bother the developer who signed the key with pesky
questions about whether or not he remembers this person, principly because
we trust that the keysigning was correctly done
> 2. applicants should not bother to get an existing maintainer to
> sign their key -- there is no benefit for the purposes of the
> new-maintainer process
> 3. the debian `web of trust' breaks down (further) into a large set
> of self-signed individuals but no path to or from large numbers of keys
Have no idea what you just said, but I think it is FUD as well.
> That applicants who fit into the case of Applicant B be deemed to have
> completed the identification process.
> End result:
> 1. (somewhat) Speedier processing for those applicants are able to
> convince existing Debian Developers to sign their key.
We already have that, as they don't need to provide a phone contact for ID
> 2. More pressure on applicants to search out Debian developers in their
> area and get to know them. Nothing beats knowing someone IRL.
> 3. More trusted pathways between developers, a stronger web of trust for
> > just obliterate all the requirements, and make signing up sufficient to
> > membership? We did that at one time, why not now?
> You know I know. But I bet large numbers of people don't. Would you like
> to prepare a history of Debian's new-maintainer system and the
> various requirements, when they were introduced and why that was done?
See the original proposal, and the ensuing discussions on nm-admin.
> > If you can't answer the above questions, you simply haven't been paying
> > attention to the particulars of the problem posed by new maintainers.
> > We wish to restrict membership to those people who are open and capable of
> > cooperating in a joint project like Debian. Try looking at this from
> > Debian's point of view instead of the poor abused applicant.
> I have been. It is in the projects interest and in the interest of applicants
> to make this change.
I'm not convinced. Your premise is flawed.
> For whatever reason, no matter what language I use, you don't seem to grasp
> how fundamentally important it is that we trust our existing developers.
It is quite clear to me that you don't understand the my position. It is
also quite clear that I am not capable of clearly explaining it to you.
>From my point of view the reason I am failing is that you refuse to let go
of what I see as a flawed point of view.
You continue to insist that I (the process here crafted) don't trust
current developers. I insist that this is not at all the case and that it
is my trust that allows me to accept the other components of the ID.
I don't know any way to make myself understood above what I've already
_-_-_-_-_- Author of "The Debian Linux User's Guide" _-_-_-_-_-_-
aka Dale Scheetz Phone: 1 (850) 656-9769
Flexible Software 11000 McCrackin Road
e-mail: firstname.lastname@example.org Tallahassee, FL 32308
_-_-_-_-_-_- See www.linuxpress.com for more details _-_-_-_-_-_-_-