cvs commit: www/en/cgi Makefile query-pr.cgi querypr-code.cgi

[John Baldwin]

On Saturday 12 November 2005 04:03 pm, Alexander Leidinger wrote:
> On Sat, 12 Nov 2005 10:35:29 -0700 (MST)
>
> "M. Warner Losh" <imp at bsdimp.com> wrote:
> > I've had a couple of private suggestions sent to me.
> >
> > The first is to create a raw-query-pr.cgi that will just serve up one
> > PR in raw format with no links to this page.
> >
> > The second is to add another parameter to query-pr that changes
> > quarterly.  pass=bluestarts this quarter, pass=yellowdiamons next, etc
> > (well, we wouldn't use the ingrediants to lucky charms as a
> > password).  This level of security is the same that exist on certain
> > invitation only IRC channels that are out there.  Someone has to tell
> > you the password, and the password changes from time to time.  Since
> > developer mail is project confidencial, I would guess it would be
> > sufficient to email the new password once a quarter.
> >
> > The ugly alternative is to have a 'members only' section of the
> > website where you have to login.  In that section, we could also give
> > the full names.  However, this suffers from the inability to easily
> > use with 'fetch'.
> >
> > The forth alternative is those goofy 'tell me what's in this box'
> > schemes.  Prove you are a human.  This sounds more burdonsome than
> > logging into freefall to do the query-pr, which is Kris' main
> > objection to the new change.
>
> Those, and specially the one we use, are too easy to circumvent. There's
> somewhere a page (maybe available on the links section on my homepage
> or still as a "add me to the links section"-mail somewhere in my
> inbox...) which dissects a lot of those schemes and also provides code
> how to circumvent them.
>
> With the current scheme in place we also can just render the email
> address as a picture. It provides the same protection and also has the
> same drawbacks for a committer.
>
> A better alternative would be to obfuscate the address, e.g. replacing
> the "@" with an "at" or with a space or an ampersand or a percent sign
> or whatever (even randomizing the replacement would be possible). And
> replacing dots with something else.
>
> This would result in at least the same computational complexity for
> address-harvesters and it would allow to just cut and paste the
> addresses. It gives the additional benefit that sites such as
> freshports (or our/foreign mail archives) provide the same obfuscation
> without any further work.

Hmm, I might like this the best.  Something I've noticed, too, btw, is that 
there is still a 'submit followup' link on the same page that has the 
submitter's e-mail address in the mailto: (so it's even easier for a spider 
to find) so unfortunately I think the current change doesn't actually help 
the current page contents at all.  I actually received the original complaint 
e-mail and had forwarded it to core@ to ask if the person's request was even 
reasonable, etc. on a Friday and came back in to find the changes were done 
over the weekend. :)   On the face the request that we not publish people's 
e-mail addresses may seem reasonable, but I think in practice it is not 
something we can realistically do.  At this point I'm all for just saying, 
"Sorry, once you've sent in a PR your e-mail address is likely to be 
harvested for spam and unfortunately we can't really plug all the leaks and 
still get anything useful done."  I do like Alexander's suggestion above as 
it would automate the task of obfuscating the e-mail address when cutting and 
pasting into a commit log.  If it included some randomization it would also 
make it slightly more "secure" (that's not the right word really) than the 
simplistic scheme that I always follow (s/@/ at /, s/\./ dot /g)

-- 
John Baldwin <jhb at FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve"  =  http://www.FreeBSD.org