Re: Problems after sendmail security upgrade
* Stephen Gran [Fri, 24 Mar 2006 18:45:52 +]: This one time, at band camp, Emmanuel Halbwachs said: /etc/cron.d/sendmail has been tailored to our needs and has been reverted to a standard Debian one by the upgrade. Very sorry for the noise and thanks for your collaboration. A file in /etc that was overwritten silently is a bug. Please file one with the bug tracking system if this is the case. But please make sure first you didn't actually answer Yes to dpkg asking whether to overwrite the file, and that you don't have --force-confnew or similar in /etc/dpkg/dpkg.cfg. Cheers, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Acaba de... Acaba de una vez... Acaba de una vez conmigo -- Astrud, Masaje -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: On Mozilla-* updates
* Thomas Bushnell BSG [Tue, 02 Aug 2005 16:07:08 -0700]: It would be very nice if Mozilla would publish to distributions like ours a description of the security problem, and then a separate patch for that specific problem. Publish to distributions is effectively the same as making it completely public, so they won't. See [1]. [1] http://lists.debian.org/debian-security/2005/08/msg00032.html -- Adeodato Simó EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621 A dream is an answer to a question that we don't know how to ask. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: On Mozilla-* updates
* Alexander Sack [Mon, 01 Aug 2005 13:25:42 +0200]: since you are a member of the mozilla security team, what are your experiences? Have you ever tried to work with them to improve their security process? What was the outcome? What were the problems? Assuming you meant s/mozilla/ubuntu/ above: http://lists.debian.org/debian-devel/2005/07/msg01586.html http://lists.debian.org/debian-devel/2005/08/msg00012.html -- Adeodato Simó EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621 The Wright Brothers weren't the first to fly. They were just the first not to crash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#278518: KDE 3.2.2 (sarge) Konqueror suffers XSS vuln.
* Yanosz [Wed, 27 Oct 2004 15:45:21 +0200]: Package: Konqueror Version: 3.2.2-1 (sarge) Severity: Important In contrast to other browsers like firefox, Konqueror allows JavaScript to access other frames in a frameset, loaded with from different (sub)domain. By that enclosed / secret data can be read through a hidden frameset. See http://groenndemon.de/bla for demonstration. please see http://bugs.debian.org/261740. version 3.2.3-1.sarge.1 (available in testing-proposed-updates) fixed the vulnerability and will be included in sarge. you can use this version by adding this line to your sources.list: deb http://your.mirror.debian.org/debian sarge-proposed-updates main thanks, -- Adeodato Simó EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621 If there is a sin against life, it consists perhaps not so much in despairing of life as in hoping for another life and in eluding the implacable grandeur of this life. -- Albert Camus -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
challenge-response antispam systems in the BTS (was Re: Spam fights)
[this is offtopic here, but since the issue was raised on d-security, I thought I'd follow up there and move to d-devel if it's worth a discussion.] * Dmitry Golubev [Thu, 10 Jun 2004 12:27:04 +0300]: On Thursday 10 June 2004 11:58, Russell Coker [EMAIL PROTECTED] wrote: On Thu, 10 Jun 2004 18:21, Jaroslaw Tabor [EMAIL PROTECTED] wrote: For unknown sender, automated confirmation request is send. If My response to these scumbags who send me the confirmation messages is that if they are on a mailing list I'm on then I black-list their email address if it's known (or their mail server if their email address is not clear). If a confirmation message appears to be in response to a virus then I respond to it. Let the scumbag get another copy of the virus... I'm planning to develop this feauture, but It will be nice to hear from what you thing about this idea. Don't do it. Confirmation systems are just as bad as the problems that they try to solve. I second that. If I receive a confirmation message I never respond to it! (well, when I first received such a message, I wanted to try how it works - that was the only confirmation I responded to). Maybe that's impolite, but I do not want to waste my time answering to that spam. has it been discussed before the usage of such systems by bug submitters? I've come up with this situation twice or so, and I found myself thinking what the hell, they're putting extra work on *anybody* wanting to help with *their* problem! so, do you think an address with such system qualifies as non-valid for the BTS? for me, I guess, it's pretty as if they had posted with [EMAIL PROTECTED] in the From: line. OTOH, if all mail to the submitter was sent to [EMAIL PROTECTED], the user could whitelist [EMAIL PROTECTED], but this is not common practice ATM and would also prevent us from stating our dislike for such systems. any thoguths? -- Adeodato Simó EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621 As an adolescent I aspired to lasting fame, I craved factual certainty, and I thirsted for a meaningful vision of human life -- so I became a scientist. This is like becoming an archbishop so you can meet girls. -- Matt Cartmill -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
challenge-response antispam systems in the BTS (was Re: Spam fights)
[this is offtopic here, but since the issue was raised on d-security, I thought I'd follow up there and move to d-devel if it's worth a discussion.] * Dmitry Golubev [Thu, 10 Jun 2004 12:27:04 +0300]: On Thursday 10 June 2004 11:58, Russell Coker [EMAIL PROTECTED] wrote: On Thu, 10 Jun 2004 18:21, Jaroslaw Tabor [EMAIL PROTECTED] wrote: For unknown sender, automated confirmation request is send. If My response to these scumbags who send me the confirmation messages is that if they are on a mailing list I'm on then I black-list their email address if it's known (or their mail server if their email address is not clear). If a confirmation message appears to be in response to a virus then I respond to it. Let the scumbag get another copy of the virus... I'm planning to develop this feauture, but It will be nice to hear from what you thing about this idea. Don't do it. Confirmation systems are just as bad as the problems that they try to solve. I second that. If I receive a confirmation message I never respond to it! (well, when I first received such a message, I wanted to try how it works - that was the only confirmation I responded to). Maybe that's impolite, but I do not want to waste my time answering to that spam. has it been discussed before the usage of such systems by bug submitters? I've come up with this situation twice or so, and I found myself thinking what the hell, they're putting extra work on *anybody* wanting to help with *their* problem! so, do you think an address with such system qualifies as non-valid for the BTS? for me, I guess, it's pretty as if they had posted with [EMAIL PROTECTED] in the From: line. OTOH, if all mail to the submitter was sent to [EMAIL PROTECTED], the user could whitelist [EMAIL PROTECTED], but this is not common practice ATM and would also prevent us from stating our dislike for such systems. any thoguths? -- Adeodato Simó EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621 As an adolescent I aspired to lasting fame, I craved factual certainty, and I thirsted for a meaningful vision of human life -- so I became a scientist. This is like becoming an archbishop so you can meet girls. -- Matt Cartmill
Re: Mail processing tool
* Rick Moen [Sun, 25 Jan 2004 17:41:11 -0800]: Fetchmail's a useful tool, but it does require running a local MTA as an inherent part of its design. (It does that instead of, itself, having code to support mail stores.) $ apt-cache show fetchmail | grep -i suggests $ man fetchmail /--mda Am I missing something? -- Adeodato Simó (a.k.a. thibaut) EM: asp16 [ykwim] alu.ua.es | IM: my_dato [jabber.org] | PK: DA6AE621 Old men are fond of giving good advice to console themselves for their inability to set a bad example. -- La Rochefoucauld, Maxims signature.asc Description: Digital signature
Re: Mail processing tool
* Rick Moen [Sun, 25 Jan 2004 17:53:58 -0800]: Quoting Adeodato Simó ([EMAIL PROTECTED]): Am I missing something? http://www.catb.org/~esr/fetchmail/ includes: Fetchmail retrieves mail from remote mail servers and forwards it via SMTP fetchmail(1) includes: -m command | --mda command (Keyword: mda) You can force mail to be passed to an MDA directly (rather than forwarded to port 25) with the --mda or -m option. To avoid losing mail, use this option only with MDAs like procmail or sendmail that return a nonzero status on disk- full and other resource-exhaustion errors; the nonzero status tells fetchmail that delivery failed and prevents the message from being deleted off the server. -- Adeodato Simó (a.k.a. thibaut) EM: asp16 [ykwim] alu.ua.es | IM: my_dato [jabber.org] | PK: DA6AE621 Man is certainly stark mad; he cannot make a flea, yet he makes gods by the dozens. -- Michel de Montaigne signature.asc Description: Digital signature
Re: Mail processing tool
* Rick Moen [Sun, 25 Jan 2004 17:53:58 -0800]: Quoting Adeodato Simó ([EMAIL PROTECTED]): Am I missing something? http://www.catb.org/~esr/fetchmail/ includes: Fetchmail retrieves mail from remote mail servers and forwards it via SMTP fetchmail(1) includes: -m command | --mda command (Keyword: mda) You can force mail to be passed to an MDA directly (rather than forwarded to port 25) with the --mda or -m option. To avoid losing mail, use this option only with MDAs like procmail or sendmail that return a nonzero status on disk- full and other resource-exhaustion errors; the nonzero status tells fetchmail that delivery failed and prevents the message from being deleted off the server. -- Adeodato Simó (a.k.a. thibaut) EM: asp16 [ykwim] alu.ua.es | IM: my_dato [jabber.org] | PK: DA6AE621 Man is certainly stark mad; he cannot make a flea, yet he makes gods by the dozens. -- Michel de Montaigne signature.asc Description: Digital signature
Re: GnuPG can not read some pgp signatures
* LeVA [Wed, 07 Jan 2004 11:59:25 +0100]: Wednesday 07 January 2004 08:34 dátummal Adrian 'Dagurashibanipal' von Bidder ezt írta: Clinging to sanity, LeVA mumbled in his beard: Reason: No appropriate crypto plug-in was found. Hi, I guess that your problem is NOT idea, but inline gpg signed msgs (like this one) versus PGP/MIME signed messages. Not really. Your messages doesn't produce that No appropriate crypto plug-in was found. message. For your mail, KMail says this: It is that, *indeed*. But the other way round: inline gpg signed msgs do not cause trouble to KMail, but PGP/MIME ones (like *this* one) do. If I'm correct, you should just have seen: The message is signed, but the validity of the signature can't be verified. Reason: No appropriate crypto plug-in was found. Any idea? Yep, the KMail PGP/MIME Howto which Adrian already pointed you to: [1] http://kmail.kde.org/kmail-pgpmime-howto.html -- Adeodato Simó (a.k.a. thibaut) EM: asp16 [ykwim] alu.ua.es | IM: my_dato [jabber.org] | PK: DA6AE621 When all is summed up, a man never speaks of himself without loss; his accusations of himself are always believed; his praises never. -- Michel de Montaigne signature.asc Description: Digital signature
Re: Content-Type in DSAs
* Lupe Christoph [Tue, 06 Jan 2004 11:25:27 +0100]: When I recently read about problems with verifying the PGP signature of DSAs, I realized that for most DSAs mutt does not automatically check the signature. Comparing the DSAs and reading how mutt recognizes a PGP signed message, I found that only some DSAs from Martin Schulze have a Content-Type as mutt wants it: Content-Type: application/pgp; format=text; x-action=sign I think this format is obsolete. A correct PGP/MIME message would read something similar to (correct me if I'm wrong): Content-Type: multipart/signed; micalg=pgp-sha1; protocol=application/pgp-signature; boundary=tKW2IUtsqtDRztdT Newer ones from him and all others have this: Content-Type: text/plain; charset=us-ascii Mutt *can* varify these, but only when told with (default) ESC P. And this does not change the message, mutt will loose the info when it leaves the mailbox. Yes, I know about the procmail hack. And I will set it up now. But for the sake of people like me before I started to investigate this, I still wanted to ask this question. I know about the procmail hack too, and it miserably fails when the message is a multipart one. Of course the long term solution is to get everybody to use the new not-obsolete PGP/MIME format, but in the meanwhile I would recommend to mutt users to try this little mutt hook: message-hook '!(~g|~G) ~b^-BEGIN\ PGP\ (SIGNED\ )?MESSAGE' exec check-traditional-pgp Personally, I found it quite useful, as I've now completely forgotten about headaches brought by inline-signed mail. (The hook, oviously, simuates presssing ESC P *each* time the message is viewed.) HTH. -- Adeodato Simó (a.k.a. thibaut) EM: asp16 [ykwim] alu.ua.es | IM: my_dato [jabber.org] | PK: DA6AE621 If there is a sin against life, it consists perhaps not so much in despairing of life as in hoping for another life and in eluding the implacable grandeur of this life. -- Albert Camus signature.asc Description: Digital signature
Re: Content-Type in DSAs
* Lupe Christoph [Tue, 06 Jan 2004 11:25:27 +0100]: When I recently read about problems with verifying the PGP signature of DSAs, I realized that for most DSAs mutt does not automatically check the signature. Comparing the DSAs and reading how mutt recognizes a PGP signed message, I found that only some DSAs from Martin Schulze have a Content-Type as mutt wants it: Content-Type: application/pgp; format=text; x-action=sign I think this format is obsolete. A correct PGP/MIME message would read something similar to (correct me if I'm wrong): Content-Type: multipart/signed; micalg=pgp-sha1; protocol=application/pgp-signature; boundary=tKW2IUtsqtDRztdT Newer ones from him and all others have this: Content-Type: text/plain; charset=us-ascii Mutt *can* varify these, but only when told with (default) ESC P. And this does not change the message, mutt will loose the info when it leaves the mailbox. Yes, I know about the procmail hack. And I will set it up now. But for the sake of people like me before I started to investigate this, I still wanted to ask this question. I know about the procmail hack too, and it miserably fails when the message is a multipart one. Of course the long term solution is to get everybody to use the new not-obsolete PGP/MIME format, but in the meanwhile I would recommend to mutt users to try this little mutt hook: message-hook '!(~g|~G) ~b^-BEGIN\ PGP\ (SIGNED\ )?MESSAGE' exec check-traditional-pgp Personally, I found it quite useful, as I've now completely forgotten about headaches brought by inline-signed mail. (The hook, oviously, simuates presssing ESC P *each* time the message is viewed.) HTH. -- Adeodato Simó (a.k.a. thibaut) EM: asp16 [ykwim] alu.ua.es | IM: my_dato [jabber.org] | PK: DA6AE621 If there is a sin against life, it consists perhaps not so much in despairing of life as in hoping for another life and in eluding the implacable grandeur of this life. -- Albert Camus signature.asc Description: Digital signature
Re: 2.4.18-bf2.4 version confusion, patches?
* kuene [Sun, 04 Jan 2004 16:52:18 +0100]: hi thank you very much. this clears things for me. :) I think it just obscured them a little too much. I'll try to clean up the mess, hope not to make another one ;-). [Please somebody correct me if I'm wrong about something.] summary: in debian stable every package with security holes is patched. yep only the kernel images are not pachted. so the kernel image packages are the only packages with security holes in it. even if you run debian-stable. is this right? No. What never gets updated is the kernel you get from installation. Kernel-images (of which there are a lot in the archive) get fixed if there are any security holes. this sound quite strange to me. :o Because it's simply not true. however it is always best to compile your own kernel imediately after installation. It is always best to *change* the kernel after installation, i.e., substitute the one-fits-all 2.4.18-bf24 by antother one which fits your processor, etc, e.g. 2.4.xx-k7. That can be accomplished by compiling your own kernel OR by installing one of the many kernel-images available in the archive. I've heard (but not 100 %) that sarge will install a kernel-package after installation. -- Adeodato Simó (a.k.a. thibaut) EM: asp16 [ykwim] alu.ua.es | IM: my_dato [jabber.org] | PK: DA6AE621 The reader this message encounters not failing to understand is cursed. signature.asc Description: Digital signature
Re: 2.4.18-bf2.4 version confusion, patches?
* kuene [Sun, 04 Jan 2004 16:52:18 +0100]: hi thank you very much. this clears things for me. :) I think it just obscured them a little too much. I'll try to clean up the mess, hope not to make another one ;-). [Please somebody correct me if I'm wrong about something.] summary: in debian stable every package with security holes is patched. yep only the kernel images are not pachted. so the kernel image packages are the only packages with security holes in it. even if you run debian-stable. is this right? No. What never gets updated is the kernel you get from installation. Kernel-images (of which there are a lot in the archive) get fixed if there are any security holes. this sound quite strange to me. :o Because it's simply not true. however it is always best to compile your own kernel imediately after installation. It is always best to *change* the kernel after installation, i.e., substitute the one-fits-all 2.4.18-bf24 by antother one which fits your processor, etc, e.g. 2.4.xx-k7. That can be accomplished by compiling your own kernel OR by installing one of the many kernel-images available in the archive. I've heard (but not 100 %) that sarge will install a kernel-package after installation. -- Adeodato Simó (a.k.a. thibaut) EM: asp16 [ykwim] alu.ua.es | IM: my_dato [jabber.org] | PK: DA6AE621 The reader this message encounters not failing to understand is cursed. signature.asc Description: Digital signature
Re: GnuPG mutt on Woody 3.0r2.
* s. keeling [Mon, 22 Dec 2003 23:52:30 -0700]: With help from one of the list recipients, this is now verified and reproducible. Something between me and those people whose keys are determined by my copy of gpg to be Bad signature, is mangling mail. Specifically, that something is fixing line breaks: - gpg: There is no indication that the signature belongs to the ow-ner. + gpg: There is no indication that the signature belongs to the owner. More exactly, that something is removing =\n sequences from Quoted-Printable encoded mails, so the diff would read: gpg: WARNING: This key is not certified with a trusted signature! - gpg: There is no indication that the signature belongs to the ow= -ner. + gpg: There is no indication that the signature belongs to the owner. Mail sent to me containing lines less than (ca.) eighty chars results in Good signature. Mail sent to me which includes lines longer than (ca.) eighty chars results in Bad signature. So, long lines remain long lines in the decoded message, but the Q-P codification gets mangled and modified messages no longer have 72-or-less-chars lines (and the signature fails, as it gets applied to the Q-P message rather than to the decoded message). Debian Woody 3.0r2 Mutt/1.3.28i Exim 3.35 #1 (Debian) GNU Emacs 20.7.2 GnuPG 1.0.6-4 Procmail v3.22 At this point, I just can figure out it *might* be a broken MTA as somebody else pointed out; but no more I can say... All this Q-P mangling must sound familiar to someone out there. Any hints? Cheers. -- Adeodato Simó (a.k.a. thibaut) EM: asp16 [ykwim] alu.ua.es | IM: my_dato [jabber.org] | PK: DA6AE621 Truth is the most valuable thing we have, so let's economize it. -- Mark Twain signature.asc Description: Digital signature
Re: GnuPG mutt on Woody 3.0r2.
* s. keeling [Mon, 22 Dec 2003 23:52:30 -0700]: With help from one of the list recipients, this is now verified and reproducible. Something between me and those people whose keys are determined by my copy of gpg to be Bad signature, is mangling mail. Specifically, that something is fixing line breaks: - gpg: There is no indication that the signature belongs to the ow-ner. + gpg: There is no indication that the signature belongs to the owner. More exactly, that something is removing =\n sequences from Quoted-Printable encoded mails, so the diff would read: gpg: WARNING: This key is not certified with a trusted signature! - gpg: There is no indication that the signature belongs to the ow= -ner. + gpg: There is no indication that the signature belongs to the owner. Mail sent to me containing lines less than (ca.) eighty chars results in Good signature. Mail sent to me which includes lines longer than (ca.) eighty chars results in Bad signature. So, long lines remain long lines in the decoded message, but the Q-P codification gets mangled and modified messages no longer have 72-or-less-chars lines (and the signature fails, as it gets applied to the Q-P message rather than to the decoded message). Debian Woody 3.0r2 Mutt/1.3.28i Exim 3.35 #1 (Debian) GNU Emacs 20.7.2 GnuPG 1.0.6-4 Procmail v3.22 At this point, I just can figure out it *might* be a broken MTA as somebody else pointed out; but no more I can say... All this Q-P mangling must sound familiar to someone out there. Any hints? Cheers. -- Adeodato Simó (a.k.a. thibaut) EM: asp16 [ykwim] alu.ua.es | IM: my_dato [jabber.org] | PK: DA6AE621 Truth is the most valuable thing we have, so let's economize it. -- Mark Twain signature.asc Description: Digital signature
