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:
+# Slightly less nonsensical,
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 os...@debian.org 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
Osamu Aoki os...@debian.org 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
(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
