Change History (104)

I started on a solution and ran in to problems with the cc field. These arose because I was trying to support multiple entries; if the intention of cc was to contain only a single user, or if that would be a reasonable restriction to impose, I can make my solution work.

Otherwise, as cc is open for editing, populating it with a value other than that in the database will cause an erroneous change unless save_changes filters for these values. But that's problematic: how do you match the altered version with the saved version? Since the altered versions may be ambiguous (abc@… and abc@… both map to abc@…, for instance), it seems a different solution is needed.

Making cc read- or add-only for non-authenticated users would clear this up. Any other ideas?

Of course other, more efficient techniques are needed to fight against spam, but meanwhile we should not make it too easy for those address grabbers. Even the simplest mangling, e.g. replacing all non alphanumeric characters in an address (like '@' and '.') with human-readable equivalents (like 'at' and 'dot') will help. On-the-fly rendering it with a funny font into to an image is a possibility, too.

The mangling should be made in such a way that it is unambigous for a human reader.

I'd warn against using "at" or "dot" — the spam harvesters are surely smart enough to pick that up now. My personal preference lately is to replace @ with (a) and . with * or (o). Image-based is of course the best way to hide the address from spammers, but does cause trouble for people who like to copy/paste the address.

I also don't like the idea of cutting the email address. I dislike the tools/newsgroup/list archives doing this. It's really difficult if you can't read the full email address and want to contact the person.

I also don't like the idea of cutting the email address. I dislike the tools/newsgroup/list archives doing this. It's really difficult if you can't read the full email address and want to contact the person.

As the original author implied, there are a number of browsing modes, and an ideal implementation would allow a per-installation configuration of which mode is used:

Emails obfuscated, except for people with permission to view them (developers), who see the emails fully expanded.

Emails obfuscated, except for people who are logged in.

Emails are not obfuscated

Personally, I refuse to give my email address to web sites that don't obfuscate email addresses, which means that it's going to be even more difficult for you to contact me than if my email were obfuscated :-)

So, what about solving of this SPAM problem? If mangling is too complicated or more time is needed to choose proper solution for mangling, maybe it could be solved simpler. I.e. for me it could be enough to get new configuration option. If this option is set to true only usernames are shown for not authenticated users, but emails hidden. If it is set to false, everything works as it works now.

I have not looked into the trac source code at all, but I'm guessing that the final rendering of the e-mail address in can't be too hard…?

Per the point above that abbreviated addresses are annoying to random 3rd parties, consider the poster's bias: if the developers want feedback, they will provide a mechanism to get it. For example, they can allow anonymous posts to the ticket (which may result in mailing the poster anyway), or provide an alternate mechanism such as a support mailing list. My point: direct e-mail is one option for contacting someone; it may not be the only option (and depending on that someone, direct e-mail may not be the preferred method of contact). If Trac gets this feature, it gives the owners of the system the flexibilty to decide which model they want to use.

I too, try very hard not to give my e-mail address to web sites that publish it (which is why I didn't include my address on this report :-( ). We just started using Trac for our open source project (​http://www.open-mpi.org/) and just discovered that it's showing all the CC addresses to the world. Big bummer.

One difficulty I see in solving this is how to handle the cc list. Currently, everyone just appends their email onto the list when they want to be cc'ed on a ticket. If mangling or obfuscating the list, what is shown in the Cc change ticket properties field? If the addresses are all mangled and I add mine, it will look very inconsistent, so I might be tempted to add "me (at) this (dot) com" instead of a valid address just to conform with the other addresses listed.

Another option is to hide the cc contents and the cc field then becomes a "add only" type of field. But then you have the problem that you cannot remove yourself from the list if you want to.

#1459 addresses a way to redesign the cc field that should address my concerns. The only email address that is editable will be your own. If that is the case, then it seems that this only becomes a problem of presentation of email addresses..

From TracNotification: always_notify_updater: (since 0.10) Always send a notification to the updater of a ticket.

Got mails for all today's updates of this ticket, too. So maybe the description of always_notify_updater should read: "… to the updaters of a ticket", meaning that everyone who updated a ticket once will get mails from that moment on?

Now, I wanted to reopen my ticket, but more people are listening here. This is not about obfuscating emails. This is about not exposing them, at all.

If you expose emails in RSS feeds why do you hide them on normal HTML pages? I'm not talking about the Cc field, but the author.

Why do you want to expose email addresses, at all? Why do you not create wiki pages where you list emails for those who want it? You're making it far too easy for spammers and I'm sure that most Trac users don't even know that their email is accessible so easily via the RSS feed (and some will wonder why they get more spam…).

I think that it's absolutely not necessary to make the email visible (even obfuscated). If someone wants to talk about a ticket then he should add a comment. If someone wants to contact the developers then he should use IRC or the mailing list. That way, he reaches all developers instead of only one of them.

Ideally, with #2456 you could click on the username to get to the user's details page where you can send him a message (possibly secured with a captcha). That would provide what you need in IMHO *rare* cases.

think that it's absolutely not necessary to make the email visible (even obfuscated).

there are several public RSS feeds that contain real email address.

Why do you want to expose email addresses, at all?

Trac is also used in private networks where hidding email address would be non sense. Any Trac installation which serves a company's intranet for example.

These are at least two reasons why obfuscating/truncating/hiding/… altering in any kind email addresses is not an acceptable option.

Trac does need a way to hide email addresses for sure. The way the email address is not made public does not really matter. Obfuscating, truncating, hiding, not resolving the login into the email address, … are several ways to achieve the same goal, IMHO

Email addresses could be hidden for ticket and/or for RSS feeds, that why I closed your initial ticket as a duplicate of #153, but if you think there are not related, feel free to re-open the original ticket.

A note about spam: as long as mailing lists, and mailing list archives exist, hidding email address from the RSS feed won't save you from being spammed - at least with on t.e.o. ;-) This does not invalidate the need for hiding email addresses, of course.

About the patch: please pay attention to the users = [''] # for clearing assignment line that you removed. I'm quite sure it was there for a reason. Well, only testing could tell ;)

I enabled restrict_users and noticed that there were two empty entries. As you can see, field['optional'] = True, so this one will already add an empty entry.

Also, you added <dc:creator> elements, I'm not sure whether that shouldn't rather be filled with the ticket reporter rather than the ticket updater (i.e. the resource creator vs. the resource editor).

The comment and the changes are all created by the ticket updater, so IMHO it should be like that.

Finally, you could take the opportunity of this patch to move the email map stuff in trac.util, while waiting for a better place (part of your suggested user refactorings?)

Like eblot said, I plan to do this differently with the IUserStore interface. If you have a lot of users (e.g.: every user has to register) you'll get too many unnecessary DB lookups because you must retrieve the email address for each user (instead of each ticket change).

What was the rationale for doing that only at the RSS level, again?
Maybe the approach could be extended to the .html templates as well.

The email was only exposed at the RSS level which I found very strange. I wanted to fix that. Could you please commit my patch. I want to continue my work on IUserStore. The more I work on other patches the more work I'll have with adjusting the IUserStore patch.

OK. This is a good step on the road then. I would suggest that this ticket shouldn't be closed until a patch is committed that addresses changelogs and wiki pages as well. Especially since some VCS (such as darcs) use an email address for the patch author.

It should be very easy to obfuscate the commit author. But is it really worth to obfuscate the commit message and wiki page contents? The developers could take care of this. I think that there are cases where content obfuscation is harmful (esp. on wiki pages).

Some of my projects have change histories going back years before Trac even existed. It would be unfortunate to expose all those emails (as is currently happening, actually)

Are you talking about the commit message or the commit author? In Darcs and Mercurial, for example, the commit author is of the form "Waldemar Kornewald <wkornewald@…>" and this could be easily obfuscated because it's stored in a separate field.

Or do you have email addresses in the commit message (i.e.: "Fixed bug #123, thanks tom@… for providing the patch.")? This would be more difficult to implement.

So basically I simplified the templates by adding two macros, one to be used in .html documents, the other in .rss documents. Text documents can also make use directly of the helper function which encapsulates the basic author information presentation logic (i.e. format_author).

The macro for html documents is named authorinfo, for consistency with the sizeinfo and dateinfo macros which are often used nearby.

Then, I believe all occurrences of the author information in the system are now protected (well, except the CC: field, but that would be a second step). I've verified this for e.g. Mercurial, where the e-mails are indeed pervasive. Note that for obfuscating the e-mails in wiki content, we could add a regexp for the e-mail addresses and either transform that to a 'mailto:' link (if show_email_addresses set or to an obfuscated email).

Some of my projects have change histories going back years before Trac even existed. It would be unfortunate to expose all those emails (as is currently happening, actually)

Are you talking about the commit message or the commit author? In Darcs and Mercurial, for example, the commit author is of the form "Waldemar Kornewald <wkornewald@…>" and this could be easily obfuscated because it's stored in a separate field.

Or do you have email addresses in the commit message (i.e.: "Fixed bug #123, thanks tom@… for providing the patch.")? This would be more difficult to implement.

I have both, your example is exactly why it would occur in the changelog. However, the author name — in exactly the form you suggest — is the primary concern. (I run Darcs with trac) In the last couple of years, I've tried to be careful about putting people's email addresses in the log messages, but I can't do anything about the author strings.

In versioncontrol/web_ui/log.py we could directly check for show_email_addresses in the if statement without defining a variable. That would save two lines of code. :)

Hmm, I think I found another issue:
By using the "Download in other formats:" function you can still retrieve email addresses. I don't know how to solve this easily, though. This could be fixed with another (independent) patch. I think that we should commit the patch, now.

… I was suggesting reusing it in other modules like: Chrome(self.env).show_email_addresses

Are you sure that Chrome is the right place for the show_email_addresses? I had a doubt about this, that's why I preferred to use getbool, for not having to add imports for Chrome that would have to be removed later…

Ok, I've committed the patch, along with the Chrome(self.env).show_email_addresses change (but don't come later saying that Chrome is not the right place for that option! ;) ), and fixes for the unit tests.

We're nearly there, but I think there are a few remaining points open before we can close this ticket:

Ok, I've committed the patch, along with the Chrome(self.env).show_email_addresses change (but don't come later saying that Chrome is not the right place for that option! ;) ), and fixes for the unit tests.

Cool, thanks!

e-mails in .csv (query and report module)

And ticket module (see at the bottom of this ticket ;).

Obfuscation of the CC: fields should be addressed separately, in #1459.

Obfuscation of the CC: fields should be addressed separately, in #1459.

Let's not leave the CC field as is for the 0.11. For now we could at least go with the JavaScript way to not render the addresses as is (document.write… see #4799). It is a simple solution that works. In the mean time, the definitive solution will come with the 0.12.

Also, as proposed at #4799, a note near e-mail related input fields saying "Your e-mail will be masked for protection against spam (learn more (link))" is also a good idea, so users will be ok to included their addresses, avoiding the "myname _AT_ mydomain _DOT_ com" entries.

Obfuscation of the CC: fields should be addressed separately, in #1459.

Let's not leave the CC field as is for the 0.11. For now we could at least go with the JavaScript way to not render the addresses as is (document.write… see #4799). It is a simple solution that works. In the mean time, the definitive solution will come with the 0.12.

Well… I'm not a Python programmer, so unfortunately I'm not able to provide a ready to use patch for it, but the implementation could be quite simple. I can give some client side bits though.

So, in the server side, it is just a matter of rendering the above snippet, replacing all "@" and "." in the Cc value with " A " and " O " respectively.

I don't know. But, even if email addresses are rendered that way in HTML (using As and Os instead of @s and dots) who guarantees that SPAM bots aren't smart enough to deobfuscate it?

Maybe I don't get it but IMHO the only option to obfuscate it is to map it to user real names, nicks or other ids that are not email addresses. In the case of the CC field a redesign would be better, though.

Maybe I don't get it but IMHO the only option to obfuscate it is to map it to user real names, nicks or other ids that are not email addresses. In the case of the CC field a redesign would be better, though.

I agree… and this is planned for the 0.12, as far as I understood. The js solution would be just quick fix for "a first level of protection" in the 0.11.

trac have became a very easy and popular target for spammers other other dirt eaters.
I vote for this one, and for any fix that will improve the privacy of trac users.
I understand that in many cases its a trade-off between ease of use and privacy (like when allowing users to enter a username or email in the ticket comments) - but its time to start taking privacy more seriously.

something that spammer does not do yet is submit through Ajax.
for my blog, I use typo. which use Ajax for posting comments. I kill 100% of my spam simply by requesting all comments to be posted through Ajax. before, they were simply doing POST request. while regular user who visit my website is filling the form and the request is sent through Ajax.

This ticket is not about preventing a trac installation itself being spammed (which one can get under control e.g. with the spamfilter plugin), but about protecting the email addresses of the legitimate users of that trac installation.

If there's any leak of e-mails information remaining for unauthorized users, please create a new ticket.

Of course, there's still the content of the CC input field itself and maybe without doing a big redesign like those discussed in #1459, it should be possible to have an Add me to CC:/Remove me from CC: checkbox instead of the CC: text input field containing every user. A new permission (TICKET_EDIT_CC) could be used in order to enable the old-style CC: editing, which can be useful for ticket owners or admins.

Now that each and every appearance of e-mails has been tracked down and filtered out, I felt it was really bad to still have the CC: field filled with e-mail addresses, as that would still allow the spammers to collect all the e-mail addresses, which is the primary concern of this ticket.

Again, if you discover any leak of e-mails information remaining for unauthorized users, please create a new ticket.

A malicious user with a little motivation could easily harvest 100's of email addresses from Trac. This can be achieved through custom queries on user-fields, using popular domain names as search criteria.

change ownership
to
The owner will be changed from cboos to the specified user.

Add Comment

This ticket has been modified since you started editing. You should review the
other modifications which have been appended above,
and any conflicts shown in the preview below.
You can nevertheless proceed and submit your changes if you wish so.