Two GCC stories

Posted Jul 4, 2010 21:23 UTC (Sun) by fuhchee (guest, #40059)
In reply to: Two GCC stories by nix
Parent article: Two GCC stories

"If NightStrike was asked for this sort of thing, he never mentioned it"

I assume you are solely referring to "real-world contact information" issue.

As far as I know, no one asked this person his/her phone number, address, bank account numbers, date of birth, schooling & employment history, if that's what you mean. Since he was unwilling to disclose even his real name, do you believe that such a questionnaire would have been anything but a waste of time?

to post comments

Two GCC stories

Posted Jul 4, 2010 21:39 UTC (Sun) by sfeam (subscriber, #2841) [Link] (6 responses)

I am appalled that a project would require any of those as a prerequisite for accepting a contibution of patches or new code.

Two GCC stories

Posted Jul 4, 2010 23:10 UTC (Sun) by fuhchee (guest, #40059) [Link] (5 responses)

"I am appalled that a project would require any of those as a prerequisite for accepting a contibution of patches or new code."

Lucky thing then that GCC does not.

My purpose in listing those things is to figure out what nix thinks what if anything we might have asked "NightStrike" as a substitute for his real name to ascertain his identity. Recall too that this whole kerfuffle was not about contributing some random gcc patch, but about getting some semi-administrative access to the project hosting server.

Two GCC stories

Posted Jul 7, 2010 16:05 UTC (Wed) by nix (subscriber, #2304) [Link] (4 responses)

I agree that you need more info than that. I'm just reasonably certain that rejecting a name on the basis that it doesn't sound real enough and then not asking for a more extensive authenticator is not an effective security policy: it'll only keep out those who are honourable enough to not use a real-sounding pseudonym, i.e. those who are not bad guys. I'm not saying 'oooh, you should have let NightStrike in with no authentication at all', I'm saying 'hang on, who the hell else have you let in if a real-sounding name is all you need'? If that's all you need, you have survived without major attacks by virtue of chance and obscurity, nothing more.

(As an aside, I know NightStrike was unwilling to disclose his real name to the entire publically-archived GCC list, but I know the GNU Project has non-public backchannels over which this sort of info can pass. If NightStrike was unwilling to provide better authenticators that way as well, then I don't see how you can possibly let him onto gcc.gnu.org; but if he was never asked, then it looks to me like you threw away a contributor unnecessarily.)

Two GCC stories

Posted Jul 7, 2010 16:14 UTC (Wed) by fuhchee (guest, #40059) [Link] (3 responses)

"I'm just reasonably certain that rejecting a name on the basis that it doesn't sound real enough"

This person admitted the obvious that "NightStrike" is not real. AFAIK only he and his sympathisers suggested in later editorial comments that a "real-enough" but fake name might have been acceptable.

"and then not asking for a more extensive authenticator"

Please advise what forms this "more extensive authenticator" might have taken.

"is not an effective security policy"

Rejecting questionable requests for pseudo-admin access is a fine security policy.

Two GCC stories

Posted Jul 7, 2010 18:24 UTC (Wed) by nix (subscriber, #2304) [Link] (2 responses)

This person admitted the obvious that "NightStrike" is not real. AFAIK only he and his sympathisers suggested in later editorial comments that a "real-enough" but fake name might have been acceptable.

But how would you have known if it wasn't? Ignoring someone who points out a huge gaping flaw in your security policy because you don't like their name is not clever.

As for better authenticators, well, you've already mentioned things like home addresses, phone numbers, et seq. Of course all of these are fakeable: one must estimate the determination of possible attackers when figuring out which to rely on. But NightStrike is quite right that relying on 'a real-sounding name' gives you nothing: it drives away those who wish to or must use pseudonyms while failing to keep out any bad guys at all.

Two GCC stories

Posted Jul 7, 2010 18:47 UTC (Wed) by fuhchee (guest, #40059) [Link] (1 responses)

"But how would you have known if it wasn't?"

So let me get this straight. *Because* we refuse to give someone
logon privileges (for reasons that even you are sympathetic to), you
complain about a hypothetical opposite situation where we might
someday give access to someone else? So actual evidence of our
prudence is twisted to insult to our hypothetical straw-man
security policy?

Dude. Really.

I am not prepared to disclose a full investigative plan to be applied
to an arbitrary person seeking such access. "It depends." But I am
prepared to promise this: being "merely real-sounding" has not and
will not be sufficient.

Two GCC stories

Posted Jul 7, 2010 21:20 UTC (Wed) by nix (subscriber, #2304) [Link]

Right, good. That was all I was concerned about.

Two GCC stories

Posted Jul 7, 2010 16:00 UTC (Wed) by nix (subscriber, #2304) [Link] (1 responses)

So, let's see. You said

It is not correct that "he was never asked to provide any real-world contact information".

And now you're saying

I assume you are solely referring to "real-world contact information" issue.
As far as I know, no one asked this person his/her phone number, address, bank account numbers, date of birth, schooling & employment history, if that's what you mean. Since he was unwilling to disclose even his real name, do you believe that such a questionnaire would have been anything but a waste of time?

I think that's one contradiction there, so I am forced to conclude that the root of your security policy is in fact "does this person's name sound real". As I said above, this is... weak.

Two GCC stories

Posted Jul 7, 2010 16:04 UTC (Wed) by fuhchee (guest, #40059) [Link]

"I think that's one contradiction there"

Not at all. He (?) was asked for his real name. That is a part -- really, the very first & most basic part -- of one's "real-world contact information".