[35275] trunk/dports

[James Berry]

Hi Thomas,

On Mar 23, 2008, at 8:58 PM, Adam Mercer wrote:

> On Sun, Mar 23, 2008 at 10:05 PM, Thomas Reifferscheid
> <reiffert at macports.org> wrote:
>> Dear James, I dont feel well with your changes. It will make life  
>> even
>> harder for submitters to the ticket database choosing the right  
>> maintainer.
>
> Why? MacPorts understands this obfuscation, it will expand to the
> appropriate address. For example, running 'port info' for these ports
> will return the correct email address: 'user' will be expanded to
> user at macports.org and 'example.com:user' will be expanded to
> user at example.com
>
> I use this on all my ports, along with many other maintainers.

Yes, as Adam says, this is our standard and supported behavior, and is  
used for many ports. I'm not sure it's documented anywhere however,  
but Adam's explanation is correct; we support two forms of  
obfuscation, a specific one for the macports.org case, and a more  
general variety for any email address. The rationale is to cut down on  
the possibility of spam to committers, though this is only one leak of  
email addresses, and there are others that remain unfixed (bug  
reports, irc logs, etc).

Implemented by the following code in port.tcl:

proc unobscure_maintainers { list } {
    set result {}
    foreach m $list {
        if {[string first "@" $m] < 0} {
            if {[string first ":" $m] >= 0} {
                set m [regsub -- "(.*):(.*)" $m "\\2@\\1"]
            } else {
                set m "$m at macports.org"
            }
        }
        lappend result $m
    }
    return $result
}

James
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2740 bytes
Desc: not available
Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080324/a39b67db/attachment-0001.bin