Closed Bug 219021 Opened 19 years ago Closed 13 years ago

Email addresses should only be displayed to logged in users

Categories

(Bugzilla :: User Interface, enhancement, P1)

2.17.4
enhancement

Tracking

()

RESOLVED FIXED
Bugzilla 3.4

People

(Reporter: mkanat, Assigned: mkanat)

References

(Blocks 2 open bugs)

Details

Attachments

(2 files, 10 obsolete files)

v5
37.09 KB, patch
LpSolit
: review+
Details | Diff | Splinter Review
2.37 KB, text/plain
Details
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.
No longer depends on: 120030
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
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.
Severity: normal → enhancement
Priority: -- → P3
Target Milestone: --- → Bugzilla 2.18
Version: unspecified → 2.17.4
consider it agreed to.
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. "example@domain.com" 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
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).
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
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.
*** Bug 232319 has been marked as a duplicate of this bug. ***
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)
Target Milestone: Bugzilla 2.18 → Bugzilla 2.20
*** Bug 242087 has been marked as a duplicate of this bug. ***
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. :-)
Also, looking over bug 120030 -- a good comment that relates to this from preed,
is to remember things like bug 146447 when implementing this.
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.
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.
Target Milestone: Bugzilla 2.20 → Bugzilla 2.22
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:
     username@domain.tld -> username/domain

Any takers?

Prog.
(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.)
No longer depends on: bugz_anti-spam_meta
*** Bug 298324 has been marked as a duplicate of this bug. ***
*** Bug 301215 has been marked as a duplicate of this bug. ***
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.
Attachment #189681 - Attachment is obsolete: true
Attachment #189684 - Flags: review?(LpSolit)
Comment on attachment 189684 [details] [diff] [review]
combined patch to handle email obfuscation on comments and parameter value

reviewer changed per lpsolit's request.
Attachment #189684 - Flags: review?(LpSolit) → review?(myk)
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
Assignee: myk → jforman
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. 
what about reporter, qa contact, cc, votes, bug lists, ...
(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).
*** Bug 304612 has been marked as a duplicate of this bug. ***
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.
Attachment #189684 - Flags: review?(myk) → review-
The trunk is now frozen to prepare Bugzilla 2.22. Enhancement bugs are retargetted to 2.24.
Target Milestone: Bugzilla 2.22 → Bugzilla 2.24
(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.
QA Contact: mattyt-bugzilla → default-qa
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".
Target Milestone: Bugzilla 3.0 → Bugzilla 3.2
Here's my implementation of what it looks like the Red Hat server does.  Feel free to use if you like it...
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.
Attachment #242810 - Flags: review-
(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...
(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"
Assignee: jforman → ui
Taking! I want to see this implemented in Bugzilla 3.2 and I see no activity on this bug.
Assignee: ui → LpSolit
Priority: P3 → P2
Blocks: 270435
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.
Target Milestone: Bugzilla 3.2 → Bugzilla 4.0
Changed my e-mail address a week ago. Already getting spam on it, both from advertise-bz.com.
Really hope this is implemented soon.
This patch worked for me on Bugzilla 3.0.3
It only changes how bugs are displayed.
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.
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.
Attachment #189684 - Attachment is obsolete: true
Attachment #242810 - Attachment is obsolete: true
Attachment #309468 - Attachment is obsolete: true
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
(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 <email@address.com>" or "email@address.com". 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 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
Max: are you in a position to take this forward?

Gerv
(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.

I have decided that this is pretty much priority #1 for the Bugzilla Project right now, so I'm going to take it forward.
Assignee: LpSolit → mkanat
Priority: P2 → P1
Attached patch v1 (obsolete) — Splinter Review
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).
Attachment #311822 - Attachment is obsolete: true
Attachment #322855 - Attachment is obsolete: true
Attachment #356156 - Flags: review?(LpSolit)
Status: NEW → ASSIGNED
Target Milestone: Bugzilla 4.0 → Bugzilla 3.4
Attachment #356156 - Flags: review?(LpSolit) → review-
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?
Attached patch v2 (obsolete) — Splinter Review
Okay, fixed the bitrot.
Attachment #356156 - Attachment is obsolete: true
Attachment #358471 - Flags: review?(LpSolit)
Attachment #358471 - Flags: review?(LpSolit) → review-
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 <mkanat@bugzilla.org>

You should also list Daniel Brooks (db48x@db48x.net), 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.)
(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.
(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.
I'd also like db48x to verify that my changes aren't breaking the hCard.
Attached patch v3 (obsolete) — Splinter Review
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.
Attachment #358471 - Attachment is obsolete: true
Attachment #359203 - Flags: review?(LpSolit)
(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:mkanat@bugzilla.org" title="Max Kanat-Alexander &lt;mkanat@bugzilla.org&gt;">Max Kanat-Alexander
            </a>

This is how I copy and paste user identity in CVS commit messages for months (maybe years now).
Attachment #359203 - Flags: review?(LpSolit) → review-
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).
(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.
(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.
Attached patch v4 (obsolete) — Splinter Review
Okay, this handles all the stuff you mentioned above. I agree that we should use another bug to fix the attachment details page.
Attachment #359203 - Attachment is obsolete: true
Attachment #359328 - Flags: review?(LpSolit)
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.
Attachment #359328 - Flags: review?(LpSolit) → review-
Attached patch v5Splinter Review
Okay, now filtering graphical report headers. :-)
Attachment #359328 - Attachment is obsolete: true
Attachment #359400 - Flags: review?(LpSolit)
Comment on attachment 359400 [details] [diff] [review]
v5

r=LpSolit
Attachment #359400 - Flags: review?(LpSolit) → review+
Flags: approval+
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
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
(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.
Blocks: 477459
(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
Blocks: 477662
Blocks: 477745
Duplicate of this bug: 480656
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
Reopening as this causes a DoS problem when comments have certain text in them.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Filing in another bug. Sorry for the spam.
Status: REOPENED → RESOLVED
Closed: 13 years ago13 years ago
Resolution: --- → FIXED
Blocks: 481506
Duplicate of this bug: 489295
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.
(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.
Added to the release notes for Bugzilla 3.4 in bug 494037.
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.
Blocks: 533927
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
(In reply to Samuel from comment #75)
> This is not resolved.

Discussed in bug 1092445 instead
You need to log in before you can comment on or make changes to this bug.