email not obfuscated in ticket's action fieldset

[Daniel Musketa <daniel@…>]

In the action fieldset the plain email address of the current ticket owner is shown.

Aktion

leave als new

resolve als fixedinvalidwontfixduplicateworksformecantfix Der Status der Lösung wird gesetzt. Der nächste Status wird 'closed' sein

reassign zu Felix Schwarz <felix.schwarz@example.com> wird von der Verantwortlichkeit für das Ticket befreit. Der nächste Status wird 'new' sein

accept Die Verantwortlichkeit für das Ticket wird von Felix Schwarz <felix.schwarz@example.com> an anonymous übertragen. Der nächste Status wird 'assigned' sein

[Remy Blank]

Good catch!

[Christian Boos]

Mh, I'd say it's a 0.12 blocker, no? We should guarantee #153.

[Remy Blank]

Ok, I didn't want to push too much, but since you agree…

[Remy Blank]

Fixed in [9667]. The change obfuscates a bit more than strictly necessary, as it obfuscates visible e-mail addresses in the user <select> when [ticket] restrict_owner = true, even though the complete e-mail address is still (must be) present in the value attribute of the <option>.

[osimons]

Replying to rblank:

Fixed in [9667]. The change obfuscates a bit more than strictly necessary, as it obfuscates visible e-mail addresses in the user <select> when [ticket] restrict_owner = true, even though the complete e-mail address is still (must be) present in the value attribute of the <option>.

Just noticed this one. I think the visual hiding is a bad idea, and gives the users and administrators the impression that things are OK. If the email is part of the HTML we output, there is no point in obfuscating it in some places. Any email-grabbing script will snag it.

Better to be show things as they actually are so that admins can take some measure against it. I suggest this gets reverted.

[Remy Blank]

Replying to osimons:

Better to be show things as they actually are so that admins can take some measure against it.

Any idea what those measures could be (except setting restrict_owner = false)?

I'd rather fix this completely, then. When restrict_owner = true, we could set the <option> values to a hash of the e-mail address. On submit, as we have the complete list of addresses, we can get the address corresponding to the hash, something a bot can't do.

[osimons]

Replying to rblank:

Any idea what those measures could be (except setting restrict_owner = false)?

That has been the recommended approach so far. Or that the admins switch to some user scheme that don't include email addresses.

The hash idea would work in theory. It would be quite expensive to check and hash all options and change it back though, and can't really say if it will be worth it?

[Remy Blank]

We could also use a simpler "bot-resistant" obfuscation, like using HTML entities, or rot-13, or writing the e-mail addresses backward. It doesn't have to be cryptographically strong (though the hash would be, with some salt), it should just prevent bots from finding the e-mail addresses.

[osimons]

Well, if it looks like an email it will likely be harvested (or rather highly likely). Rot13 is a good idea, but recommended by others that we just tweak it slightly:

>>> 'test@example.org'.encode('rot13').replace('@', '+')
'grfg+rknzcyr.bet'

That said, this fix will work for one field. In Ticket, and also Query (but haven't looked there for this in quite a while). Are there any side-effects for request filters, stream filters or site.html rendering tweaks that no longer get the actual data?

[osimons]

Actually, such a conversion will soon become muddy. The '+' is allowed in the local part but not domain, so converting things back should be easy in theory (may contain more than one '+' but last is always '@'). Anyway, that is fine until you start seeing the input we actually get from users… And consider that it may be shortnames in use - or not. Like 'trac+john.doe' vs 'trac+john.doe@example.org' that both are valid inputs?

Can it work confidently within a reasonable amount of code?

[Remy Blank]

Rot-13 or writing backards were only meant to be examples. What we need is a reversible encoding that makes e-mail addresses look like garbage. We could just hex-encode every character as 4 hex digits. The values are not visible to the user anyway, and only contained in the value= attribute of <option> tags.

[osimons]

Replying to rblank:

Rot-13 or writing backards were only meant to be examples. What we need is a reversible encoding that makes e-mail addresses look like garbage. We could just hex-encode every character as 4 hex digits. The values are not visible to the user anyway, and only contained in the value= attribute of <option> tags.

Yes - I just elaborated on Rot13 as a good idea in a comment above, and then shot that down again as that widely recommended approach only works when the field is known to contain full emails (which ours won't).

Some regular encoding strategy then seems most useful - based on hex, base64, bin or anything. Perhaps with some simple padding.

[Remy Blank]

Let's do that in 0.12.2.

[Christian Boos]

I fear this approach is too complex for what it's worth… Saving a few e-mails from being grabbed? If those are for prominent contributors to the project, chances are that those e-mails are already visible in clear text somewhere else (in the source code, in the project meta-data, in the Team page, etc.). If those should nevertheless remain protected, then well, perhaps better make clear that restrict_owner is not the way to go in this case. So I would suggest not reverting r9667 in whole, but just its last chunk (have tag.option(x, value=x, back) and add a note to the restrict_owner configuration setting doc.

[OT] One day, we should really write down a list of all the various annoying issues we got thanks to the restrict_owner feature, from massive slow downs to special cases here and there … Externalize as a plugin? ;-)

[Remy Blank]

Last hunk of [9667] reverted in [10396], and added a comment to the documentation of [ticket] restrict_owner. Closing again against 0.12 for the initial issue.

[osimons]

Nice, that will do for now. Thanks!

[Ryan J Ollos]

comment:2:ticket:11474 describes a proposed refinement to [9667].