289382 - Incorrect dependency bugmail recipients on bug creation

Status: RESOLVED FIXED

(Bugzilla :: Email Notifications, defect)

Description

[sakthi]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040805 Netscape/7.2
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040805 Netscape/7.2

we enter a bug comitt it , it sends an addtional information in most of he
casesupto 75 % through mail,but when we try to trace out this, by the bug number
we find the information entered is 100% correct.Thus while send mail it randomly
sends addtional entered in the previous bugs.

Reproducible: Sometimes

Steps to Reproduce:
1.try to enter a bug ,commit the bug. by ading in te cc list more than 4 person's
2.And again try to add more number of cc's & commit agiain
3.then check u'r mail id .

Actual Results:  
some addtional information about previous bugs have been aded in the mail send 

Expected Results:  
out of 3 bugs entered 2  bugs will be mailed with some adtional information

bugzila version 2.18,
if u can't reproduce it , tell me ..,any configuration file to be checked , tell
us , i clarify u..

Comment 1

[Frédéric Buclin]

Confirming. I can reproduce using the latest 2.18+ version. But I cannot
reproduce using the latest CVS version (2.19.2+), so this problem is 2.18 specific.

When filling a new bug *and* adding users to the CC list *and* marking this bug
as blocking another one, users from the CC list of the bug being filled also
receive an email from the bug being blocked as if these users were also in the
CC list of that bug! This way, the summary of the other bug appears in the
subject of the email they receive.

Nevertheless, I cannot reproduce if the bug being blocked belongs to some groups
so that no confidential information is displayed. This problem is then more
annoying than a real security issue.

But I may miss some testcase where we could access some confidential
information, so I maintain the security flag till we really know what happens here.

Comment 2

[Frédéric Buclin]

gerv, is it possible that you fixed this problem together with your emailprefs
patch checked in a few days ago? This could explain why b.m.o is affected but
not the latest CVS version.

Comment 3

[Gervase Markham [:gerv]]

LpSolit: Possibly. I could only really say when we've tracked down the cause of
the problem in the 2.18 codebase.

Gerv

Comment 4

[Teemu Mannermaa (:wicked)]

I can also reproduce this on 2.18 but not on tip. Additionally, you don't have
to add CC list entries. The reporter and assignee of the new bug also receive
the bugmail for the blocked bug. This bugmail states the same reasons for
receiving as was for the new bug bugmail. For example, assignee of the new bug
receives bugmail for the blocked bug because "he is the assignee of the bug".
This is clearly wrong statement..

It's like the bugmail sending code doesn't clear all state variables correctly
between calls to it. It's like it "remembers" values from the new bugmail that
was just sent.. Still looking.

Comment 5

[Teemu Mannermaa (:wicked)]

This problem affects only post_bug but not process_bug. Difference is in the way
these scripts specify the forced recipient lists for generated BugMail.
Process_bug uses different mailrecipients hash loaded with correct bug
information for each of the bugs it processes.

Post_bug instead uses only one mailrecipients hash that it passes to created
template. That template then uses this hash to send bugmail for each of the
affected bugs. As generated hash contains information of the new bug, all
dependency bugmails are forced to have wrong recipients in addition to correct
ones. I'm not quite sure yet how this bug should be fixed..

However, last loop that actually sends bugmail (see Bugzila/BugMail.pm line 715)
validates every recipient with CanSeeBug against the current bug. So, the wrong
recipients are excluded from receiving the bugmail if they are not allowed to
see the blocked by bug. This could mean this really is not a security issue.

This problem was fixed for tip in bug 73665 because it 1) changed post_bug to
specify only changer in forced recipient hash and 2) changed BugMail logic to
use this information only to check if this recipient wants mail or not.

Comment 6

[Dave Miller [:justdave]]

(In reply to comment #5)
> However, last loop that actually sends bugmail (see Bugzila/BugMail.pm line
> 715) validates every recipient with CanSeeBug against the current bug. So,
> the wrong recipients are excluded from receiving the bugmail if they are not
> allowed to see the blocked by bug. This could mean this really is not a
> security issue.

Agreed, it's not.

Comment 7

[Frédéric Buclin]

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

Comment 8

[Teemu Mannermaa (:wicked)]

Attachment: Mailrecipient handling fix, V1

This patch changes post_bug.cgi and bug/create/created.html.tmpl template to
use different mailrecipient hash when processing bug/process/results.html.tmpl
template. That hash contains the "forced" bugmail recipients. The bugmail for
dependent bug changes now only has changer in the hash. Bugzilla/BugMail.pm
gets rest of the recipients from DB.

Previously only one hash was used that contained information of the created
bug. This resulted in 1) incorrect bugmail to be sent for dependent bug bugmail
and 2) incorrect reasons for some people of the dependent bug.

Comment 9

[Gervase Markham [:gerv]]

Comment on attachment 187001 [details] [diff] [review]
Mailrecipient handling fix, V1

r=gerv - looks good to me by inspection.

Gerv

Comment 10

[Frédéric Buclin]

Checking in post_bug.cgi;
/cvsroot/mozilla/webtools/bugzilla/post_bug.cgi,v  <--  post_bug.cgi
new revision: 1.88.2.8; previous revision: 1.88.2.7
done
Checking in template/en/default/bug/create/created.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/bug/create/created.html.tmpl,v
 <--  created.html.tmpl
new revision: 1.8.2.1; previous revision: 1.8
done

Comment 11

[Teemu Mannermaa (:wicked)]

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