Bug#792639: apt-listbugs: should use https to access bug tracking system
On Wed, 02 Nov 2022 16:52:08 +0100 marc wrote: > Hello, OpenSSL 3.0.5 is in bookworm. Are there other blockers > to fix this issue? Hello Marc, thanks for your interest in apt-listbugs! Yes, there are some blockers, but I agree that the main one (OpenSSL licensing) is solved. The remaining blockers (apart from the need to get around to actually modify apt-listbugs and test the implementation: time has been scarce for me lately...) are: * sorting out the licensing of some indirect dependencies of apt-listbugs, which seem to include GPLv2-only parts (Apache v2.0 is GPLv3-compatible, but GPLv2-incompatible, hence, if apt-listbugs links with GPLv2-only libraries, it cannot use an Apache-v2.0-licensed OpenSSL) * figuring out how the (indirect) dependency on OpenSSL v3.0 or later may be expressed, since apt-listbugs does not currently depend on OpenSSL in an explicit way I am afraid I won't be able to work on this until after bookworm is out. Sorry about that. -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpgKbZMt0bxT.pgp Description: PGP signature
Bug#792639: apt-listbugs: should use https to access bug tracking system
Package: apt-listbugs Version: 0.1.35 Followup-For: Bug #792639 X-Debbugs-Cc: marc.noto.5...@gmail.com Hello, OpenSSL 3.0.5 is in bookworm. Are there other blockers to fix this issue?
Bug#792639: apt-listbugs: should use https to access bug tracking system
On Mon, 6 Mar 2017 00:48:11 +0100 Guilhem Moulin wrote: > First of, apologizes for opening duplicate #856844… I apparently > overlooked this one while browsing though the list of existing bug > reports :-/ No problem... > > On Thu, 30 Jul 2015 at 22:35:17 +0200, Francesco Poli wrote: > > Now, the bad news is that I remembered that the libruby module > > providing SSL support links with libssl. And the OpenSSL license is > > well known to be GPL-incompatible. [...] > > FYI a similar issue (dynamic linking against libssl in the context of > python-pypump) was brought up to debian-legal two years ago: > > https://lists.debian.org/debian-legal/2015/01/msg00020.html > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=740990 > https://github.com/xray7224/PyPump/issues/101 > > “OK. It can't hurt to try - this does seem like a special case.” The > FTP masters didn't reject the GPL-3+'ed (without OpenSSL exception) > code: > > https://tracker.debian.org/media/packages/p/python-pypump/copyright-0.7-1 I am not entirely sure I would be ready to agree with the outcome of the pypump case, but, anyway, the pypump case is not completely analogous to the apt-listbugs (with the https patch) case. As far as pypump is concerned: [...] | the linking is optional, and done by the python-requests library | instead of pypump [...] (quoted from https://bugs.debian.org/740990#65 ) On the other hand, the https patch for apt-listbugs would make the program explicitly default to connecting to an https URL: hence, it would explicitly use the OpenSSL library through the Ruby standard library. > > > An older thread on debian-python mentioning the same problem: > > https://lists.debian.org/debian-python/2011/03/msg00082.html > In my case I am talking about a GPLv3+ package that exists in Debian -- > kupfer > > Where do I draw the line for using/linking against ssl? > > a) Using Python2.6 > b) Unintentionally introducing _ssl or ssl into the imported modules >(import any of urllib, httplib, socket etc!) > c) Unintentionally using ssl (use urllib.urlopen on URL provided by >user -- if it's https we are using openssl) > d) Intentionally using ssl (import ssl and use >httplib.HTTPSConnection and verify certificates) > > Kupfer is today at (c) in the debian archive. It exists in > development version at (d). > > (AFAICT apt-listbugs would be at (b).) [...] I would rather say that the https patch would make apt-listbugs land in between (c) and (d): intentionally use ssl (connecting by default to an https URL). Anyway, please note that I am myself a debian-legal regular and I myself have analyzed the issue in the past: https://lists.debian.org/debian-legal/2011/05/msg00018.html My conclusion is that a Ruby program cannot load both openssl and GPL-licensed libraries, at least if we assume that the FSF's interpretation is correct (this assumption has to be made in order to be on the safe side). Bye. -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpzo3AwqHtQD.pgp Description: PGP signature
Bug#792639: apt-listbugs: should use https to access bug tracking system
First of, apologizes for opening duplicate #856844… I apparently overlooked this one while browsing though the list of existing bug reports :-/ On Thu, 30 Jul 2015 at 22:35:17 +0200, Francesco Poli wrote: > Now, the bad news is that I remembered that the libruby module > providing SSL support links with libssl. And the OpenSSL license is > well known to be GPL-incompatible. > apt-listbugs is GPL-licensed and loads a number of GPL-licensed Ruby > libraries: as a consequence, there may be license incompatibility > issues preventing the distribution of a version of apt-listbugs which > uses SSL. > This licensing issue needs to be carefully investigated. > I will try and see what can be done about it. > Sadly, I will have to put the patch aside, until this situation is > solved for the best. FYI a similar issue (dynamic linking against libssl in the context of python-pypump) was brought up to debian-legal two years ago: https://lists.debian.org/debian-legal/2015/01/msg00020.html https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=740990 https://github.com/xray7224/PyPump/issues/101 “OK. It can't hurt to try - this does seem like a special case.” The FTP masters didn't reject the GPL-3+'ed (without OpenSSL exception) code: https://tracker.debian.org/media/packages/p/python-pypump/copyright-0.7-1 An older thread on debian-python mentioning the same problem: https://lists.debian.org/debian-python/2011/03/msg00082.html In my case I am talking about a GPLv3+ package that exists in Debian -- kupfer Where do I draw the line for using/linking against ssl? a) Using Python2.6 b) Unintentionally introducing _ssl or ssl into the imported modules (import any of urllib, httplib, socket etc!) c) Unintentionally using ssl (use urllib.urlopen on URL provided by user -- if it's https we are using openssl) d) Intentionally using ssl (import ssl and use httplib.HTTPSConnection and verify certificates) Kupfer is today at (c) in the debian archive. It exists in development version at (d). (AFAICT apt-listbugs would be at (b).) The kupfer package is still in main, released under GPL-3+ (without OpenSSL exception): https://tracker.debian.org/media/packages/k/kupfer/copyright-0%2Bv208-6 -- Guilhem. signature.asc Description: PGP signature
Bug#792639: apt-listbugs: should use https to access bug tracking system
Control: tags -1 - patch On Mon, 20 Jul 2015 22:38:18 -0400 Michael Gold wrote: On Sun, Jul 19, 2015 at 15:58:47 +0200, Francesco Poli wrote: Thank you very much, your helpfulness is really appreciated! I am looking forward to seeing your updated patch. Please send it as soon as it's ready. Here it is. Hello Michael, I have some good news and some bad news for you. First of all, the good news. I have examined your second patch and I have made some modifications/simplifications to it. The main behavioral difference with respect to your patch is that I decided that all the command-line options are to be treated as equally important: any option specified later on the command line takes precedence over the ones specified earlier (hence --url will override --hostname/--port only when it follows them on the command line). After all, this is how all other command-line options work: specifying one option multiple times already causes the last specified value to overwrite the previously specified ones. For the record, the resulting revised patch is attached. Now, the bad news is that I remembered that the libruby module providing SSL support links with libssl. And the OpenSSL license is well known to be GPL-incompatible. apt-listbugs is GPL-licensed and loads a number of GPL-licensed Ruby libraries: as a consequence, there may be license incompatibility issues preventing the distribution of a version of apt-listbugs which uses SSL. This licensing issue needs to be carefully investigated. I will try and see what can be done about it. Sadly, I will have to put the patch aside, until this situation is solved for the best. Hence, don't count on seeing the patch accepted soon into apt-listbugs. I am really sorry about this! :-( -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE diff --git a/bin/apt-listbugs b/bin/apt-listbugs index 4c5628f..88efb4c 100755 --- a/bin/apt-listbugs +++ b/bin/apt-listbugs @@ -9,6 +9,7 @@ # Copyright (C) 2009 Ryan Niebur r...@debian.org # Copyright (C) 2012 Justin B Rye j...@edlug.org.uk # Copyright (C) 2013 Google Inc +# Copyright (C) 2015 Michael Gold mich...@bitplane.org # # This program is free software; you can redistribute it and/or modify # it under the terms of the GNU General Public License as published by @@ -46,7 +47,7 @@ installation/upgrade is safe. == USAGE -apt-listbugs [-h] [-v] [-s severities] [-T tags] [-S states] [-B bug#] [-D] [-H hostname] [-p port] [-P priority] [-E title] [-q] [-C apt.conf] [-F] [-y] [-n] [-d] command [arguments] +apt-listbugs [-h] [-v] [-s severities] [-T tags] [-S states] [-B bug#] [-D] [-u url] [-H hostname] [-p port] [-P priority] [-E title] [-q] [-C apt.conf] [-F] [-y] [-n] [-d] command [arguments] == OPTIONS @@ -104,14 +105,23 @@ apt-listbugs [-h] [-v] [-s severities] [-T tags] [-S states] [-B bug#] [ Show bugs of downgraded packages. (apt mode only) +* -u url, --url url + + Specifies the SOAP URL for the Debian Bug Tracking System. Default: + [https://bugs.debian.org:443/cgi-bin/soap.cgi]. The default URL may be + changed by setting the AptListbugs::URL configuration option. + * -H hostname, --hostname hostname - Specifies the hostname of the Debian Bug Tracking System [bugs.debian.org]. + Specifies the hostname of the Debian Bug Tracking System and causes http + to be used instead of https (DEPRECATED: use --url instead). Default: + [bugs.debian.org]. * -p port, --port port - Specifies the port number of the web interface of the Debian Bug - Tracking System [80]. + Specifies the port number of the SOAP interface of the Debian Bug + Tracking System and causes http to be used instead of https (DEPRECATED: + use --url instead). Default: [80]. * -P priority, --pin-priority priority @@ -229,6 +239,15 @@ notable configuration options are hand, when this option is set, the list of severities is its value, unless explicitly altered by using the -s command-line option. +: AptListbugs::URL + + Default SOAP URL for the Debian Bug Tracking System. When this option + is not set, the SOAP URL is [https://bugs.debian.org:443/cgi-bin/soap.cgi], + unless explicitly altered by using the -u command-line option (or the + deprecated -H/-p options). On the other hand, when this option is set, + the SOAP URL is its value, unless explicitly altered by using the -u + command-line option (or the deprecated -H/-p options). + : AptListbugs::IgnoreRegexp Bugs to ignore when in apt mode. This is evaluated using Ruby regular diff --git a/debian/changelog b/debian/changelog index 67005a8..feaa60f 100644 --- a/debian/changelog +++ b/debian/changelog @@ -25,6 +25,11 @@ apt-listbugs (0.1.17) UNRELEASED; urgency=medium tells apt-listbugs to pin a package, the user is asked for
Bug#792639: apt-listbugs: should use https to access bug tracking system
On Thu, Jul 30, 2015 at 22:35:17 +0200, Francesco Poli wrote: I have examined your second patch and I have made some modifications/simplifications to it. The main behavioral difference with respect to your patch is that I decided that all the command-line options are to be treated as equally important: any option specified later on the command line takes precedence over the ones specified earlier (hence --url will override --hostname/--port only when it follows them on the command line). After all, this is how all other command-line options work: specifying one option multiple times already causes the last specified value to overwrite the previously specified ones. For the record, the resulting revised patch is attached. I thought of this when developing the patch. The problem is that you'll override more than just the host or port unless you're careful. E.g., with -h foo -u https://192.0.2.1:999/bar.cgi -p 443 I think your code will produce http://foo:443/cgi-bin/soap.cgi;, while I'd expect a URL of https://192.0.2.1:443/bar.cgi;. Note also that removing -p will change the URL completely. I'm not too concerned though. Now, the bad news is that I remembered that the libruby module providing SSL support links with libssl. And the OpenSSL license is well known to be GPL-incompatible. apt-listbugs is GPL-licensed and loads a number of GPL-licensed Ruby libraries: as a consequence, there may be license incompatibility issues preventing the distribution of a version of apt-listbugs which uses SSL. This licensing issue needs to be carefully investigated. I will try and see what can be done about it. Sadly, I will have to put the patch aside, until this situation is solved for the best. This is kind of interesting--it's not clear who would be responsible if libssl got loaded. What if you merged the patch with a non-SSL default for soapurl? It might be useful for someone to override the cgi-bin/... part on a local server, and in terms of libssl it would look the same as before. If some user chose to add an s, would Debian be responsible? (If so, all users of this SOAP library would need to be audited.) Even if Debian added the s, would the shipped software be derived from libssl, or would the derived work exist purely in RAM without ever being distributed? It would surprise me if the the presence or absence of s in apt-listbugs determines whether it's derived from libssl. We're not using the libssl API, and the underlying libraries could swap it out for something else without us ever noticing. Anyway, I'll leave these things for you to investigate. Thanks for the update. -- Michael signature.asc Description: Digital signature
Bug#792639: apt-listbugs: should use https to access bug tracking system
On Sun, Jul 19, 2015 at 15:58:47 +0200, Francesco Poli wrote:
Thank you very much, your helpfulness is really appreciated!
I am looking forward to seeing your updated patch.
Please send it as soon as it's ready.
Here it is.
-- Michael
diff --git a/bin/apt-listbugs b/bin/apt-listbugs
index 4c5628f97c04..cf73e5de3242 100755
--- a/bin/apt-listbugs
+++ b/bin/apt-listbugs
@@ -46,7 +46,7 @@ installation/upgrade is safe.
== USAGE
-apt-listbugs [-h] [-v] [-s severities] [-T tags] [-S states] [-B bug#] [-D] [-H hostname] [-p port] [-P priority] [-E title] [-q] [-C apt.conf] [-F] [-y] [-n] [-d] command [arguments]
+apt-listbugs [-h] [-v] [-s severities] [-T tags] [-S states] [-B bug#] [-D] [-u url] [-P priority] [-E title] [-q] [-C apt.conf] [-F] [-y] [-n] [-d] command [arguments]
== OPTIONS
@@ -104,14 +104,21 @@ apt-listbugs [-h] [-v] [-s severities] [-T tags] [-S states] [-B bug#] [
Show bugs of downgraded packages. (apt mode only)
+* -u url, --url url
+
+ Specifies the SOAP URL for the Debian Bug Tracking System
+ [https://bugs.debian.org:443/cgi-bin/soap.cgi]. The default URL may be
+ changed by setting the AptListbugs::URL configuration option.
+
* -H hostname, --hostname hostname
- Specifies the hostname of the Debian Bug Tracking System [bugs.debian.org].
+ Specifies the hostname of the Debian Bug Tracking System
+ (deprecated, and disables https; use --url instead).
* -p port, --port port
Specifies the port number of the web interface of the Debian Bug
- Tracking System [80].
+ Tracking System (deprecated, and disables https; use --url instead).
* -P priority, --pin-priority priority
@@ -221,6 +228,10 @@ notable configuration options are
Useful for setting HTTP proxy for apt-listbugs.
The special keyword 'DIRECT' will disable proxy.
+: AptListbugs::URL
+
+ Default SOAP URL for the Debian Bug Tracking System.
+
: AptListbugs::Severities
Default (comma-separated) list of bug severities to be shown. When
diff --git a/lib/aptlistbugs/debian/bts.rb b/lib/aptlistbugs/debian/bts.rb
index 5b31d1bffb8f..3a310819cb46 100644
--- a/lib/aptlistbugs/debian/bts.rb
+++ b/lib/aptlistbugs/debian/bts.rb
@@ -31,23 +31,21 @@ module Debian
module BTS
class Parser
- def initialize(host, port)
-@host = host
-@port = port
+ def initialize(url)
+@soapurl = url
end
# use SOAP interface to obtain the index.
class SoapIndex Parser
-def initialize(host, port)
- @host = host
- @port = port
+def initialize(url)
+ @soapurl = url
@indexes = {}
@buf = nil
end
def parse_bug(bugnum)
require 'aptlistbugs/debian/btssoap'
- soap = Debian::BTSSOAP::Soap.new(@host, @port)
+ soap = Debian::BTSSOAP::Soap.new(@soapurl)
sa = Debian::BTSSOAP::StringArray.new
# query the BTS about the given bug number
@@ -58,7 +56,7 @@ module Debian
def parse(ma_copies, parsestep, severities = [critical, grave])
require 'aptlistbugs/debian/btssoap'
- soap = Debian::BTSSOAP::Soap.new(@host, @port)
+ soap = Debian::BTSSOAP::Soap.new(@soapurl)
sa = Debian::BTSSOAP::StringArray.new
bugs = Debian::Bugs.new
diff --git a/lib/aptlistbugs/debian/btssoap.rb b/lib/aptlistbugs/debian/btssoap.rb
index 759ab7ff01ae..500e2f6d3260 100644
--- a/lib/aptlistbugs/debian/btssoap.rb
+++ b/lib/aptlistbugs/debian/btssoap.rb
@@ -23,8 +23,8 @@ module Debian
module BTSSOAP
class StringArray Array; end
class Soap
- def initialize(host = bugs.debian.org, port = 80)
-@server=http://#{host}:#{port}/cgi-bin/soap.cgi;
+ def initialize(soapurl)
+@server=soapurl
@ns = 'Debbugs/SOAP/'
@drv = SOAP::RPC::Driver.new(@server, @ns)
@drv.wiredump_dev = STDOUT if $DEBUG
diff --git a/lib/aptlistbugs/logic.rb b/lib/aptlistbugs/logic.rb
index 1e4289180866..b8923d6f8030 100644
--- a/lib/aptlistbugs/logic.rb
+++ b/lib/aptlistbugs/logic.rb
@@ -42,8 +42,15 @@ class AppConfig
QUERYBTS = /usr/bin/querybts
WWW_BROWSER = /usr/bin/www-browser
SENSIBLE_BROWSER = /usr/bin/sensible-browser
+ DEFAULT_URL = https://bugs.debian.org:443/cgi-bin/soap.cgi;
+ # The default hostname and port are for backwards compatibility,
+ # and won't be used if neither --hostname nor --port is specified.
+ # These options disable https, so --url is preferred.
+ DEFAULT_HOSTNAME = bugs.debian.org
+ DEFAULT_PORT = 80
def usage
+derive_settings
$stderr.print _(Usage: ), File.basename($0),
_( [options] command [arguments]),
\n,
@@ -57,8 +64,7 @@ class AppConfig
sprintf(_( -S states : Filter bugs by pending-state categories you want to see\n[%s].\n), @stats.join(',')),
_( -B bug#: Filter bugs by number, showing only the specified bugs.\n),
_( -D : Show
Bug#792639: apt-listbugs: should use https to access bug tracking system
On Fri, 17 Jul 2015 19:13:35 -0400 Michael Gold wrote: On Fri, Jul 17, 2015 at 20:20:16 +0200, Francesco Poli wrote: On Thu, 16 Jul 2015 20:44:14 -0400 Michael Gold wrote: Well, more packages than versions, I would say, but anyway I fully acknowledge that some information is leaked. In some scenarios, one would prefer to keep these data undisclosed. And by enabling it by default, those people will not stand out. Sure, that's clear. [...] I assume that you're contributing this patch (copyrighted by you as an individual) under the same terms as apt-listbugs (GNU GPL v2 or later). Please confirm this. Yes. Perfect, thanks for confirming this! I'll add copyright notices like Copyright (C) 2015 Michael Gold mich...@bitplane.org to the relevant files and to the debian/copyright file, when I integrate you patch into apt-listbugs. • obviously, it would have been simpler to just switch from http to https and add a --disable-ssl option for those who need unencrypted SOAP connections: please elaborate a bit on the rationale behind such a more sophisticated approach (deprecate two options, which still are supported and provide the old behavior, add another option that supports arbitrary URLs); I guess the main reason is that you really value backward compatibility...? It's not clear to me why the --hostname and --port options exist; I don't know for sure, since I found them already implemented when I adopted the package, but I guess they are useful when a non-Debian debbugs instance has to be used (I am thinking about a Debian derivative distro with its own debbugs-based BTS, for instance... I am not aware of any such distro, but who knows?). and without knowing that, it's hard for me to know what will break by just enabling TLS. If the intention is to allow users to set up their own servers, I expect they'll have no (valid) TLS there, and they'll have to adjust their setup to add some --disable option. And I guess you'd want to show a notice about the change when upgrading (I find it annoying when apt assigns me busywork like this). OK, this looks like a reasonable rationale. I recommend removing --hostname and --port from the manual eventually, to simplify it. But I don't think they complicate the code too much. Let's label those two options as deprecated for the time being. They will be ready to be removed after the release of stretch, I would say... • why should the user need to explicitly specify /cgi-bin/soap.cgi? after all, it has been automatically added by apt-listbugs so far... the user could just specify --url https://bugs.debian.org:443; and the remainder could be added transparently; are there relevant scenarios where that last part of the URL won't be /cgi-bin/soap.cgi? or is it just who knows? If we expect some users to run their own servers, the default path does seem too generic. But the real reason is because I considered adding an option to specify TLS or non-TLS, and noticed it would be a roundabout way to give a URL (especially if someone later requests a way to override soap.cgi). It's trickier to put into a config file and makes backward compatibility harder. The URL is the standard way to specify everything we need to know, and it's what the library wants anyway. OK, this seems to be reasonable. Your note does give me an idea: if the URL doesn't contain a slash after the :// part, we could append /cgi-bin/soap.cgi. What do you think? It's an interesting idea, but let's not complicate things too much. I can certainly live with the need to explicitly specify /cgi-bin/soap.cgi, especially taking into account that this need only arises when a non-default URL has to be used. • I would prefer if the online help showed the current value of @soapurl between brackets, rather than its default value: apt-listbugs does so for other options; for instance I didn't notice that. I'll change it. Good, thanks. Finally, could you please re-base your patch against the current tip of the master branch on the public git repository? OK. Thank you very much, your helpfulness is really appreciated! I am looking forward to seeing your updated patch. Please send it as soon as it's ready. -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpptKxp6x8ic.pgp Description: PGP signature
Bug#792639: apt-listbugs: should use https to access bug tracking system
On Thu, 16 Jul 2015 20:44:14 -0400 Michael Gold wrote: Package: apt-listbugs Version: 0.1.16 Severity: wishlist Tags: patch security Hello Michael, first of all: thanks a lot for your bug report and for preparing a patch! :-) apt-listbugs uses an unencrypted connection to communicate with the BTS, True. leaking information about installed packages and versions. Well, more packages than versions, I would say, but anyway I fully acknowledge that some information is leaked. In some scenarios, one would prefer to keep these data undisclosed. [...] This turns out to be trivial to fix--just replace http: with https:. The ruby libraries and the BTS already support it. This is good news, I wasn't aware that the Debian BTS SOAP interface was already able to be used through HTTPS! Actually, I admit that I haven't tried to find documentation about this... The attached patch tries to do it properly to avoid breaking any local setups that depend on an unencrypted SOAP connection Thanks again for taking the time to prepare a patch. I'll examine it more carefully later. I assume that you're contributing this patch (copyrighted by you as an individual) under the same terms as apt-listbugs (GNU GPL v2 or later). Please confirm this. * Change the default URL to use https. * Add -u / --url / AptListbugs::URL settings to specify a full URL, including protocol. * Consider -H and -p deprecated; specifying either will trigger the old (unencrypted) behaviour. * Update documentation. I have a few initial comments/questions on your patch (but, once again, I haven't yet taken the time to examine it thoroughly, let alone test it!): • obviously, it would have been simpler to just switch from http to https and add a --disable-ssl option for those who need unencrypted SOAP connections: please elaborate a bit on the rationale behind such a more sophisticated approach (deprecate two options, which still are supported and provide the old behavior, add another option that supports arbitrary URLs); I guess the main reason is that you really value backward compatibility...? • why should the user need to explicitly specify /cgi-bin/soap.cgi? after all, it has been automatically added by apt-listbugs so far... the user could just specify --url https://bugs.debian.org:443; and the remainder could be added transparently; are there relevant scenarios where that last part of the URL won't be /cgi-bin/soap.cgi? or is it just who knows? • I would prefer if the online help showed the current value of @soapurl between brackets, rather than its default value: apt-listbugs does so for other options; for instance $ apt-listbugs -P -h [...] -P priority: Pin-Priority value []. [...] Finally, could you please re-base your patch against the current tip of the master branch on the public git repository? I can do that by myself, but spare time has been quite scarce around here lately... ;-) Thank you very much for your time and help! -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpfrZxiQii8y.pgp Description: PGP signature
Bug#792639: apt-listbugs: should use https to access bug tracking system
On Fri, Jul 17, 2015 at 20:20:16 +0200, Francesco Poli wrote: On Thu, 16 Jul 2015 20:44:14 -0400 Michael Gold wrote: Well, more packages than versions, I would say, but anyway I fully acknowledge that some information is leaked. In some scenarios, one would prefer to keep these data undisclosed. And by enabling it by default, those people will not stand out. This is good news, I wasn't aware that the Debian BTS SOAP interface was already able to be used through HTTPS! Actually, I admit that I haven't tried to find documentation about this... I don't recall seeing any email or documentation, but I noticed that the canonical BTS URLs changed to use https recently (if you use http: it will redirect). I assume that you're contributing this patch (copyrighted by you as an individual) under the same terms as apt-listbugs (GNU GPL v2 or later). Please confirm this. Yes. • obviously, it would have been simpler to just switch from http to https and add a --disable-ssl option for those who need unencrypted SOAP connections: please elaborate a bit on the rationale behind such a more sophisticated approach (deprecate two options, which still are supported and provide the old behavior, add another option that supports arbitrary URLs); I guess the main reason is that you really value backward compatibility...? It's not clear to me why the --hostname and --port options exist; and without knowing that, it's hard for me to know what will break by just enabling TLS. If the intention is to allow users to set up their own servers, I expect they'll have no (valid) TLS there, and they'll have to adjust their setup to add some --disable option. And I guess you'd want to show a notice about the change when upgrading (I find it annoying when apt assigns me busywork like this). I recommend removing --hostname and --port from the manual eventually, to simplify it. But I don't think they complicate the code too much. • why should the user need to explicitly specify /cgi-bin/soap.cgi? after all, it has been automatically added by apt-listbugs so far... the user could just specify --url https://bugs.debian.org:443; and the remainder could be added transparently; are there relevant scenarios where that last part of the URL won't be /cgi-bin/soap.cgi? or is it just who knows? If we expect some users to run their own servers, the default path does seem too generic. But the real reason is because I considered adding an option to specify TLS or non-TLS, and noticed it would be a roundabout way to give a URL (especially if someone later requests a way to override soap.cgi). It's trickier to put into a config file and makes backward compatibility harder. The URL is the standard way to specify everything we need to know, and it's what the library wants anyway. Your note does give me an idea: if the URL doesn't contain a slash after the :// part, we could append /cgi-bin/soap.cgi. What do you think? • I would prefer if the online help showed the current value of @soapurl between brackets, rather than its default value: apt-listbugs does so for other options; for instance I didn't notice that. I'll change it. Finally, could you please re-base your patch against the current tip of the master branch on the public git repository? OK. -- Michael signature.asc Description: Digital signature
Bug#792639: apt-listbugs: should use https to access bug tracking system
apt-listbugs uses an unencrypted connection to communicate with the BTS, leaking information about installed packages and versions. You shouldn't expect that much more security by just switching to TLS. Unfortunately Debian nowadays uses certificates issued by an externals CA (Gandi) which itself is just an intermediate CA to USERTrust. So everyone in that hierarchy could issue a forged certificate used for selective MitM attacks. And that already assumes that apt-listbugs would only trust the USERTrust or Gandi cert. Past has shown often enough that these commercial CAs are highly untrustworthy and/or in some cases plain incompetent Best wishes, Chris. smime.p7s Description: S/MIME cryptographic signature
Bug#792639: apt-listbugs: should use https to access bug tracking system
On Fri, Jul 17, 2015 at 04:17:40 +0200, Christoph Anton Mitterer wrote: apt-listbugs uses an unencrypted connection to communicate with the BTS, leaking information about installed packages and versions. You shouldn't expect that much more security by just switching to TLS. Unfortunately Debian nowadays uses certificates issued by an externals CA (Gandi) which itself is just an intermediate CA to USERTrust. So everyone in that hierarchy could issue a forged certificate used for selective MitM attacks. And that already assumes that apt-listbugs would only trust the USERTrust or Gandi cert. Right, but switching to https is a necessary step to allow other layers to implement proper security. I don't think apt-listbugs itself needs to do much more. There's a TLSA record on _443._tcp.bugs.debian.org; the TLS library should refuse to connect if that can't be validated, or if no DNSSEC records are seen for a domain that should be signed. (Presumably it would fall back to CA-based checking if the DNS resolver has no DNSSEC support, or the domain has chosen not to use it.) Even if using CAs, https would stop trivial MITM attacks. Random access points, ISP ad-servers, etc., are not likely to be using illegitimate certificates. It seems even the NSA will think twice: Something that comes up again and again in the NSA documents is that they are amazingly risk-averse. ... The chance of being noticed by surveillance targets, or anyone else, weighs heavily on operational decisions. [https://www.schneier.com/news/archives/2014/03/glenn_greenwalds_enc.html#] -- Michael signature.asc Description: Digital signature
Bug#792639: apt-listbugs: should use https to access bug tracking system
Package: apt-listbugs
Version: 0.1.16
Severity: wishlist
Tags: patch security
apt-listbugs uses an unencrypted connection to communicate with the BTS,
leaking information about installed packages and versions. (Note that
apt can talk https--and I see 26 Debian mirrors with valid certificates,
including mirrors.kernel.org.)
This turns out to be trivial to fix--just replace http: with https:.
The ruby libraries and the BTS already support it. The attached patch
tries to do it properly to avoid breaking any local setups that depend
on an unencrypted SOAP connection:
* Change the default URL to use https.
* Add -u / --url / AptListbugs::URL settings to specify a full URL,
including protocol.
* Consider -H and -p deprecated; specifying either will trigger the
old (unencrypted) behaviour.
* Update documentation.
- Michael
-- System Information:
Debian Release: stretch/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: arm64
Kernel: Linux 4.0.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
Versions of packages apt-listbugs depends on:
ii apt 1.0.9.10
ii ruby 1:2.1.5.1
ii ruby-debian 0.3.9+b1
ii ruby-gettext 3.1.2-1
ii ruby-soap4r 2.0.5-3
ii ruby-unicode 0.4.4-2+b4
ii ruby-xmlparser0.7.3-1+b1
ii ruby1.9.1 [ruby-interpreter] 1.9.3.484-2
ii ruby2.0 [ruby-interpreter]2.0.0.484+really457-3
ii ruby2.1 [ruby-interpreter]2.1.5-3
Versions of packages apt-listbugs recommends:
ii ruby-httpclient 2.3.3-3.1
Versions of packages apt-listbugs suggests:
ii chromium [www-browser] 43.0.2357.130-1
ii debianutils 4.5.1
ii dillo [www-browser] 3.0.5-1
ii elinks [www-browser] 0.12~pre6-10
ii iceweasel [www-browser] 38.1.0esr-3
ii links [www-browser] 2.9-3
ii lynx-cur [www-browser] 2.8.9dev6-3
ii reportbug6.6.3
ii w3m [www-browser]0.5.3-22
-- no debconf information
diff -ur apt-listbugs-0.1.16-orig/apt-listbugs apt-listbugs-0.1.16/apt-listbugs
--- apt-listbugs-0.1.16-orig/apt-listbugs 2014-08-25 13:41:12.0 -0400
+++ apt-listbugs-0.1.16/apt-listbugs 2015-07-16 20:33:43.925422599 -0400
@@ -46,7 +46,7 @@
== USAGE
-apt-listbugs [-h] [-v] [-s severities] [-T tags] [-S states] [-B bug#] [-D] [-H hostname] [-p port] [-P priority] [-E title] [-q] [-C apt.conf] [-F] [-y] [-n] [-d] command [arguments]
+apt-listbugs [-h] [-v] [-s severities] [-T tags] [-S states] [-B bug#] [-D] [-u url] [-P priority] [-E title] [-q] [-C apt.conf] [-F] [-y] [-n] [-d] command [arguments]
== OPTIONS
@@ -104,14 +104,21 @@
Show bugs of downgraded packages. (apt mode only)
+* -u url, --url url
+
+ Specifies the SOAP URL for the Debian Bug Tracking System
+ [https://bugs.debian.org:443/cgi-bin/soap.cgi]. The default URL may be
+ changed by setting the AptListbugs::URL configuration option.
+
* -H hostname, --hostname hostname
- Specifies the hostname of the Debian Bug Tracking System [bugs.debian.org].
+ Specifies the hostname of the Debian Bug Tracking System
+ (deprecated, and disables https; use --url instead).
* -p port, --port port
Specifies the port number of the web interface of the Debian Bug
- Tracking System [80].
+ Tracking System (deprecated, and disables https; use --url instead).
* -P priority, --pin-priority priority
@@ -214,6 +221,10 @@
Useful for setting HTTP proxy for apt-listbugs.
The special keyword 'DIRECT' will disable proxy.
+: AptListbugs::URL
+
+ Default SOAP URL for the Debian Bug Tracking System.
+
: AptListbugs::Severities
Default (comma-separated) list of bug severities to be shown. When
diff -ur apt-listbugs-0.1.16-orig/lib/apt-listbugs/logic.rb apt-listbugs-0.1.16/lib/apt-listbugs/logic.rb
--- apt-listbugs-0.1.16-orig/lib/apt-listbugs/logic.rb 2014-08-25 13:41:12.0 -0400
+++ apt-listbugs-0.1.16/lib/apt-listbugs/logic.rb 2015-07-16 20:40:29.519387373 -0400
@@ -42,6 +42,12 @@
QUERYBTS = /usr/bin/querybts
WWW_BROWSER = /usr/bin/www-browser
SENSIBLE_BROWSER = /usr/bin/sensible-browser
+ DEFAULT_URL = https://bugs.debian.org:443/cgi-bin/soap.cgi;
+ # The default hostname and port are for backwards compatibility,
+ # and won't be used if neither --hostname nor --port is specified.
+ # They don't support https, so --url is preferred.
+ DEFAULT_HOSTNAME = bugs.debian.org
+ DEFAULT_PORT = 80
def usage
$stderr.print _(Usage: ), File.basename($0),
@@ -56,8 +62,7 @@
sprintf(_( -S states : Filter bugs by pending-state categories you want to see\n[%s].\n), @stats.join(',')),
_( -B bug#: Filter bugs by number, showing only the specified bugs.\n),
_( -D : Show downgraded packages,
