219021 - Email addresses should only be displayed to logged in users

Status: RESOLVED FIXED

(Bugzilla :: User Interface, enhancement, P1)

Description

[Max Kanat-Alexander]

This is a spinoff bug from bug 120030. See comment 65, comment 73

The idea is that all user email addresses in Bugzilla should only be displayed
when the end user is logged in.

Here's my implementation idea:

For Comment Links
-----------------
When a user is not logged in, the names on bug comments are not links. Instead
there is a small link that says "Log in to email this user" The links contain,
as query data, the user's name and the bug number. They would look something like:

sendemail.cgi?toUsername=joe&bug=218917

When clicked on, this would:

1) Have the user log in.
2) Return the user to the bug page, and move to the link they clicked on.
3) Use JavaScript to open an email properly addressed. (this is optional, and
perhaps could be a BZ preference.)

The JavaScript is to make it more like, "I clicked on this link and then there
was an email." However, for non-JS browsers, the user would still be returned to
the link, and could then click on it.

CC List
-------
For the CC List, instead of the multiple select box that lists the emails, there
would be a link which said "Log in to see CC list."

This entire behavior should be optional, and be embodied in an administrative
preference.

Will Spammers get Accounts?
---------------------------
Probably not. They did it on ebay in the past, but that's because ebay is one of
the largest web sites in the world. bugzilla.mozilla.org is probably the largest
bugzilla installation, and even it isn't near the size for spammers to care.
Also, not all BugZilla installations are b.m.o. It's possible that they will.
Then, we still have the email filter implemented in bug 120030, which we could
possibly change at some point in the future it that became incredibly necessary.

Also, it should be somewhat apparent if somebody is spam-harvesting BugZilla
through an account, since you'll see a ridiculous number of hits from that account.

And, of course, if there ever is a ebay-sized or yahoo-sized BugZilla
installation, we could implement protections against auto-creation of accounts,
which would pretty much stop spammers.

What About Emails in Bug Comments?
----------------------------------
Two Options:
1) They can just be obfuscated from the code in bug 120030.
2) They can be read with a regexp and changed to "Log in to see email" links.
(Might be too much load on bugzilla).

One could also provide a preference for this, as smaller installations may be
more concerned about spam and less concerned about performance.

Comment 1

[Max Kanat-Alexander]

Slight clarification: "It's possible that they will." should be "It's possible
that spammers will get accounts."

And by the "Emails in bug comments" heading I mean "Emails that the bug reporter
or commenter types into his/her comment/summary."

-M

Comment 2

[Joel Peshkin]

I agree that this shold take care of any spider that just crawls and stumbles on
Bugzilla instead of being customized to Bugzilla.  I expect that will get the
vast majority of them.

If this gets agreement in principle from a few key people, let's do it.

Comment 3

[Dave Miller [:justdave]]

consider it agreed to.

Comment 4

[Gervase Markham [:gerv]]

A very interesting and relevant document is the Center for Democracy and
Technology's "Why am I getting all this spam?" research:
http://www.cdt.org/speech/spam/030319spamreport.shtml

To summarise:

"CDT tested two methods of obstructing address harvesting:

    * Replacing characters in an e-mail address with human-readable equivalents, 
      e.g. "[e-mail]" was written "example at domain dot com;" and
    * Replacing characters in an e-mail address with HTML equivalents.

E-mail addresses posted to Web sites using these conventions did not receive any
spam."

The second of those two methods is the one implemented by bug 120030. Note:
addresses obfuscated in this way did not receive _any_ spam at all.

I'm not saying spammers won't get smarter eventually. But I am saying that,
given those findings, this bug isn't a priority - because what we've done is
sufficient for now. As the proposed solution removes function from Bugzilla, we
should present evidence that it will actually reduce the amount of spam sent to
the addresses in question before we implement it.

Gerv

Comment 5

[Stephen Lee]

Admittedly I'm biased, but IMHO bug 218917 is the way to go on this, and after 
such an email_address / login_name split, hiding email addresses from non-
logged in users will be quite straightforward (rather than the massive number 
of conditional expressions in templates that might be needed otherwise).

Comment 6

[K.H. Pennemann]

A possible strategy to keep 'smart' spammers away could be to leave the
obfuscation of the email address to the respective user.

Proposal: Every user is self responsible for supplying an obfuscated version of
his contact address (via bugzilla preferences). The real address is only used
internally and is never shown on the bugzilla pages (to regular users or
guests). If no obfuscated version is supplied, then the real address (or a
standard obfuscation of it) is used.

Benefit: obfuscations are to some degree unique and not generally automatically
reversible

Comment 7

[Daniel Wang]

re comment 6:
The solution is unacceptable. To foster open communication in this open
community, we should encourage contributors to use their real names and real
e-mail addresses. Allowing e-mail obfuscating, especially to such a degree that
it becomes visible to humans, sends the users the wrong message. Also, bug
comments are mailed to people and often people respond in private mail.
Obfuscating would be counter-productive.

Comment 8

[timeless]

*** Bug 232319 has been marked as a duplicate of this bug. ***

Comment 9

[Dave Miller [:justdave]]

Enhancements which don't currently have patches on them which are targetted at
2.18 are being retargetted to 2.20 because we're about to freeze for 2.18. 
Consideration will be taken for moving items back to 2.18 on a case-by-case
basis (but is unlikely for enhancements)

Comment 10

[Dave Miller [:justdave]]

*** Bug 242087 has been marked as a duplicate of this bug. ***

Comment 11

[Max Kanat-Alexander]

Red Hat has implemented this already, a while ago. You can see how it works at
http://bugzilla.redhat.com/

dkl could maybe even get us a patch for us here. :-)

Comment 12

[Max Kanat-Alexander]

Also, looking over bug 120030 -- a good comment that relates to this from preed,
is to remember things like bug 146447 when implementing this.

Comment 13

[David Lawrence [:dkl]]

Basically it is just some template hackery which looks for whether someone is logged in otherwise just 
prints the realname value without a mailto: link. I will see if it is worthy of a patch.

Comment 14

[Dave Miller [:justdave]]

Bugzilla 2.20 feature set is now frozen as of 15 Sept 2004.  Anything flagged
enhancement that hasn't already landed is being pushed out.  If this bug is
otherwise ready to land, we'll handle it on a case-by-case basis, please set the
blocking2.20 flag to '?' if you think it qualifies.

Comment 15

[Prognathous]

How about this alternative:

- Always show email addresses to Gecko users - even when they're logged out
- Always show email addresses to logged in users (see comment 0)
- For all the others:
  1. Hide email addresses
  2. Obfuscate email-addresses-as-usersnames, using the following format:
     [e-mail] -> username/domain

Any takers?

Prog.

Comment 16

[Jeff Walden [:Waldo]]

(In reply to comment #15)
> How about this alternative:

What's needed now is a patch, not suggestions.

(Personally, I see no reason to unnecessarily complicate things by displaying
email addresses to Gecko users.  The original, base idea of displaying addresses
only to logged-in users is still perfectly fine.  Remember, this bug is for
Bugzilla, not b.m.o.)

Comment 17

[Frédéric Buclin]

*** Bug 298324 has been marked as a duplicate of this bug. ***

Comment 18

[Jeffrey Forman]

*** Bug 301215 has been marked as a duplicate of this bug. ***

Comment 19

[Jeffrey Forman]

Attachment: patch to comments template to poll emailobfuscate param value

Comment 20

[Jeffrey Forman]

Attachment: combined patch to handle email obfuscation on comments and parameter value

apologies on the dupes and missubmissions of patches. hopefully this one is
sufficient. this patches defparams.pl and comments.html.tmpl so that one can
easily turn off/on email obfuscation in the comments.

Comment 21

[Jeffrey Forman]

Comment on attachment 189684 [details] [diff] [review]
combined patch to handle email obfuscation on comments and parameter value

reviewer changed per lpsolit's request.

Comment 22

[Gervase Markham [:gerv]]

Why is this a parameter? If the Bugzilla is public, you need it. If the Bugzilla
is private, people are going to always be logged in anyway, so will not be
affected by the munging. So why not just always have it on?

GErv

Comment 23

[Jeffrey Forman]

Gerv,

Some may not want mungling at all. That is up to the admin. I made it a
parameter so it is more easily controlled. Earlier comments were asking for
code, and so I provided. 

Comment 24

[:glob ✱]

what about reporter, qa contact, cc, votes, bug lists, ...

Comment 25

[Stephen Lee]

(In reply to comment #24)
> what about reporter, qa contact, cc, votes, bug lists, ...

Some of these currently need to show the login/user name for operational reasons
- (e.g. CC list so that when you click on "Remove selected CCs", it knows who
you mean, etc.). It would be a significant loss of functionality for some users
if you cannot edit the bug just before being asked for login credentials.

In my opinion, I see no harm in removing mailto: links and display of email
addresses where possible with a simple patch like this, but I would suggest than
anything that requires more extensive changes would be best left for bug 218917
and bug 163551 or similar (such that there is no longer any need for email
addresses to be displayed to ANYONE unless you explicitly allow it).

Comment 26

[Max Kanat-Alexander]

*** Bug 304612 has been marked as a duplicate of this bug. ***

Comment 27

[Myk Melez [:myk] [@mykmelez]]

Comment on attachment 189684 [details] [diff] [review]
combined patch to handle email obfuscation on comments and parameter value

This is a great start, but it has limited effect as implemented, since it only
handles commenters.  This code should be factored out into a separate template,
f.e. global/userref.html.tmpl, that contains a block for formatting addresses,
i.e. something like:

[% userref = BLOCK %]
(code displaying either a hyperlinked address or the user's name)
[% END %]

The template can then be used by multiple other templates to hide email
addresses for users on bug lists, the request queue, and other places in
addition to commenters on show bug.  Note that while we can't hide the QA
contact's or cc:er's email addresses, we can and should also hide the
reporter's and assignee's addresses on a bug when a non-logged in user is
looking at it.

Comment 28

[Frédéric Buclin]

The trunk is now frozen to prepare Bugzilla 2.22. Enhancement bugs are retargetted to 2.24.

Comment 29

[Takanori MATSUURA]

(In reply to comment #11)

I also think 
https://bugzilla.redhat.com/bugzilla/
is a good solution.

Email addresses in Reporter, Assigned To, CC, and header of each comments are hidden if users access to the bugzilla without login.

Comment 30

[Frédéric Buclin]

This bug is retargetted to Bugzilla 3.2 for one of the following reasons:

- it has no assignee (except the default one)
- we don't expect someone to fix it in the next two weeks (i.e. before we freeze the trunk to prepare Bugzilla 3.0 RC1)
- it's not a blocker

If you are working on this bug and you think you will be able to submit a patch in the next two weeks, retarget this bug to 3.0.

If this bug is something you would like to see implemented in 3.0 but you are not a developer or you don't think you will be able to fix this bug yourself in the next two weeks, please *do not* retarget this bug.

If you think this bug should absolutely be fixed before we release 3.0, either ask on IRC or use the "blocking3.0 flag".

Comment 31

[Steve Wendt]

Attachment: patch to display names instead of emails when not logged in

Here's my implementation of what it looks like the Red Hat server does.  Feel free to use if you like it...

Comment 32

[Frédéric Buclin]

Comment on attachment 242810 [details] [diff] [review]
patch to display names instead of emails when not logged in

There are many other places where the email address is displayed (such as request.cgi). Moreover, nothing would be displayed for users who have no realname. Also, as the realname is not unique, you cannot distinguish them.

Comment 33

[Steve Wendt]

(In reply to comment #32)
> There are many other places where the email address is displayed (such as
> request.cgi). 

Yes, but it takes care of more than the last patch posted.  ;)
I didn't request a review, because I knew it was incomplete.

> Moreover, nothing would be displayed for users who have no
> realname. Also, as the realname is not unique, you cannot distinguish them.

These are probably "don't care" items for most Bugzilla admins...

Comment 34

[Max Kanat-Alexander]

(In reply to comment #33)
> > Moreover, nothing would be displayed for users who have no
> > realname. Also, as the realname is not unique, you cannot distinguish them.
> 
> These are probably "don't care" items for most Bugzilla admins...

  The fact that the realname isn't unique is fine. You could display the username without the "@domain" part, if you want.

  For users who don't have a domain name, just display the username without "@domain"

Comment 35

[Frédéric Buclin]

Taking! I want to see this implemented in Bugzilla 3.2 and I see no activity on this bug.

Comment 36

[Max Kanat-Alexander]

Bugzilla 3.2 is now frozen. Only enhancements blocking 3.2 or specifically approved for 3.2 may be checked in to the 3.2 branch. If you would like to nominate your enhancement for Bugzilla 3.2, set the "blocking3.2" flag to "?", and either the target milestone will be changed back, or the blocking3.2 flag will be granted, if we will accept this enhancement for Bugzilla 3.2.

Comment 37

[Sander Goudswaard]

Changed my e-mail address a week ago. Already getting spam on it, both from advertise-bz.com.
Really hope this is implemented soon.

Comment 38

[Christopher Brooks]

Attachment: Patch Bugzilla 3.0.3 bug display to show only email if user is logged in

This patch worked for me on Bugzilla 3.0.3
It only changes how bugs are displayed.

Comment 39

[Craig Dunigan]

Attachment: hides email addresses from all but trusted group

Tested only on v3.0.2.  This patch was created using GNU diff against v3.0.2 instead of CVS diff, as I never set up Mozilla CVS access.  It will change User.pm per Michael Tosh's suggestion on the mailing list (http://groups.google.com/group/mozilla.support.bugzilla/browse_thread/thread/10722f83dd3d13b1/4583e8d04dec0c33?lnk=gst&q=hide+email#4583e8d04dec0c33).  
I wrote the template and cgi changes so that they follow David Miller's suggestion in the same thread - the patch hides email addresses based on membership in a "trusted group" instead of just checking login status.  I'm not too familiar with Template Toolkit yet, so the "trusted group is re-created in several places, as I didn't spend much time trying to figure out how to do it only once.  Anyone who knows how can give me suggestions or just change the code, if you'd like, but until then, you'll have to change every instance of "trusted_group" to the group name you'd like to use.  Ideally, "trusted_group" could be made into a new Bugzilla parameter, and then reused from there, but I don't know how to do that yet, either.  Apologies if the patch format causes you trouble.

Comment 40

[Max Kanat-Alexander]

Attachment: Patch for 3.0.x to hide email addresses from logged-out users

This patch was developed by Everything Solved for a client--this modifies Bugzilla 3.0 to hide email addresses from all logged-out users. It just cuts off the domain part of the email address, so you can still see the username part of their email (particularly useful for open-source communities that know people by their usernames instead of their real names) but not the whole email address.

It wouldn't be too hard to update this patch for HEAD, if somebody wanted to.

Comment 41

[David Lawrence [:dkl]]

I like the idea of using a filter to do the grunt work so that having conditionals all through out the templates is not needed. But I think having the profiles.realname displayed if it is available would look cleaner. And then have the hostname cut off if the realname is blank.

But I suppose in order to look up the realname a db call would need to be made in the filter code which may or may not cause a performance hit.

Dave

Comment 42

[Max Kanat-Alexander]

(In reply to comment #41)
> But I suppose in order to look up the realname a db call would need to be made
> in the filter code which may or may not cause a performance hit.

  Sort of. Really, the idea was to have one filter for all possible fields, which mean that you could have an identity with "Real Name <[e-mail]>" or "[e-mail]". So for simplicity's sake, this handles both cases with only one piece of code (which is important, since when we call "user.identity" from a template, we have no idea what we'll get).

Comment 43

[Gervase Markham [:gerv]]

Comment on attachment 322855 [details] [diff] [review]
Patch for 3.0.x to hide email addresses from logged-out users

>+DefineColumn("assigned_to_sort"       ,"map_assigned_to.login_name"      , "Assignee"         );
>+DefineColumn("reporter_sort"          ,"map_reporter.login_name"         , "Reporter"         );
>+DefineColumn("qa_contact_sort"        ,"map_qa_contact.login_name"       , "QA Contact"       );

The only thing I don't get is what are these three new columns? They don't seem to be referenced anywhere else in the patch. Otherwise, r=gerv.

Gerv

Comment 44

[Gervase Markham [:gerv]]

Max: are you in a position to take this forward?

Gerv

Comment 45

[Max Kanat-Alexander]

(In reply to comment #44)
> Max: are you in a position to take this forward?

  I don't think so. I might have a contract somewhere that wants me to do so for some client or another. If so then it will get brought forward even though it's not otherwise one of my upstream priorities.

Comment 46

[Max Kanat-Alexander]

I have decided that this is pretty much priority #1 for the Bugzilla Project right now, so I'm going to take it forward.

Comment 47

[Max Kanat-Alexander]

Attachment: v1

Okay! This truncates emails to the part before the @, if you're logged out.

A few pages had functionality changes:

* votes.cgi now uses user_ids instead of usernames.
* We now show the CC list to logged-out people, since it should be safe.
  (I'm actually not sure why we weren't showing it to them before.)
* describecomponents.cgi will now show people's real names instead of 
  their login names, and if you are logged in, their real name will be
  an hCard.

Let me know if I missed filtering emails on any pages that logged-out users can see. I actually did quite a bit of testing on this, and I'm pretty sure that all the pages I did modify work fine for logged-out users. I also tested most for logged-in users (though for many pages, the behavior for logged-in users didn't change and I didn't test that extensively).

Comment 48

[Frédéric Buclin]

Comment on attachment 356156 [details] [diff] [review]
v1

2 out of 2 hunks FAILED -- saving rejects to file buglist.cgi.rej

DefineColumn no longer exists, right?

Comment 49

[Max Kanat-Alexander]

Attachment: v2

Okay, fixed the bitrot.

Comment 50

[Frédéric Buclin]

Comment on attachment 358471 [details] [diff] [review]
v2

>Index: buglist.cgi

>+        $columns->{$colname}->{name} =
>+            "CASE WHEN map_assigned_to.realname = '' 
>+                  THEN $login ELSE map_assigned_to.realname 
>+                   END AS $colname";

map_assigned_to is hardcoded. assigned_to must be replaced by a variable.



>Index: Bugzilla/Util.pm

>+sub email_quote {

>+    my ($email) = Email::Address->parse($toencode);
>+    if (!Bugzilla->user->id && $email) {

You should only call Email::Address if the user is logged out. If the user is logged in, we already know we won't use $email at all.


>+        my $host = $email->host;
>+        $toencode =~ s/\@$host//g;

You should split email addresses and use $email->user, which will do what you want. If you have several users with a different domain (host), e.g. the CC list or flag changes in the bug activity table, only those having the same domain as the first user of the list will be correctly filtered. Others will be left unaltered.

Did you try to use $user->nick when we have a user object? It already does what you want.



>Index: template/en/default/bug/activity/table.html.tmpl

>-                  [% change.removed FILTER html %]
>+                  [% change.removed FILTER email FILTER html %]

When you edit several flags at once, or add/remove several users from the CC list at once, and some users have a different domain name, only the first user and users having the same domain are filtered, because Util::email_quote() is only able to filter one domain at once.



>Index: template/en/default/global/user.html.tmpl

>+  # Contributor(s): 
>+  #  Max Kanat-Alexander <[e-mail]>

You should also list Daniel Brooks ([e-mail]), who is the original author of this code, see bug 369429. It seems a bit unfair to me to cut and paste the code into a separate template and add yourself as the only contributor of the template.


>+         title="[% who.email FILTER html %]">

I would prefer who.identity as title, to match what we have on b.m.o (it's also easier to copy and paste patch authors in CVS commit messages :)).



>Index: template/en/default/request/queue.html.tmpl

You also have to filter request.$group_field in:

  <h3>[% column_headers.$group_field %]: [% (request.$group_field || "None") FILTER html %]</h3>

when you group by requester or requestee. Else the full login name is displayed.


Some more problems:

- Graphical reports (pie, bar, line) still display the full login name.
- In XML format, show_bug still displays the full login name in the CC list.
- Your patch doesn't pass tests:

t/008filter..........NOK 7/263
#   Failed test '(en/default) template/en/default/bug/show.xml.tmpl has unfiltered directives:
#   140: val FILTER
#     xml
# --ERROR'


Otherwise, it looks good. (the UI may be a bit confusing when using tabular reports and several users have the same nick. But I guess that's really minor.)

Comment 51

[Max Kanat-Alexander]

(In reply to comment #50)
> You should split email addresses and use $email->user, which will do what you
> want.

  No, because I also want it to preserve any text that comes before the email address, if it exists.

> Did you try to use $user->nick when we have a user object? It already does what
> you want.

  I never have a user object inside the filter, but outside the filter it could be used.

> It seems a bit unfair to me to cut and
> paste the code into a separate template and add yourself as the only
> contributor of the template.

  It wasn't intentional. I don't know why you would assume it was.

> - Graphical reports (pie, bar, line) still display the full login name.

  Yes, but not as text, right? So we don't care, because this is only about spam.


  In response to everything else: I'm glad that you noticed, and I will fix.

Comment 52

[Max Kanat-Alexander]

(In reply to comment #50)
> >+         title="[% who.email FILTER html %]">
> 
> I would prefer who.identity as title, to match what we have on b.m.o (it's also
> easier to copy and paste patch authors in CVS commit messages :)).

  I just checked, and bmo has email here, not identity. As far as the copy and paste, I'm not sure what you're talking about, also, since you can't cut-and-paste a tooltip.

Comment 53

[Max Kanat-Alexander]

I'd also like db48x to verify that my changes aren't breaking the hCard.

Comment 54

[Max Kanat-Alexander]

Attachment: v3

Okay, I modified the email filter to remove all email addresses from any string, even if there are multiple email addresses. This allows us to also filter comments, which is a nice little bonus. If the comment filtering isn't perfect, that's OK with me, since it's really just a bonus.

Anyhow, I fixed everything else that needed fixing.

Comment 55

[Frédéric Buclin]

(In reply to comment #52)
> > I would prefer who.identity as title
>   I just checked, and bmo has email here, not identity. As far as the copy and
> paste, I'm not sure what you're talking about, also, since you can't
> cut-and-paste a tooltip.

Yes you can. Right-click the link, then Properties. You get the identity. And I also checked, and bmo uses the user identity:

<a href="mailto:[e-mail]" title="Max Kanat-Alexander &lt;[e-mail]&gt;">Max Kanat-Alexander
            </a>

This is how I copy and paste user identity in CVS commit messages for months (maybe years now).

Comment 56

[Frédéric Buclin]

Comment on attachment 359203 [details] [diff] [review]
v3

We are very close now. Only a few minor things left to fix:


>Index: Bugzilla/Util.pm

>+sub email_quote {

Please add POD for this function. Also, I think it worths a test or two in t/007util.t.


>Index: template/en/default/global/user.html.tmpl

>+      <a class="email" href="mailto:[% who.email FILTER html %]"
>+         title="[% who.email FILTER html %]">

I really want who.identity for the title, see my previous comment. :)


>Index: template/en/default/reports/report-table.html.tmpl

I didn't notice it before, but when you set Multiple Tables to reporter, assignee or QA contact, the login name is not filtered. This also affects all graphical reports and CSV as the title of the graphs is plain text.


When you view the Details page of an attachment, all requestees are displayed with their full login name. This page may require a bit more work to do what we want, and I'm fine to fix this page in a separate bug (please CC pyrzak and me).

Comment 57

[Frédéric Buclin]

(In reply to comment #55)
> Yes you can. Right-click the link, then Properties. You get the identity.

Oh, to be more precise, I right-click the name of the attacher in the attachment table. This is a very cool way to get the attacher's identity. And I think we should use this everywhere.

Comment 58

[Reed Loden [:reed]]

(In reply to comment #56)
> >+      <a class="email" href="mailto:[% who.email FILTER html %]"
> >+         title="[% who.email FILTER html %]">
> 
> I really want who.identity for the title, see my previous comment. :)

I agree with making title the identity, fyi.

Comment 59

[Max Kanat-Alexander]

Attachment: v4

Okay, this handles all the stuff you mentioned above. I agree that we should use another bug to fix the attachment details page.

Comment 60

[Frédéric Buclin]

Comment on attachment 359328 [details] [diff] [review]
v4

>Index: template/en/default/reports/report-table.html.tmpl

>-  <h2>[% tbl_disp FILTER html %]</h2>
>+  <h2>[% tbl_disp FILTER email FILTER html %]</h2>

You also have to fix the H2 title for CSV and graphical reports.


Everything else looks good and works as expected.

Comment 61

[Max Kanat-Alexander]

Attachment: v5

Okay, now filtering graphical report headers. :-)

Comment 62

[Frédéric Buclin]

Comment on attachment 359400 [details] [diff] [review]
v5

r=LpSolit

Comment 63

[Max Kanat-Alexander]

Woot! :-)

Checking in buglist.cgi;
/cvsroot/mozilla/webtools/bugzilla/buglist.cgi,v  <--  buglist.cgi
new revision: 1.390; previous revision: 1.389
done
Checking in votes.cgi;
/cvsroot/mozilla/webtools/bugzilla/votes.cgi,v  <--  votes.cgi
new revision: 1.57; previous revision: 1.56
done
Checking in Bugzilla/DB.pm;
/cvsroot/mozilla/webtools/bugzilla/Bugzilla/DB.pm,v  <--  DB.pm
new revision: 1.123; previous revision: 1.122
done
Checking in Bugzilla/Template.pm;
/cvsroot/mozilla/webtools/bugzilla/Bugzilla/Template.pm,v  <--  Template.pm
new revision: 1.98; previous revision: 1.97
done
Checking in Bugzilla/Util.pm;
/cvsroot/mozilla/webtools/bugzilla/Bugzilla/Util.pm,v  <--  Util.pm
new revision: 1.82; previous revision: 1.81
done
Checking in t/007util.t;
/cvsroot/mozilla/webtools/bugzilla/t/007util.t,v  <--  007util.t
new revision: 1.12; previous revision: 1.11
done
Checking in template/en/default/attachment/list.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/attachment/list.html.tmpl,v  <--  list.html.tmpl
new revision: 1.39; previous revision: 1.38
done
Checking in template/en/default/bug/comments.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/bug/comments.html.tmpl,v  <--  comments.html.tmpl
new revision: 1.40; previous revision: 1.39
done
Checking in template/en/default/bug/dependency-tree.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/bug/dependency-tree.html.tmpl,v  <--  dependency-tree.html.tmpl
new revision: 1.31; previous revision: 1.30
done
Checking in template/en/default/bug/edit.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/bug/edit.html.tmpl,v  <--  edit.html.tmpl
new revision: 1.149; previous revision: 1.148
done
Checking in template/en/default/bug/show-multiple.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/bug/show-multiple.html.tmpl,v  <--  show-multiple.html.tmpl
new revision: 1.44; previous revision: 1.43
done
Checking in template/en/default/bug/show.xml.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/bug/show.xml.tmpl,v  <--  show.xml.tmpl
new revision: 1.26; previous revision: 1.25
done
Checking in template/en/default/bug/activity/table.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/bug/activity/table.html.tmpl,v  <--  table.html.tmpl
new revision: 1.17; previous revision: 1.16
done
Checking in template/en/default/bug/votes/list-for-bug.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/bug/votes/list-for-bug.html.tmpl,v  <--  list-for-bug.html.tmpl
new revision: 1.13; previous revision: 1.12
done
RCS file: /cvsroot/mozilla/webtools/bugzilla/template/en/default/global/user.html.tmpl,v
done
Checking in template/en/default/global/user.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/global/user.html.tmpl,v  <--  user.html.tmpl
initial revision: 1.1
done
Checking in template/en/default/list/list.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/list/list.html.tmpl,v  <--  list.html.tmpl
new revision: 1.64; previous revision: 1.63
done
Checking in template/en/default/reports/components.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/reports/components.html.tmpl,v  <--  components.html.tmpl
new revision: 1.14; previous revision: 1.13
done
Checking in template/en/default/reports/report-table.csv.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/reports/report-table.csv.tmpl,v  <--  report-table.csv.tmpl
new revision: 1.12; previous revision: 1.11
done
Checking in template/en/default/reports/report-table.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/reports/report-table.html.tmpl,v  <--  report-table.html.tmpl
new revision: 1.17; previous revision: 1.16
done
Checking in template/en/default/reports/report.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/reports/report.html.tmpl,v  <--  report.html.tmpl
new revision: 1.16; previous revision: 1.15
done
Checking in template/en/default/request/queue.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/request/queue.html.tmpl,v  <--  queue.html.tmpl
new revision: 1.21; previous revision: 1.20
done

Comment 64

[Frédéric Buclin]

(In reply to comment #56)
> When you view the Details page of an attachment, all requestees are displayed
> with their full login name. This page may require a bit more work to do what we
> want, and I'm fine to fix this page in a separate bug

See bug 365267.

Comment 65

[Max Kanat-Alexander]

(In reply to comment #64)
> See bug 365267.

  Hmm, although I think at this point that's too much enhancement work (since we're frozen). Probably the best is just to add the uneditable flag view to flag/list.html.tmpl

Comment 67

[David Lawrence [:dkl]]

Attachment: Test script that illustrates issue with certain text and Email::Address

Reopening as this causes a DoS problem when comments have certain text in them.

Since bug comments are now filtered using Bugzilla::Util::email_filter, Email::Address is not able to handle some blocks of text properly and consumes massive amounts of CPU and also denies access to the bug itself for others.

I am attaching a simple script that has the text from out site that causes the issue.

Dave

Comment 68

[David Lawrence [:dkl]]

Reopening as this causes a DoS problem when comments have certain text in them.

Comment 69

[David Lawrence [:dkl]]

Filing in another bug. Sorry for the spam.

Comment 71

[Mike Coppins]

I assume this fix isn't in effect on the version of Bugzilla currently in use here, because I can still see peoples' e-mail addresses without being logged in.

Comment 72

[Max Kanat-Alexander]

(In reply to comment #71)
> I assume this fix isn't in effect on the version of Bugzilla currently in use
> here, because I can still see peoples' e-mail addresses without being logged
> in.

  That's correct. If you look, you'll see that the Target Milestone of this bug is 3.4 (which hasn't been released yet), and this Bugzilla is 3.2.3.

Comment 73

[Max Kanat-Alexander]

Added to the release notes for Bugzilla 3.4 in bug 494037.

Comment 74

[BoffinBrain]

I've started receiving spam for my Bugzilla address, so I know bots are getting it from here.  Please, when can we see this updated?  It should be top priority.

Comment 75

[Sam H]

This is not resolved. I can see my email address everywhere in this bug, without being logged in:

https://bugzilla.mozilla.org/show_bug.cgi?id=1034952

Comment 76

[Andre Klapper]

(In reply to Samuel from comment #75)
> This is not resolved.

Discussed in bug 1092445 instead