Spam in the bug tracker

Spam in the bug tracker

[Mikko Huhtala]

Looks to me like the spam situation in the bug tracker is quite bad.

Would it be possible to limit the bug tracker to mailing list
subscribers? One can turn off receiving the list email in mailman, so
it shouldn't be too much to ask for of users to subscribe. They don't
need to get all that mail in their inboxes if they don't want to. Or
would this requirement be a problem for report-emacs-bug?

Mikko

Re: Spam in the bug tracker

[Samuel Bronson]

On Fri, May 8, 2009 at 8:13 AM, Mikko Huhtala <mhuhtala@abo.fi> wrote:

> Would it be possible to limit the bug tracker to mailing list
> subscribers? One can turn off receiving the list email in mailman, so
> it shouldn't be too much to ask for of users to subscribe. They don't
> need to get all that mail in their inboxes if they don't want to. Or
> would this requirement be a problem for report-emacs-bug?

Yes, it would be a problem for report-emacs-bug. We need to come up
with a way to get rid of the spam before it hits the tracker without
causing anyone too much work.

Re: Spam in the bug tracker

[Mikko Huhtala]

Samuel Bronson writes:

 > We need to come up with a way to get rid of the spam before it hits
 > the tracker without causing anyone too much work.

Maybe require the messages sent by report-emacs-bug to be confirmed by
replying to a 'did you send this' question from the tracker? That
would cut off most of the spammers, but it does require something more
than a mailing list on the server side.

Mikko

Re: Spam in the bug tracker

[Stefan Monnier]

>> Would it be possible to limit the bug tracker to mailing list
>> subscribers? One can turn off receiving the list email in mailman, so
>> it shouldn't be too much to ask for of users to subscribe. They don't
>> need to get all that mail in their inboxes if they don't want to. Or
>> would this requirement be a problem for report-emacs-bug?
> Yes, it would be a problem for report-emacs-bug. We need to come up
> with a way to get rid of the spam before it hits the tracker without
> causing anyone too much work.

The solution is known, stop looking for it: the bug-reporting address
needs to be moderated.  As for the problem, it is that we have very
little control over emacsbugs.donarmstrong.com and over the email
processing at gnu.org, so any solution we come up with will currently
not be applicable.


        Stefan

Re: Spam in the bug tracker

[David De La Harpe Golden]

[Getting kind of OT for emacs-devel I guess, and likely old hat to Don 
Armstrong &co., but just in case]:

Mikko Huhtala wrote:
> Samuel Bronson writes:
> 
>  > We need to come up with a way to get rid of the spam before it hits
>  > the tracker without causing anyone too much work.
> 
> Maybe require the messages sent by report-emacs-bug to be confirmed by
> replying to a 'did you send this' question from the tracker?

Well, only questioning messages tagged probable-spam by spamassasin (or 
whatever). In the modern era such challenge-response systems can 
themselves potentially be abused for their backscatter possibilities 
with fake from addresses though.

*** what RT land does:

Anyway, over in RT land, probable-spams are typically diverted into a 
"spam" RT queue with enough data about where they would have gone if 
they hadn't been tagged so that a probable-spam can be moved to a real 
RT queue if it's a false positive (either manually detected or via 
aforementioned challenge-response).

http://www.soundwave.net/~wmono/rt/
http://wiki.bestpractical.com/view/SpamFiltering

I don't see why something similar couldn't be done in the debbugs case, 
apart from needing someone who deeply understands debbugs internals to 
actually implement it... if it's not there already, which it might be...

Due to some very basic design differences in debbugs vs. RT (the latter 
being what I'm really familiar with), I'm having a slightly difficult 
time imagining how best to implement it for debbugs, something Don has 
probably thought about a lot more, but here's my blowhard take on it:

Way I see it, there are three main cases - (using "spamassassin" to mean 
"spamassassin or whatever", and assuming mails incoming to the tracker
are passed through said "spamassassin or whatever" and are thereby
tagged with the usual this-looks-like-spam headers):

*** 1. spam that would open new bugs:

That's relatively easy. Go ahead and open the bug, but auto-reassign to 
a package "spam" based on the spamassassin headers.  Someone needs to 
check that package every so often for false positives to be reassigned 
to real emacs package, and closing definite-spam bugs.

*** 2. spam that's going to existing bugs:

Maybe giving every single debbugs bug two "micro mailing lists" instead 
of just one would in fact be the best approach, though extravagant 
looking on the surface, the micro mailing lists are obviously not that 
heavyweight given there's a new one for every bug anyway...

  i.e. 1234@bugs.example.com and 1234-suspected-spam@bugs.example.com 
mail sent to the former being diverted to the latter if it looks like 
spam to spamassassin. Then a "rescue this mail from the per-bug 
spambucket" becomes a relatively easy op to implement, just a forward, 
and people owning each individual bug can take responsibility for 
checking their bug's per-bug spambucket for spam once in a while.  The 
spambucket micro mailing list could presumably have a different cc list 
to the main bug micro mailing list to avoid echoing suspected spam to 
every subscriber to the bug. Could perhaps do the 
challenge-response-auto-rescue thing since could also have a different 
autoreply for the diverted mails.

*** 3. spam that closes/mangles bugs, eek:

There's an additional issue of control messages in the debbugs case 
(i.e. spammers were closing emacs bugs) - was that resolved?  requiring 
gpg signed control messages seems a fairly obvious solution there, at 
least if emacs devs are willing to gpg sign control messages. Which is a 
one-click-or-less op in modern muas. Chances of spammers bothering to 
gpg-sign mails are slim. I guess they'll eventually start doing so (most 
likely using victim's gpg keys and keylogged passphrases found from 
infiltrated hosts), but then you just limit to good gpg identities.

Re: Spam in the bug tracker

[Richard M Stallman]

    Would it be possible to limit the bug tracker to mailing list
    subscribers?

No, that is self-defeating.  We need to encourage bug reports, not
put barriers in their way.

With all the meaningless messages that the bug tracker sends
to this list, it take a very strong interest in Emacs to convince
someone to be on this list.  Why haven't those messages
been diverted to another list?

Re: Spam in the bug tracker

[Agustin Martin]

2009/5/8 Stefan Monnier <monnier@iro.umontreal.ca>:
>>> Would it be possible to limit the bug tracker to mailing list
>>> subscribers? One can turn off receiving the list email in mailman, so
>>> it shouldn't be too much to ask for of users to subscribe. They don't
>>> need to get all that mail in their inboxes if they don't want to. Or
>>> would this requirement be a problem for report-emacs-bug?
>> Yes, it would be a problem for report-emacs-bug. We need to come up
>> with a way to get rid of the spam before it hits the tracker without
>> causing anyone too much work.
>
> The solution is known, stop looking for it: the bug-reporting address
> needs to be moderated.  As for the problem, it is that we have very
> little control over emacsbugs.donarmstrong.com and over the email
> processing at gnu.org, so any solution we come up with will currently
> not be applicable.

In the Debian bug tracker, a new message needs to have a special
pseudo-header to open a bug report. It would be good If only messages
sent to report-emacs-bug starting with something like

Package: emacs

automatically start a new bug report. This seems currently disabled.

A similar pseudo-header may also be required for a message be
automatically accepted when sent to the bug address or close a bug
report (Note that this is currently not done in Debian).

Everything else could go through moderation, if there is enough people
to handle it and the bug tracker allows that.

Re: Spam in the bug tracker

[Stefan Monnier]

> In the Debian bug tracker, a new message needs to have a special
> pseudo-header to open a bug report. It would be good If only messages
> sent to report-emacs-bug starting with something like

The main spam problem in the bugtracker is not the creation of new bugs,
but spam sent to existing bugs.


        Stefan