[Pkg-kde-extras] Bug#669702: OpenSSL and Openconnect VPN in plasma networkmanagement
Hi, > I'm not entirely sure when plasma-widget-networkmanagement registers its > NM VPN agent. This is almost certainly a problem with that, rather than > the openconnect-specific parts. Can you restart kded perhaps? I logged out and in, so everything was restarted. Maybe just putting the old debian folder into the new openconnect sources does not work since there was a soname bump - I don't know enough about Debian's handling of shared libraries. Kind regards, Ralf ___ pkg-kde-extras mailing list pkg-kde-extras@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-extras
[Pkg-kde-extras] Bug#669702: OpenSSL and Openconnect VPN in plasma networkmanagement
On Tue, 2012-06-12 at 15:18 +0200, Ralf Jung wrote: > [1339506419.612035] [nm-vpn-connection.c:934] get_secrets_cb(): > Failed > to request VPN secrets #3: (6) No agents were available for this request. I'm not entirely sure when plasma-widget-networkmanagement registers its NM VPN agent. This is almost certainly a problem with that, rather than the openconnect-specific parts. Can you restart kded perhaps? I've made a 3.99 release of OpenConnect, which is essentially a beta for 4.00. Matthew, you might want the subsequent patch from the git tree if you're using OpenSSL for DTLS still. The auth-dialog patches for GNOME are already upstream, although you need *not* to include the IPv6 bits from NetworkManager-openconnect unless you've also got an up-to-date NetworkManager. And the final auth-dialog patch for KDE is https://git.reviewboard.kde.org/r/105185/ The packages in Fedora rawhide should be working, using GnuTLS for authentication and falling back to OpenSSL (only in /usr/sbin/openconnect) for DTLS. -- dwmw2 smime.p7s Description: S/MIME cryptographic signature ___ pkg-kde-extras mailing list pkg-kde-extras@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-extras
[Pkg-kde-extras] Bug#669702: OpenSSL and Openconnect VPN in plasma networkmanagement
Hi, I had quite some trouble getting the current openconnect installed without messing my system up (that is, compiling a Debian package for it)... and apparently I did something wrong, or it doesn't work: After also patching and installing plasma-widget-networkmanagement, connecting to the VPN fails with the error [1339506419.612035] [nm-vpn-connection.c:934] get_secrets_cb(): Failed to request VPN secrets #3: (6) No agents were available for this request. Kind regards, Ralf On Thursday 07 June 2012 12:21:05 David Woodhouse wrote: > On Thu, 2012-06-07 at 12:16 +0200, Ralf Jung wrote: > > So the next step would be to change the KDE openconnect NM plugin to use > > the GnuTLS backend of openconnect instead of the OpenSSL one? Currently > > the backend also uses some stuff directly from OpenSSL, I do not know > > why that is needed. > > I fixed that already: > http://git.infradead.org/users/dwmw2/networkmanagement.git/commitdiff/dde75 > baa ___ pkg-kde-extras mailing list pkg-kde-extras@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-extras
[Pkg-kde-extras] Bug#669702: OpenSSL and Openconnect VPN in plasma networkmanagement
Hi, On Friday 01 June 2012 03:04:29 David Woodhouse wrote: > On Mon, 2012-05-28 at 13:14 +0200, Ralf Jung wrote: > > > That said, I'm working on porting to GnuTLS anyway. > > > > That's good news. Let me know if I can help testing :) > > http://lists.infradead.org/pipermail/openconnect-devel/2012-May/000572.html So the next step would be to change the KDE openconnect NM plugin to use the GnuTLS backend of openconnect instead of the OpenSSL one? Currently the backend also uses some stuff directly from OpenSSL, I do not know why that is needed. Kind regards, Ralf ___ pkg-kde-extras mailing list pkg-kde-extras@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-extras
[Pkg-kde-extras] Bug#669702: OpenSSL and Openconnect VPN in plasma networkmanagement
On Thu, 2012-06-07 at 12:16 +0200, Ralf Jung wrote: > So the next step would be to change the KDE openconnect NM plugin to use the > GnuTLS backend of openconnect instead of the OpenSSL one? Currently the > backend also uses some stuff directly from OpenSSL, I do not know why that is > needed. I fixed that already: http://git.infradead.org/users/dwmw2/networkmanagement.git/commitdiff/dde75baa -- dwmw2 smime.p7s Description: S/MIME cryptographic signature ___ pkg-kde-extras mailing list pkg-kde-extras@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-extras
[Pkg-kde-extras] Bug#669702: OpenSSL and Openconnect VPN in plasma networkmanagement
On Mon, 2012-05-28 at 13:14 +0200, Ralf Jung wrote: > > That said, I'm working on porting to GnuTLS anyway. > That's good news. Let me know if I can help testing :) http://lists.infradead.org/pipermail/openconnect-devel/2012-May/000572.html -- dwmw2 smime.p7s Description: S/MIME cryptographic signature ___ pkg-kde-extras mailing list pkg-kde-extras@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-extras
[Pkg-kde-extras] Bug#669702: OpenSSL and Openconnect VPN in plasma networkmanagement
On Mon, 2012-05-28 at 13:14 +0200, Ralf Jung wrote: > > >* 6. Redistributions of any form whatsoever must retain the following > >*acknowledgment: > >*"This product includes software developed by the OpenSSL Project > >*for use in the OpenSSL Toolkit (http://www.openssl.org/)" > > > > I don't see the relevance of §6. You're linking to a copy of OpenSSL in > > shared library form which already exists on the system; you aren't > > redistributing it in any form. So that should be a non-issue, surely? > > From what I understood - but that's not very much - the problem is simply > that > this is a restriction, while the GPL forbids all kinds of restrictions. It's not a restriction unless you are redistributing OpenSSL, which nobody here is doing. > > That said, I'm working on porting to GnuTLS anyway. > That's good news. Let me know if I can help testing :) It'll be a while; there's a lot to be done and I don't have a lot of free time for it at the moment. If anyone else is interested in working on it, I'd be happy to hand off my work-in-progress and my vague notes on what else needs doing (past the basics of actually making it compile). -- dwmw2 smime.p7s Description: S/MIME cryptographic signature ___ pkg-kde-extras mailing list pkg-kde-extras@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-extras
[Pkg-kde-extras] Bug#669702: OpenSSL and Openconnect VPN in plasma networkmanagement
Hi, > > According to the copyright headers and the git log, you are the main and > > actually almost the only author of that plugin. Is that correct, and if > > yes, would you be willing to add a license extension as stated in [1] to > > the files, so they can be linked with OpenSSL? > > Like libopenconnect itself, Ilia's code is already licensed under the > LGPL, not the GPL. There is no need for an exception for OpenSSL, in the > openconnect-specific plugin. Oh, I did not know that. Sorry for the noise, Ilia. But then I actually do not see the issue here - does the GPL even infect through libraries which are only found and dlsym'ed at runtime? I mean, most of kdelibs is also LGPL. So the entire of kded and would have to be re- licensed for any kded plugin to be able to use OpenSSL? Wow... > Whether that's sufficient or not is not entirely clear to me though. It > is still being loaded into the GPL'd kded as a plugin, after all. > > > [1] http://people.gnome.org/~markmc/openssl-and-the-gpl.html > > That highlights §2 and §6 of the OpenSSL licence: > >* 3. All advertising materials mentioning features or use of this >*software must display the following acknowledgment: >*"This product includes software developed by the OpenSSL Project >*for use in the OpenSSL Toolkit. (http://www.openssl.org/)" > >* 6. Redistributions of any form whatsoever must retain the following >*acknowledgment: >*"This product includes software developed by the OpenSSL Project >*for use in the OpenSSL Toolkit (http://www.openssl.org/)" > > I don't see the relevance of §6. You're linking to a copy of OpenSSL in > shared library form which already exists on the system; you aren't > redistributing it in any form. So that should be a non-issue, surely? >From what I understood - but that's not very much - the problem is simply that this is a restriction, while the GPL forbids all kinds of restrictions. > That said, I'm working on porting to GnuTLS anyway. That's good news. Let me know if I can help testing :) Kind regards, Ralf ___ pkg-kde-extras mailing list pkg-kde-extras@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-extras
[Pkg-kde-extras] Bug#669702: OpenSSL and Openconnect VPN in plasma networkmanagement
On 28.05.2012 12:21, Ralf Jung wrote: > Hi Ilia, > > the openconnect vpn module of the plasma widget for networkmanagement links > against OpenSSL, which has some problematic licensing consequences [1]. This > prevents the module from being enabled in Debian [2]. The openconnect vpn module is not problematic, as its sources are under LGPL2. > The only part of network manager directly linking with OpenSSL is that plugin > - I am by far not a licensing expert, but I hope this means that the rest of > the code, which just loads the plugin at runtime, does not need any > relicensing - after all, that code can't know which plugins will be loaded > later. That's exactly what it means, unfortunately. It is the combined work which is problematic. > According to the copyright headers and the git log, you are the main and > actually almost the only author of that plugin. Is that correct, and if yes, > would you be willing to add a license extension as stated in [1] to the > files, > so they can be linked with OpenSSL? The complete networkmanagement sources which use GPL2 would need that exemption. Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature ___ pkg-kde-extras mailing list pkg-kde-extras@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-extras
[Pkg-kde-extras] Bug#669702: OpenSSL and Openconnect VPN in plasma networkmanagement
On Mon, 2012-05-28 at 12:21 +0200, Ralf Jung wrote: > According to the copyright headers and the git log, you are the main and > actually almost the only author of that plugin. Is that correct, and if yes, > would you be willing to add a license extension as stated in [1] to the > files, > so they can be linked with OpenSSL? Like libopenconnect itself, Ilia's code is already licensed under the LGPL, not the GPL. There is no need for an exception for OpenSSL, in the openconnect-specific plugin. Whether that's sufficient or not is not entirely clear to me though. It is still being loaded into the GPL'd kded as a plugin, after all. > [1] http://people.gnome.org/~markmc/openssl-and-the-gpl.html That highlights §2 and §6 of the OpenSSL licence: * 3. All advertising materials mentioning features or use of this *software must display the following acknowledgment: *"This product includes software developed by the OpenSSL Project *for use in the OpenSSL Toolkit. (http://www.openssl.org/)" * 6. Redistributions of any form whatsoever must retain the following *acknowledgment: *"This product includes software developed by the OpenSSL Project *for use in the OpenSSL Toolkit (http://www.openssl.org/)" I don't see the relevance of §6. You're linking to a copy of OpenSSL in shared library form which already exists on the system; you aren't redistributing it in any form. So that should be a non-issue, surely? So that leaves §2, and I have difficulty understanding precisely what restriction that places on kded. We don't *have* any advertising materials that mention features or use of OpenSSL, but I suppose the concern is that any downstream user must have the right to *create* such, without the wording that OpenSSL requires? But surely they *can* anyway? Doing so doesn't restrict their ability to use libopenconnect or anything higher up in the stack; only their ability to distribute OpenSSL itself, which as already observed we aren't doing. That said, I'm working on porting to GnuTLS anyway. -- dwmw2 smime.p7s Description: S/MIME cryptographic signature ___ pkg-kde-extras mailing list pkg-kde-extras@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-extras
[Pkg-kde-extras] Bug#669702: OpenSSL and Openconnect VPN in plasma networkmanagement
Hi Ilia, the openconnect vpn module of the plasma widget for networkmanagement links against OpenSSL, which has some problematic licensing consequences [1]. This prevents the module from being enabled in Debian [2]. The only part of network manager directly linking with OpenSSL is that plugin - I am by far not a licensing expert, but I hope this means that the rest of the code, which just loads the plugin at runtime, does not need any relicensing - after all, that code can't know which plugins will be loaded later. According to the copyright headers and the git log, you are the main and actually almost the only author of that plugin. Is that correct, and if yes, would you be willing to add a license extension as stated in [1] to the files, so they can be linked with OpenSSL? Kind regards, Ralf [1] http://people.gnome.org/~markmc/openssl-and-the-gpl.html [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=669702 ___ pkg-kde-extras mailing list pkg-kde-extras@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-extras
