If a user has no ability to see a bug, but can edit another bug, the user can still create a dependency on the bug that he should not be able to see and get a list of the email addresses associated with that other bug. Probably, users should not be able to add dependency relationships to bugs they are not permitted to see.

You can't get the summary, though - see bug 99608. And even if you couldn't add it, you'd still see mail being sent if you marked the bug as fixed.

Not being able to add inaccessible bugs, while probably a good addition, at least as a warning, would not work, because it doesn't handle relationships that are preexisting or have been set up by other people with permission. The solution to this would seem to be to hide the email listing for that bug if you don't have permission to that bug.

I think that the approach in comment 2 solves a few problems. How do the following rules sound?? 1) Don't mention any bugs in the dependency tree that the user initiating the change is not permited to see 2) Don't notify any users of a change to a bug unless they are permitted to see the bug.

I believe (2) is already fixed in confidential bug #99608. The fix to this is certainly to hide the email list if necessary for that specific bug, by saying "You are not permitted to see the email address list for this bug." instead of saying the list. I assume you mean dependency tree in the logical sense of the dependency graph, rather than the dependency tree page, which I hope is not divulging private bugs.

Sorry, it's not confidential, probably because the major problem never appeared in a released version.

This is also a problem for duplicate marks.

Regarding comment 4, the only case I saw with cause for concern was that process_bug showed me the relevent email addresses for people involved with a bug that I had no privilege to see. The bug tree was correctly pruned.

Hey, you know, this would be easy if processmail stuff were in a template.... Are we planning on this for 2.16?

OK, someone want to explain to me why this is a security bug? So you know who has access to the bug. So what? There's worse things you can find out with the current architecture (like the fact that the bug even exists to begin with). This sounds like a very good feature request, and I'm all for hiding that info if the person can't see the relevant bug, but I don't think this is a security issue.

Unloved bugs targetted for 2.18 but untouched since 9-15-2003 are being retargeted to 2.20 If you plan to act on one immediately, go ahead and pull it back to 2.18.

This bug has not been touched by its owner in over six months, even though it is targeted to 2.20, for which the freeze is 10 days away. Unsetting the target milestone, on the assumption that nobody is actually working on it or has any plans to soon. If you are the owner, and you plan to work on the bug, please give it a real target milestone. If you are the owner, and you do *not* plan to work on it, please reassign it to nobody@bugzilla.org or a .bugs component owner. If you are *anybody*, and you get this comment, and *you* plan to work on the bug, please reassign it to yourself if you have the ability.

Now that the MTA rewrite is done, it should be possible to replace the list of users on dependency mail confirmation messages with a "mail processed" message.

Note also bug 141593 *** This bug has been marked as a duplicate of 28398 ***