Re: Reopening bug closed due to SPAM
Javier == Javier Fernández-Sanguino Peña [EMAIL PROTECTED] writes: Javier If spam e-mail is going to start closing our Bugs in the Javier BTS then we should start thinking about implementing Javier authentication checks in the BTS... like for example: do Javier not allow control messages or -close messages with no Javier attached (valid) GPG/PGP signatures (from a valid Javier developer?) Would a GPG signature help in the long run? The BTS closes bugs based on the address in the SMTP recipient field. This is not GPG protected. So a Spammer could copy an existing email from an existing developer from mailing list archives, forge his email address, and resend it. The signature remains valid, and the bug will still be closed. GPG signatures don't protect data that isn't protected (such as mail headers or SMTP session), and it doesn't protect against replay attacks (unless you add some other mechanism, e.g. include the date and time in the protected part of the message). -- Brian May [EMAIL PROTECTED]
Re: Reopening bug closed due to SPAM
Goswin von Brederlow escribió: Javier Fernández-Sanguino Peña [EMAIL PROTECTED] writes: If spam e-mail is going to start closing our Bugs in the BTS then we should start thinking about implementing authentication checks in the BTS... like for example: do not allow control messages or -close messages with no attached (valid) GPG/PGP signatures (from a valid developer?) NMs and most submitters aren't in the keyring so they would have a hard time managing bugs if a DD signature is required. The requirement for a valid signature might not be 'valid signature = DD signature' but something more liberal like 'valid signature = signature in the web of trust' (i.e. either a DD or signed by a DD) or even more liberal like 'valid signature = signature in known keyservers'. In the later, spammers could get keys generated and submitted there but they are not really targetting our BTS, it's backscatter from their spam tricks. And don't forget the DAK closing bugs on uploads. The archive key would have to be allowed to sign too. Or the BTS mail interface could approve messages coming in directly from the ftp-master system, in any case, adding the archive key would not be an issue, probably. I don't know if the BTS admins are going to go forward with any of these but IMHO it doesn't make any sense to allow administrative access (managing, retitling, tagging, etc.) to the BTS without any kind of authentication attempts (even if simple) of the end user when in most situations it's somebody the project knows about, not Random Joe. Maybe the BTS admins are tracking abuse somehow, I haven't digged into the BTS code at all but I do remember some abuse in the past and people being shunted off. However, with the current state of affairs, is there anything that prevents somebody from sending fake e-mails (maybe using relay proxies) to the BTS using random mail To's to (1-close to 319400-close _AT_ bugs.debian.org ? Just wondering... Regards Javier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Reopening bug closed due to SPAM
Javier Fernández-Sanguino Peña wrote: If spam e-mail is going to start closing our Bugs in the BTS then we should start thinking about implementing authentication checks in the BTS... like for example: do not allow control messages or -close messages with no attached (valid) GPG/PGP signatures (from a valid developer?) Spammers aren't targeting the BTS on purpose; they're doing it by mistake. We could just use something simple, like a phrase that must occur in the message for the BTS to act on the message sent to [EMAIL PROTECTED] This is also probably far more trivial to implement than GPG. And compatible with any mailer, unlike additional headers. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Reopening bug closed due to SPAM
Javier Fernández-Sanguino Peña [EMAIL PROTECTED] writes: reopen 209891 thanks If spam e-mail is going to start closing our Bugs in the BTS then we should start thinking about implementing authentication checks in the BTS... like for example: do not allow control messages or -close messages with no attached (valid) GPG/PGP signatures (from a valid developer?) Regards Javier NMs and most submitters aren't in the keyring so they would have a hard time managing bugs if a DD signature is required. And don't forget the DAK closing bugs on uploads. The archive key would have to be allowed to sign too. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Reopening bug closed due to SPAM
On 7/21/05, Javier Fernández-Sanguino Peña [EMAIL PROTECTED] wrote: If spam e-mail is going to start closing our Bugs in the BTS then we should start thinking about implementing authentication checks in the BTS... like for example: do not allow control messages or -close messages with no attached (valid) GPG/PGP signatures (from a valid developer?) As it was already requested, please don't make this a DD specific thing. GPG signing is not that bad, but making it DD specific is really a BAD thing. (keep in mind, there are non-DD maintainers, who wouldn't be able to close their own bugs!!) -- Besos, Marga
Re: Reopening bug closed due to SPAM
* Javier Fernández-Sanguino Peña [Thu, 21 Jul 2005 00:31:48 +0200]: If spam e-mail is going to start closing our Bugs in the BTS then we should start thinking about implementing authentication checks in the BTS... like for example: do not allow control messages or -close messages with no attached (valid) GPG/PGP signatures (from a valid developer?) I see much more feasible to require a pseudo-header: less cumbersome, higher probability of getting implemented, and more in accordance with the philosophy of our BTS. And such header is now needed to make a versioned closes, so it doesn't sound too disruptive to require it for every mail to -done (at least the Source: one, Source-Version could be optional). Cheers, -- Adeodato Simó EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621 Hanlon's Razor: Never attribute to malice that which is adequately explained by stupidity. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Reopening bug closed due to SPAM
On Thu, Jul 21, 2005 at 12:31:48AM +0200, Javier Fernández-Sanguino Peña wrote: If spam e-mail is going to start closing our Bugs in the BTS then we Start? It used to happen a lot; it's much less common nowadays. -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Reopening bug closed due to SPAM
On Thu, Jul 21, 2005 at 11:36:15AM +0200, Adeodato Simó wrote: And such header is now needed to make a versioned closes, so it doesn't sound too disruptive to require it for every mail to -done (at least the Source: one, Source-Version could be optional). It's possible this may happen in the future, but I don't want to do it immediately; such changes are better made gradually so that people don't have to get used to too many new things at once. -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Reopening bug closed due to SPAM
On 21/07/05, Adeodato Simó [EMAIL PROTECTED] wrote: * Javier Fernández-Sanguino Peña [Thu, 21 Jul 2005 00:31:48 +0200]: If spam e-mail is going to start closing our Bugs in the BTS then we should start thinking about implementing authentication checks in the BTS... like for example: do not allow control messages or -close messages with no attached (valid) GPG/PGP signatures (from a valid developer?) I see much more feasible to require a pseudo-header: less cumbersome, higher probability of getting implemented, and more in accordance with the philosophy of our BTS. And such header is now needed to make a versioned closes, so it doesn't sound too disruptive to require it for every mail to -done (at least the Source: one, Source-Version could be optional). And how about a nice header for -done which is something to the effect of 'mark as spam archive now prevent replies etc unless reopened', or let us tag bugs as 'spam' (which would also be an alias for close) and on the bug summary pages instead of all the spam bugs on package pages (mainly 'general' i'd say) it'd appear in it's own little section, and can autoarchive in 28 days without mixing with other bugs... My two cents Cheers, -- Adeodato Simó EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621 Hanlon's Razor: Never attribute to malice that which is adequately explained by stupidity. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- N Jones Blogging @ http://nigelj.blogspot.com Proud Debian FOSS User Debian Maintainer of: html2ps ipkungfu
Re: Reopening bug closed due to SPAM
On Thu, Jul 21, 2005 at 11:16:45PM +1200, Nigel Jones wrote: And how about a nice header for -done which is something to the effect of 'mark as spam archive now prevent replies etc unless reopened', I think that's far more prone to abuse than spams closing bugs. Archiving is deliberately irreversible except by [EMAIL PROTECTED], so it should not be so easy to cause immediate archiving. -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Reopening bug closed due to SPAM
attached (valid) GPG/PGP signatures (from a valid developer?) -- valid GPG signature present on public servers, not necessarily from a valid DD seems to be a valid scheme. I haven't seen any spam GPG signed yet -- another idea would be to use the same authentication as used by most of the mailing list servers -- verification of intent: confirmation email sent to the originating email address and reply to it keeping subject with a key code intact would verify that it was a valid request. Otherwise original request expires in a day or two if it doesn't get confirmed. Then anyone who wants automate this process writes a 2 liner procmail rule ;-) My 2 kopeyki (ie cents) -- .-. =-- /v\ = Keep in touch// \\ (yoh@|www.)onerussian.com Yaroslav Halchenko /( )\ ICQ#: 60653192 Linux User^^-^^[17] pgpP61H8uv0XZ.pgp Description: PGP signature
Re: Reopening bug closed due to SPAM
Le Jeu 21 Juillet 2005 15:22, Yaroslav Halchenko a écrit : attached (valid) GPG/PGP signatures (from a valid developer?) -- valid GPG signature present on public servers, not necessarily from a valid DD seems to be a valid scheme. I haven't seen any spam GPG signed yet that sucks, I want to be able to close bugs, even if I'm using a M$ computer with no gpg plugin on it (on from an unsecure machine where I don't want to unlock my gpg key). -- another idea would be to use the same authentication as used by most of the mailing list servers -- verification of intent: confirmation email sent to the originating email address and reply to it keeping subject with a key code intact would verify that it was a valid request. Otherwise original request expires in a day or two if it doesn't get confirmed. Then anyone who wants automate this process writes a 2 liner procmail rule ;-) that's way better. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpJk6OcNgxkb.pgp Description: PGP signature
Re: Reopening bug closed due to SPAM
On Thu, Jul 21, 2005 at 03:34:43PM +0200, Pierre Habouzit wrote: that sucks, I want to be able to close bugs, even if I'm using a M$ computer with no gpg plugin on it (on from an unsecure machine where I don't want to unlock my gpg key). Well - we need to give up something so it becomes 1 click harder for the spammers ;-) indeed it would make it tricky to close bugs while working from cell phones, some pdas, wrist watchers and kitchen sinks. As for M$ Windows, for any kinds of emails really a nice solution is Thunderbird+Enigmamail+keys on a USB flash drive (ie it can be your ipod or iriver) so you have all your privates with you at any moment ;-) not that I'm forcing you to accept it in any way -- I'm just giving an alternative solution ;-) -- .-. =-- /v\ = Keep in touch// \\ (yoh@|www.)onerussian.com Yaroslav Halchenko /( )\ ICQ#: 60653192 Linux User^^-^^[17] pgpwCv8AYx16T.pgp Description: PGP signature
Re: Reopening bug closed due to SPAM
Thunderbird+Enigmamail+keys on a USB flash drive (ie it can be your ipod just a link FYI http://dev.weavervsworld.com/projects/ptbirdeniggpg/ -- .-. =-- /v\ = Keep in touch// \\ (yoh@|www.)onerussian.com Yaroslav Halchenko /( )\ ICQ#: 60653192 Linux User^^-^^[17] pgpkseH5iT4Ul.pgp Description: PGP signature
Re: Reopening bug closed due to SPAM
On Thu, 21 Jul 2005, Yaroslav Halchenko wrote: On Thu, Jul 21, 2005 at 03:34:43PM +0200, Pierre Habouzit wrote: that sucks, I want to be able to close bugs, even if I'm using a M$ computer with no gpg plugin on it (on from an unsecure machine where I don't want to unlock my gpg key). Well - we need to give up something so it becomes 1 click harder for the spammers ;-) [...] The only reason it is easy for spammers to close a bug is that the bug has been already closed before (and reopened again) and the spammers have harvested the -done address for that bug from the web pages. So if the BTS people decided to make it more difficult to close a bug, it would be more than enough to make it just minimally more difficult, for example, require that the address is [EMAIL PROTECTED] or -done2 for the second time a bug is closed (instead of the usual -done), and so on. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Reopening bug closed due to SPAM
On Thu, Jul 21, 2005 at 09:22:10AM -0400, Yaroslav Halchenko wrote: -- another idea would be to use the same authentication as used by most of the mailing list servers -- verification of intent: confirmation email sent to the originating email address and reply to it keeping A slightly better modification of this scheme I think would be taken from some FIDONet newsgroups -- to verify sender's email address. so algorithm is check sender in DB and get his Keyword from DB if it is there if sender is not in DB then add email to DB, generate Keyword fi if email includes Keyword anywhere (X-Keyword field in the header or just a line in the body) then strip the lines containing keyword and post email else send a verification email to the sender where provide his Keywords for future postings fi this way it is one time job for anyone to adjust their .muttrc or whatever to include X-Keyword header in their emails to *debian.org -- .-. =-- /v\ = Keep in touch// \\ (yoh@|www.)onerussian.com Yaroslav Halchenko /( )\ ICQ#: 60653192 Linux User^^-^^[17] pgp2cutljQHuD.pgp Description: PGP signature
Re: Reopening bug closed due to SPAM
The only reason it is easy for spammers to close a bug is that the bug has been already closed before (and reopened again) and the spammers have harvested the -done address for that bug from the web pages. A very valid point... I took the task more general - to infiltrate bug reports (and may be give ideas for even mailing lists) from SPAM. crawlers get all [EMAIL PROTECTED] emails and then bug reports get spammed as well as the relevant dudes. BTW - why it has to be iff scheme - why it can't be a pipeline if signed with a valid GPG signature -- permit else if spamassassin gives negative score -- permit else send a verification letter Indeed - it is more load on the server but 1st step doesn't require much of load, mostly waiting time for the transaction. We would get to spamassassin quite rarely if most of people (and DD) start signing their submissions, and 3rd one will hit with probably 1% false positives... -- .-. =-- /v\ = Keep in touch// \\ (yoh@|www.)onerussian.com Yaroslav Halchenko /( )\ ICQ#: 60653192 Linux User^^-^^[17] pgpZ8cjo4aJDv.pgp Description: PGP signature
Re: Re: Reopening bug closed due to SPAM
On Thu, Jul 21, 2005 at 12:31:48AM +0200, Javier Fernández-Sanguino Peña wrote: If spam e-mail is going to start closing our Bugs in the BTS then we Start? It used to happen a lot; it's much less common nowadays. Well, it's the first time I've seen spam closing one bug reported by me. I often see spam to [EMAIL PROTECTED] addresses, however [1]. irony mode one I wonder if we can get spammers to add *debian* to the blacklist of keywords _not_ to spam, just like they currently do with *postmaster*, *abuse*, *spam* and, even, *linux* (ever seen a spammer bot? scary stuff) /irony mode off Regards Javier [1] Too much, in fact, for me to dedicate enough time to report it, counting 409 distinct mails since I implemented the filter a year ago. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Reopening bug closed due to SPAM
On Thu, Jul 21, 2005 at 11:25:09AM -0400, Yaroslav Halchenko wrote: The only reason it is easy for spammers to close a bug is that the bug has been already closed before (and reopened again) and the spammers have harvested the -done address for that bug from the web pages. A very valid point... I took the task more general - to infiltrate bug reports (and may be give ideas for even mailing lists) from SPAM. crawlers get all [EMAIL PROTECTED] emails and then bug reports get spammed as well as the relevant dudes. BTW - why it has to be iff scheme - why it can't be a pipeline if signed with a valid GPG signature -- permit else if spamassassin gives negative score -- permit else send a verification letter Indeed - it is more load on the server but 1st step doesn't require much of load, mostly waiting time for the transaction. We would get to spamassassin quite rarely if most of people (and DD) start signing their submissions, and 3rd one will hit with probably 1% false positives... Sending verification letters like that is a rather bad idea. We're talking in the 10,000 to 100,000 verification emails a day here. Pasc -- Pascal Hakim 0403 411 672 Do Not Bend signature.asc Description: Digital signature
Reopening bug closed due to SPAM
reopen 209891 thanks If spam e-mail is going to start closing our Bugs in the BTS then we should start thinking about implementing authentication checks in the BTS... like for example: do not allow control messages or -close messages with no attached (valid) GPG/PGP signatures (from a valid developer?) Regards Javier signature.asc Description: Digital signature
Re: Reopening bug closed due to SPAM
On Wednesday 20 July 2005 06:31 pm, Javier Fernández-Sanguino Peña wrote: reopen 209891 thanks If spam e-mail is going to start closing our Bugs in the BTS then we should start thinking about implementing authentication checks in the BTS... like for example: do not allow control messages or -close messages with no attached (valid) GPG/PGP signatures (from a valid developer?) I request that you not require the signature to belong to a DD. I have done a fair amount of bug triage, including merging, retitling, and even closing for both Qt and KDE with the permission of the respective maintainers, and would not have been able to help out in those ways if I needed to be a DD to do so. I think we should also make sure the submitter can close a bug if he realizes it is invalid. It seems the only way a spam is likely to close a bug is by going to [EMAIL PROTECTED] I doubt that [EMAIL PROTECTED] is very vulnerable to spam. Josh
