Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Bug#792639: apt-listbugs: should use https to access bug tracking system
35 views
Skip to first unread message
Michael Gold
Jul 16, 2015, 9:00:03 PM7/16/15
to
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-xmlparser 0.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 reportbug 6.6.3
ii w3m [www-browser] 0.5.3-22
-- no debconf information
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-xmlparser 0.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 reportbug 6.6.3
ii w3m [www-browser] 0.5.3-22
-- no debconf information
Michael Gold
Jul 17, 2015, 1:00:05 AM7/17/15
to
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.
> apt-listbugs uses an unencrypted connection to communicate with the
> > BTS,
> > leaking information about installed packages and versions.
>
>
> 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
Francesco Poli
Jul 17, 2015, 2:30:04 PM7/17/15
to
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,
> Package: apt-listbugs
> Version: 0.1.16
> Severity: wishlist
> Tags: patch security
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,
> leaking information about installed packages and versions.
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
> The ruby libraries and the BTS already support it.
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
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 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 2222 -h
[...]
-P <priority> : Pin-Priority value [2222].
[...]
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
Michael Gold
Jul 17, 2015, 7:20:02 PM7/17/15
to
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.
> 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.
> 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...
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.
> • 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...?
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?"
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
> Finally, could you please re-base your patch against the current tip of
> the master branch on the public git repository?
-- Michael
Francesco Poli
Jul 19, 2015, 10:10:04 AM7/19/15
to
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.
> 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.
[...]
> > 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!
> > individual) under the same terms as apt-listbugs (GNU GPL v2 or later).
> > Please confirm this.
>
> Yes.
I'll add copyright notices like
"Copyright (C) 2015 Michael Gold <mic...@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;
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).
>
> I recommend removing --hostname and --port from the manual eventually,
> to simplify it. But I don't think they complicate the code too much.
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.
>
> 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 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.
>
> > Finally, could you please re-base your patch against the current tip of
> > the master branch on the public git repository?
>
> OK.
I am looking forward to seeing your updated patch.
Please send it as soon as it's ready.
Michael Gold
Jul 20, 2015, 10:50:02 PM7/20/15
to
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.
> 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.
-- Michael
Francesco Poli
Jul 30, 2015, 5:00:05 PM7/30/15
to
Control: tags -1 - patch
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! :-(
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! :-(
Michael Gold
Jul 30, 2015, 9:40:02 PM7/30/15
to
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
> 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.
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.
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
Guilhem Moulin
Mar 5, 2017, 7:00:02 PM3/5/17
to
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.
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.
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.
Francesco Poli
Mar 18, 2017, 1:00:02 PM3/18/17
to
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...
> 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.
>
> 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
> 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
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.
Trent W. Buck
Apr 6, 2021, 4:50:03 AM4/6/21
to
Early discussion on this bug is "do we even want SSL?".
Please note this is now moot, as bugs.debian.org enforces SSL:
$ wget http://bugs.debian.org/test
$ grep bugs.debian.org ~/.wget-hsts
bugs.debian.org 0 0 1617696160 15552000
$ wget http://bugs.debian.org/test
URL transformed to HTTPS due to an HSTS policy
Background reading:
https://en.wikipedia.org/wiki/HSTS
Boring context (you can ignore this):
1. apt-listbugs SOMETIMES breaks unattended-upgrades for me (about 60% of the time), with this config:
Acquire::http::Proxy "http://apt-cacher-ng.cyber.com.au:3142";
Acquire::https::Proxy "DIRECT";
2. The error is not always the same:
4 times: E: HTTPClient::KeepAliveDisconnected:
3 times: E: SSL_connect SYSCALL returned=5 errno=0 state=SSLv3/TLS write client hello
4 times: E: SSL_connect returned=1 errno=0 state=error: wrong version number
Is ruby's HTTP/1 client continuing to use the (HTTP-only) proxy after
http://deb.debian.org redirects to
https://deb.debian.org?
UPDATE: apt-listbugs/0.1.35 ignores Acquire::https::Proxy entirely, which sounds wrong:
https://salsa.debian.org/frx-guest/apt-listbugs/-/blob/master/lib/aptlistbugs/logic.rb#L268
3. The documented workaround sounds silly, because I already set a blanket DIRECT for https:
https://salsa.debian.org/frx-guest/apt-listbugs/-/blob/master/FAQ.md#how-can-i-use-apt-listbugs-with-apt-cacherapt-cacher-ng-proxies
UPDATE: since Acquire::https::Proxy is ignored, I guess I have to do this. Blech.
4. Since bugs.debian.org already forces TLS (due to HSTS),
surely I just change the URL from http:// to https://?
I don't see an equivalent of Acquire::Changelogs::URI in "apt-config dump":
lib/aptlistbugs/logic.rb: if /sev_list='(.*)'/ =~ `apt-config #{@apt_conf} shell sev_list AptListbugs::Severities`
lib/aptlistbugs/logic.rb: if /qb='(.*)'/ =~ `apt-config #{@apt_conf} shell qb AptListbugs::QueryStep`
lib/aptlistbugs/logic.rb: if /qb='(.*)'/ =~ `apt-config #{@apt_conf} shell qb AptListbugs::ParseStep`
lib/aptlistbugs/logic.rb: if /http_proxy='(.*)'/ =~ `apt-config #{@apt_conf} shell http_proxy acquire::http::proxy`
lib/aptlistbugs/logic.rb: if /proxy_detect='(.*)'/ =~ `apt-config #{@apt_conf} shell proxy_detect acquire::http::proxy-auto-detect`
lib/aptlistbugs/logic.rb: if /http_proxy='(.*)'/ =~ `apt-config #{@apt_conf} shell http_proxy acquire::http::proxy::bugs.debian.org`
lib/aptlistbugs/logic.rb: if /ignore_regexp='(.*)'/ =~ `apt-config #{@apt_conf} shell ignore_regexp AptListbugs::IgnoreRegexp`
Looks like it's not even starting from a URL, but rather a hostname and a port number:
https://salsa.debian.org/frx-guest/apt-listbugs/-/blob/master/lib/aptlistbugs/logic.rb#L95
5. I found this bug where people are bikeshedding the moral hazards of condoning SSL.
I get annoyed.
Please note this is now moot, as bugs.debian.org enforces SSL:
$ wget http://bugs.debian.org/test
$ grep bugs.debian.org ~/.wget-hsts
bugs.debian.org 0 0 1617696160 15552000
$ wget http://bugs.debian.org/test
URL transformed to HTTPS due to an HSTS policy
Background reading:
https://en.wikipedia.org/wiki/HSTS
Boring context (you can ignore this):
1. apt-listbugs SOMETIMES breaks unattended-upgrades for me (about 60% of the time), with this config:
Acquire::http::Proxy "http://apt-cacher-ng.cyber.com.au:3142";
Acquire::https::Proxy "DIRECT";
2. The error is not always the same:
4 times: E: HTTPClient::KeepAliveDisconnected:
3 times: E: SSL_connect SYSCALL returned=5 errno=0 state=SSLv3/TLS write client hello
4 times: E: SSL_connect returned=1 errno=0 state=error: wrong version number
Is ruby's HTTP/1 client continuing to use the (HTTP-only) proxy after
http://deb.debian.org redirects to
https://deb.debian.org?
UPDATE: apt-listbugs/0.1.35 ignores Acquire::https::Proxy entirely, which sounds wrong:
https://salsa.debian.org/frx-guest/apt-listbugs/-/blob/master/lib/aptlistbugs/logic.rb#L268
3. The documented workaround sounds silly, because I already set a blanket DIRECT for https:
https://salsa.debian.org/frx-guest/apt-listbugs/-/blob/master/FAQ.md#how-can-i-use-apt-listbugs-with-apt-cacherapt-cacher-ng-proxies
UPDATE: since Acquire::https::Proxy is ignored, I guess I have to do this. Blech.
4. Since bugs.debian.org already forces TLS (due to HSTS),
surely I just change the URL from http:// to https://?
I don't see an equivalent of Acquire::Changelogs::URI in "apt-config dump":
lib/aptlistbugs/logic.rb: if /sev_list='(.*)'/ =~ `apt-config #{@apt_conf} shell sev_list AptListbugs::Severities`
lib/aptlistbugs/logic.rb: if /qb='(.*)'/ =~ `apt-config #{@apt_conf} shell qb AptListbugs::QueryStep`
lib/aptlistbugs/logic.rb: if /qb='(.*)'/ =~ `apt-config #{@apt_conf} shell qb AptListbugs::ParseStep`
lib/aptlistbugs/logic.rb: if /http_proxy='(.*)'/ =~ `apt-config #{@apt_conf} shell http_proxy acquire::http::proxy`
lib/aptlistbugs/logic.rb: if /proxy_detect='(.*)'/ =~ `apt-config #{@apt_conf} shell proxy_detect acquire::http::proxy-auto-detect`
lib/aptlistbugs/logic.rb: if /http_proxy='(.*)'/ =~ `apt-config #{@apt_conf} shell http_proxy acquire::http::proxy::bugs.debian.org`
lib/aptlistbugs/logic.rb: if /ignore_regexp='(.*)'/ =~ `apt-config #{@apt_conf} shell ignore_regexp AptListbugs::IgnoreRegexp`
Looks like it's not even starting from a URL, but rather a hostname and a port number:
https://salsa.debian.org/frx-guest/apt-listbugs/-/blob/master/lib/aptlistbugs/logic.rb#L95
5. I found this bug where people are bikeshedding the moral hazards of condoning SSL.
I get annoyed.
Francesco Poli
Apr 6, 2021, 1:30:03 PM4/6/21
to
On Tue, 6 Apr 2021 18:39:11 +1000 Trent W. Buck wrote:
> Early discussion on this bug is "do we even want SSL?".
Hello Trent,
> Early discussion on this bug is "do we even want SSL?".
thanks for following up on this wishlist bug report!
I think the conclusion of the first part of this report was that SSL
would be desirable, but not yet easy to achieve without licensing
issues.
[...]
> Background reading:
>
> https://en.wikipedia.org/wiki/HSTS
Thanks for the news.
This means that apt-listbugs now unintentionally uses SSL.
Let's leave things as they are, until OpenSSL v3.0.0 gets released and
included in Debian unstable and testing.
Please see [933252#10] for further details.
[933252#10]: <https://bugs.debian.org/933252#10>
>
>
> Boring context (you can ignore this):
>
> 1. apt-listbugs SOMETIMES breaks unattended-upgrades for me
> (about 60% of the time), with this config:
>
> Acquire::http::Proxy "http://apt-cacher-ng.cyber.com.au:3142";
> Acquire::https::Proxy "DIRECT";
> UPDATE: apt-listbugs/0.1.35 ignores Acquire::https::Proxy entirely, which sounds wrong:
>
> https://salsa.debian.org/frx-guest/apt-listbugs/-/blob/master/lib/aptlistbugs/logic.rb#L268
The reason is that apt-listbugs is currently unaware of any SSL-related
>
> https://salsa.debian.org/frx-guest/apt-listbugs/-/blob/master/lib/aptlistbugs/logic.rb#L268
thing.
So it looks at HTTP proxy settings, not HTTPS ones...
>
> 3. The documented workaround sounds silly, because I already set
> a blanket DIRECT for https:
>
> https://salsa.debian.org/frx-guest/apt-listbugs/-/blob/master/FAQ.md#how-can-i-use-apt-listbugs-with-apt-cacherapt-cacher-ng-proxies
>
> UPDATE: since Acquire::https::Proxy is ignored, I guess I have
> to do this. Blech.
I admit that having to add one more configuration line sucks a bit,
but... please bear with apt-listbugs, which currently knows nothing
about SSL!
Have you tried this workaround?
I hope it can solve your unattended-upgrade issues.
>
> 4. Since bugs.debian.org already forces TLS (due to HSTS),
> surely I just change the URL from http:// to https://?
> Looks like it's not even starting from a URL, but rather a hostname and a port number:
>
> https://salsa.debian.org/frx-guest/apt-listbugs/-/blob/master/lib/aptlistbugs/logic.rb#L95
Correct, apt-listbugs currently builds the URL from hostname and port,
>
> https://salsa.debian.org/frx-guest/apt-listbugs/-/blob/master/lib/aptlistbugs/logic.rb#L95
automatically adding the protocol part ("http://") and the rest...
>
> 5. I found this bug where people are bikeshedding the moral hazards
> of condoning SSL.
> I get annoyed.
that really have to be taken into account. I don't consider paying
attention to them as "bikeshedding".
Anyway, I appreciate your contribution (I wasn't aware of HSTS).
Let's hope that OpenSSL v3.0.0 gets released soon, so that we can make
use of it (after Debian bullseye is out, of course!).
Bye! :-)
Trent W. Buck
Apr 7, 2021, 4:10:04 AM4/7/21
to
Francesco Poli wrote:
> Let's leave things as they are, until OpenSSL v3.0.0 gets released and
> included in Debian unstable and testing.
>
> Please see [933252#10] for further details.
>
> [933252#10]: <https://bugs.debian.org/933252#10>
>> https://salsa.debian.org/frx-guest/apt-listbugs/-/blob/master/FAQ.md#how-can-i-use-apt-listbugs-with-apt-cacherapt-cacher-ng-proxies
> Let's leave things as they are, until OpenSSL v3.0.0 gets released and
> included in Debian unstable and testing.
>
> Please see [933252#10] for further details.
>
> [933252#10]: <https://bugs.debian.org/933252#10>
>> Since Acquire::https::Proxy is ignored, I guess I have to do this. Blech.
>
> Probably you have, for the time being.
> I admit that having to add one more configuration line sucks a bit,
> but... please bear with apt-listbugs, which currently knows nothing
> about SSL!
>
> Have you tried this workaround?
> I hope it can solve your unattended-upgrade issues.
Yes, I have deployed the workaround from FAQ.md.
> Probably you have, for the time being.
> I admit that having to add one more configuration line sucks a bit,
> but... please bear with apt-listbugs, which currently knows nothing
> about SSL!
>
> Have you tried this workaround?
> I hope it can solve your unattended-upgrade issues.
I think it works;
I have to wait a week or two to see if it is truly works.
On that basis, I agree it is reasonable to ignore this issue until OpenSSL 3.x lands.
On that basis, I also won't bother digging into "could libruby2.7 use libgnutls30/libnss3/libmbedtls12/libwolfssl24 instead of libssl1.1?"
>> 5. I found this bug where people are bikeshedding the moral hazards
>> of condoning SSL.
>> I get annoyed.
>
> I think that potential licensing incompatibilities are serious issues
> that really have to be taken into account. I don't consider paying
> attention to them as "bikeshedding".
I agree that is not bikeshedding.
I was referring to the people saying (paraphrasing) "if we use SSL then an evil CA might break Debian!"
Chris Hofstaedtler
Apr 7, 2021, 4:20:04 PM4/7/21
to
Hello Francesco,
* Francesco Poli <inver...@paranoici.org> [210407 20:11]:
> I think that potential licensing incompatibilities are serious issues
> that really have to be taken into account. I don't consider paying
> attention to them as "bikeshedding".
>
> Anyway, I appreciate your contribution (I wasn't aware of HSTS).
>
> Let's hope that OpenSSL v3.0.0 gets released soon, so that we can make
> use of it (after Debian bullseye is out, of course!).
Note that you do not really have to wait for anything. The FTP team
has already decided that Debian will use OpenSSL under the system
library exception (and I believe this applies to OpenSSL 3.0 as
well).
Chris
* Francesco Poli <inver...@paranoici.org> [210407 20:11]:
> Let's leave things as they are, until OpenSSL v3.0.0 gets released and
> included in Debian unstable and testing.
>
> Please see [933252#10] for further details.
>
> [933252#10]: <https://bugs.debian.org/933252#10>
[..]
> included in Debian unstable and testing.
>
> Please see [933252#10] for further details.
>
> [933252#10]: <https://bugs.debian.org/933252#10>
> I think that potential licensing incompatibilities are serious issues
> that really have to be taken into account. I don't consider paying
> attention to them as "bikeshedding".
>
> Anyway, I appreciate your contribution (I wasn't aware of HSTS).
>
> Let's hope that OpenSSL v3.0.0 gets released soon, so that we can make
> use of it (after Debian bullseye is out, of course!).
has already decided that Debian will use OpenSSL under the system
library exception (and I believe this applies to OpenSSL 3.0 as
well).
Chris
Francesco Poli
Apr 7, 2021, 5:20:03 PM4/7/21
to
On Wed, 7 Apr 2021 22:15:15 +0200 Chris Hofstaedtler wrote:
> Hello Francesco,
Hi Chris, nice to read you! :-)
[...]
where.
I am a bit perplexed by that decision, since it contradicts what has
been said and done for ages. I am not sure I understand which new facts
emerged, justifying such a dramatic turn of events.
Old [consultation] reached the opposite conclusion.
[consultation]: <https://lists.debian.org/debian-legal/2007/07/msg00194.html>
And I see I am not the only one who's [perplexed].
[perplexed]: <https://lists.debian.org/debian-devel/2020/10/msg00168.html>
Are you aware of an official statement by the Debian FTP team
explaining the rationale behind this decision?
P.S.: anyway, as far as apt-listbugs is concerned, I will reconsider
all the issue *after* bullseye is released as stable...
> Hello Francesco,
Hi Chris, nice to read you! :-)
[...]
> > Let's hope that OpenSSL v3.0.0 gets released soon, so that we can make
> > use of it (after Debian bullseye is out, of course!).
>
> Note that you do not really have to wait for anything. The FTP team
> has already decided that Debian will use OpenSSL under the system
> library exception (and I believe this applies to OpenSSL 3.0 as
> well).
I had heard of that decision, even though I am now unable to recall
> > use of it (after Debian bullseye is out, of course!).
>
> Note that you do not really have to wait for anything. The FTP team
> has already decided that Debian will use OpenSSL under the system
> library exception (and I believe this applies to OpenSSL 3.0 as
> well).
where.
I am a bit perplexed by that decision, since it contradicts what has
been said and done for ages. I am not sure I understand which new facts
emerged, justifying such a dramatic turn of events.
Old [consultation] reached the opposite conclusion.
[consultation]: <https://lists.debian.org/debian-legal/2007/07/msg00194.html>
And I see I am not the only one who's [perplexed].
[perplexed]: <https://lists.debian.org/debian-devel/2020/10/msg00168.html>
Are you aware of an official statement by the Debian FTP team
explaining the rationale behind this decision?
P.S.: anyway, as far as apt-listbugs is concerned, I will reconsider
all the issue *after* bullseye is released as stable...
Chris Hofstaedtler
Apr 7, 2021, 6:00:04 PM4/7/21
to
Hi Francesco,
* Francesco Poli <inver...@paranoici.org> [210407 23:08]:
> > * Francesco Poli <inver...@paranoici.org> [210407 20:11]:
> [...]
> > > Let's hope that OpenSSL v3.0.0 gets released soon, so that we can make
> > > use of it (after Debian bullseye is out, of course!).
> >
> > Note that you do not really have to wait for anything. The FTP team
> > has already decided that Debian will use OpenSSL under the system
> > library exception (and I believe this applies to OpenSSL 3.0 as
> > well).
>
> I had heard of that decision, even though I am now unable to recall
> where.
The "best" reference I can find right now is:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=924937
http://meetbot.debian.net/debian-ftp/2020/debian-ftp.2020-03-13-20.02.html
I believe there was an announcement, but cannot find it at this
time.
> I am a bit perplexed by that decision, since it contradicts what has
> been said and done for ages. I am not sure I understand which new facts
> emerged, justifying such a dramatic turn of events.
[..]
TTBOMK some people also consider Apache + GPL not necessarily
compatible, so it would not really be a better situation either.
Chris
* Francesco Poli <inver...@paranoici.org> [210407 23:08]:
> On Wed, 7 Apr 2021 22:15:15 +0200 Chris Hofstaedtler wrote:
> Hi Chris, nice to read you! :-)
Likewise :-)
> Hi Chris, nice to read you! :-)
> > * Francesco Poli <inver...@paranoici.org> [210407 20:11]:
> [...]
> > > Let's hope that OpenSSL v3.0.0 gets released soon, so that we can make
> > > use of it (after Debian bullseye is out, of course!).
> >
> > Note that you do not really have to wait for anything. The FTP team
> > has already decided that Debian will use OpenSSL under the system
> > library exception (and I believe this applies to OpenSSL 3.0 as
> > well).
>
> I had heard of that decision, even though I am now unable to recall
> where.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=924937
http://meetbot.debian.net/debian-ftp/2020/debian-ftp.2020-03-13-20.02.html
I believe there was an announcement, but cannot find it at this
time.
> I am a bit perplexed by that decision, since it contradicts what has
> been said and done for ages. I am not sure I understand which new facts
> emerged, justifying such a dramatic turn of events.
> Are you aware of an official statement by the Debian FTP team
> explaining the rationale behind this decision?
I believe the libgcc situation had a strong influence on this;
> explaining the rationale behind this decision?
TTBOMK some people also consider Apache + GPL not necessarily
compatible, so it would not really be a better situation either.
Chris
Francesco Poli
Apr 8, 2021, 5:50:04 PM4/8/21
to
On Wed, 7 Apr 2021 23:52:27 +0200 Chris Hofstaedtler wrote:
[...]
>
> I believe there was an announcement, but cannot find it at this
> time.
Well, I (re-)read the meeting [log]. Quite laconic, I would say.
I would like to read a rationale for the decision.
Reading the [log], it almost looks like a decision made out of despair
(as if the conclusion were "it is a system library, because we need it
to be"...).
[log]: <http://meetbot.debian.net/debian-ftp/2020/debian-ftp.2020-03-13-20.02.log.html>
[...]
At least, libgcc looks more like a fundamental library: referring to
the GPL-2 clause, libgcc might be considered as "normally distributed
[...] with the major components (compiler, kernel, and so on) of the
operating system on which the executable runs".
There's still something to be understood, however. libgcc and the
executable are shipped in two distinct Debian packages: does this mean
that libgcc accompanies the executable?
> TTBOMK some people also consider Apache + GPL not necessarily
> compatible, so it would not really be a better situation either.
Apache-1.1 is definitely GPL-incompatible.
Apache-2.0 is considered GPL-3-compatible, but GPL-2-incompatible.
Do you mean that some people consider Apache-2.0 not necessarily
GPL-3-compatible?
[...]
> * Francesco Poli <inver...@paranoici.org> [210407 23:08]:
[...]
> > I had heard of that decision, even though I am now unable to recall
> > where.
>
> The "best" reference I can find right now is:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=924937
> http://meetbot.debian.net/debian-ftp/2020/debian-ftp.2020-03-13-20.02.html
Mmmmh, sounds familiar: that's probably where I learned about this decision.
> > where.
>
> The "best" reference I can find right now is:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=924937
> http://meetbot.debian.net/debian-ftp/2020/debian-ftp.2020-03-13-20.02.html
>
> I believe there was an announcement, but cannot find it at this
> time.
I would like to read a rationale for the decision.
Reading the [log], it almost looks like a decision made out of despair
(as if the conclusion were "it is a system library, because we need it
to be"...).
[log]: <http://meetbot.debian.net/debian-ftp/2020/debian-ftp.2020-03-13-20.02.log.html>
[...]
> I believe the libgcc situation had a strong influence on this;
I am not sure how much the libgcc case is equivalent to the libssl one.
At least, libgcc looks more like a fundamental library: referring to
the GPL-2 clause, libgcc might be considered as "normally distributed
[...] with the major components (compiler, kernel, and so on) of the
operating system on which the executable runs".
There's still something to be understood, however. libgcc and the
executable are shipped in two distinct Debian packages: does this mean
that libgcc accompanies the executable?
> TTBOMK some people also consider Apache + GPL not necessarily
> compatible, so it would not really be a better situation either.
Apache-2.0 is considered GPL-3-compatible, but GPL-2-incompatible.
Do you mean that some people consider Apache-2.0 not necessarily
GPL-3-compatible?
marc
Nov 2, 2022, 12:00:04 PM11/2/22
to
Package: apt-listbugs
Version: 0.1.35
Followup-For: Bug #792639
X-Debbugs-Cc: marc.no...@gmail.com
Hello, OpenSSL 3.0.5 is in bookworm. Are there other blockers to fix this issue?
Version: 0.1.35
Followup-For: Bug #792639
X-Debbugs-Cc: marc.no...@gmail.com
Hello, OpenSSL 3.0.5 is in bookworm. Are there other blockers to fix this issue?
Francesco Poli
Nov 3, 2022, 7:20:03 PM11/3/22
to
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,
> Hello, OpenSSL 3.0.5 is in bookworm. Are there other blockers
> to fix this issue?
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.
0 new messages