Bug#766670: Security fix without feature enhancement for 4.32.0 and 4.20.0
On Sat, 22 Nov 2014, Charles Cazabon wrote: > I hope Debian can simply accept the newer version of getmail; as I said, I try The "next stable" version of Debian (aka "jessie") has getmail 4.46.0. We also have an official backports archive, and it will also have getmail 4.46.0 in a few days. This won't automatically update any of the users of current Debian stable (aka "wheezy") to 4.46.0, but they can manually do so if they so wish. However, to get current Debian stable (wheezy) users automatically updated to 4.46.0, we need a so called stable-update. This needs an OK from the stable release managers, and the non-trivial changes from 4.32.0 to 4.46.0 are a problem. The key issue here is "risk of regression". I have not seen any regressions, and I have been using a 4.46.0 backport for a while already, but we need to convince the stable release manager that the benefits of going from 4.32.0 to 4.46.0 are worth the risk of regression, and that these risks are low. For the record, attached is an unified diff with the relevant (i.e. excluding documentation) changes between 4.32.0 and 4.46.0. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh diff -ru getmail-4.32.0/docs/CHANGELOG getmail-4.46.0/docs/CHANGELOG diff -ru getmail-4.32.0/docs/configuration.html getmail-4.46.0/docs/configuration.html diff -ru getmail-4.32.0/docs/configuration.txt getmail-4.46.0/docs/configuration.txt diff -ru getmail-4.32.0/docs/documentation.txt getmail-4.46.0/docs/documentation.txt diff -ru getmail-4.32.0/docs/faq.html getmail-4.46.0/docs/faq.html diff -ru getmail-4.32.0/docs/faq.txt getmail-4.46.0/docs/faq.txt diff -ru getmail-4.32.0/docs/getmail.1 getmail-4.46.0/docs/getmail.1 diff -ru getmail-4.32.0/docs/troubleshooting.txt getmail-4.46.0/docs/troubleshooting.txt diff -ru getmail-4.32.0/getmail getmail-4.46.0/getmail --- getmail-4.32.0/getmail 2012-06-20 00:44:15.0 -0300 +++ getmail-4.46.0/getmail 2014-04-07 00:24:46.0 -0300 @@ -14,6 +14,18 @@ import pprint from optparse import OptionParser, OptionGroup import socket +import signal + +# Optional gnome-keyring integration +try: +import gnomekeyring +import glib +glib.set_application_name('getmail') +# And test to see if it's actually available +if not gnomekeyring.is_available(): +gnomekeyring = None +except ImportError: +gnomekeyring = None options_bool = ( 'read_all', @@ -22,9 +34,11 @@ 'received', 'message_log_verbose', 'message_log_syslog', +'fingerprint', ) options_int = ( 'delete_after', +'delete_bigger_than', 'max_message_size', 'max_messages_per_session', 'max_bytes_per_session', @@ -45,7 +59,7 @@ logging from getmailcore.exceptions import * from getmailcore.utilities import eval_bool, logfile, format_params, \ -address_no_brackets, expand_user_vars +address_no_brackets, expand_user_vars, get_password except ImportError, o: sys.stderr.write('ImportError: %s\n' % o) sys.exit(127) @@ -62,6 +76,7 @@ 'read_all' : True, 'delete' : False, 'delete_after' : 0, +'delete_bigger_than' : 0, 'max_message_size' : 0, 'max_messages_per_session' : 0, 'max_bytes_per_session' : 0, @@ -71,8 +86,21 @@ 'message_log_verbose' : False, 'message_log_syslog' : False, 'logfile' : None, +'fingerprint' : False, } + + + +### +def convert_to_sigint(unused1, unused2): +"""Catch a SIGTERM and raise a SIGINT so getmail exits normally and does +cleanup if killed with default signal. +""" +raise KeyboardInterrupt('from signal') + +signal.signal(signal.SIGTERM, convert_to_sigint) + ### def blurb(): log.info('getmail version %s\n' % __version__) @@ -80,7 +108,7 @@ 'GNU GPL version 2.\n') ### -def go(configs): +def go(configs, idle): """Main code. Returns True if all goes well, False if any error condition occurs. @@ -88,7 +116,27 @@ blurb() summary = [] errorexit = False +idling = False + +if len(configs) > 1 and idle: +log.info('more than one config file given with --idle, ignoring\n') +idle = False + for (configfile, retriever, _filters, destination, options) in configs: +if options['read_all'] and not options['delete']: +if idle: +# This is a nonsense combination of options; every time the +# server returns from IDLE, all messages will be re-retrieved. +log.error('%s: IDLE, read_all, and not delete - bad ' + 'combination, skipping\n' + % retriever) +continue +else: +# Slight
Bug#766670: Security fix without feature enhancement for 4.32.0 and 4.20.0
Osamu Aoki wrote: > On Sat, Nov 22, 2014 at 01:30:41PM -0600, Charles Cazabon wrote: > > > > As Linus Torvalds says, there's no real difference between "bugfix" and > > "security fix", and I would argue there's almost as little difference > > between "bugfix" and "new feature". > > If you added an unrelated HTTP-server feature to getmail for the remote > configuration, I call it a feature changes (, enhancement, bloat, or > ...). Yes. I note I should have been more specific with the above: I meant specifically in regards to getmail in its "mature" state, where pretty much the only changes going in are bugfixes and minor feature enhancements, which are difficult to distinguish between. > > I don't think you need to drop *anything*. getmail hasn't had much in > > the way of new features in many years, and I try to maintain > > compatibility as much as is practical. Just update to the latest > > version. > > Thank you. I hope Debian can simply accept the newer version of getmail; as I said, I try very hard to keep it compatible when things like the additional SSL certificate options were added, and getmail v.4 by itself is more than ten years old at this point, long into its quiescent "adult" period as far as software goes ;) Charles -- --- Charles Cazabon GPL'ed software available at: http://pyropus.ca/software/ --- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#766670: Security fix without feature enhancement for 4.32.0 and 4.20.0
Hi, Thanks for your comment. (Charles is the upstream,) On Sat, Nov 22, 2014 at 01:30:41PM -0600, Charles Cazabon wrote: > Osamu Aoki wrote: > > > > In Debian, its security update policy prohibits any new feature added > > with security updates. > > It's kind of a bogus distinction. As Linus Torvalds says, there's no real > difference between "bugfix" and "security fix", and I would argue there's > almost as little difference between "bugfix" and "new feature". If you added an unrelated HTTP-server feature to getmail for the remote configuration, I call it a feature changes (, enhancement, bloat, or ...). > > There are needs for updating 4.32.0 and 4.20.0 for the MITM security > > issues. > > CVE-2014-7273 > > CVE-2014-7274 > > CVE-2014-7275 > > The changes in getmail to allow it to perform server SSL certificate > validation and various other advanced SSL options: would you call > those a new feature? Because it clearly is. It is a boarder line case. > But on the other hand, some people consider the previous behavior a > bug, so perhaps its a bugfix. But others say it closes a security > hole, so it's a security fix. I forward your insightful argument to the Debian security team. > I see no way to make a clear-cut distinction between any of those three > possibilities. I concur. > > I for one as being its maintainer in Debian see it theoretically > > possible but am scared to make mistakes when dropping non-security fix > > changes. > > I don't think you need to drop *anything*. getmail hasn't had much in > the way of new features in many years, and I try to maintain > compatibility as much as is practical. Just update to the latest > version. Thank you. Osamu -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#766670: Security fix without feature enhancement for 4.32.0 and 4.20.0
(resent after subscribing with proper return path mail address) Hi, In Debian, its security update policy prohibits any new feature added with security updates. There are needs for updating 4.32.0 and 4.20.0 for the MITM security issues. CVE-2014-7273 CVE-2014-7274 CVE-2014-7275 I for one as being its maintainer in Debian see it theoretically possible but am scared to make mistakes when dropping non-security fix changes. https://bugs.debian.org/766670 Someone suggested "Maybe you can ask upstream if they are willing to point you the correct set of commits?". Can someone tell me such answer? I will be happy to get either "Yes" or "No" as the answer. Regards, Osamu -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#766670: Security fix without feature enhancement for 4.32.0 and 4.20.0
Hi, In Debian, its security update policy prohibits any new feature added with security updates. There are needs for updating 4.32.0 and 4.20.0 for the MITM security issues. CVE-2014-7273 CVE-2014-7274 CVE-2014-7275 I for one as being its maintainer in Debian see it possible but am scared to make mistakes when dropping non-security fix changes. https://bugs.debian.org/766670 Someone suggested "Maybe you can ask upstream if they are willing to point you the correct set of commits?". Can someone tell me such answer? I will be happy to get any "Yes" or "No" answer. Regards, Osamu -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org