[Pkg-kde-extras] Bug#669702: OpenSSL and Openconnect VPN in plasma networkmanagement
On Tue, 2012-06-12 at 15:18 +0200, Ralf Jung wrote: 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. 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
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 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
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: Patch to enable openconnect VPN plugin
On Fri, 2012-05-25 at 22:45 +0200, Michael Biebl wrote: If only openconnect would have used gnutls... If only gnutls would have given a sane way to use a certificate from a TPM, and supported DTLS. Hey, maybe I wouldn't have had to write HTTP client support for myself at all; I could have used one of the multitude of existing libraries! Looking to the future though: gnutls does have DTLS support now, and it shouldn't be that hard to make it support the slightly nonstandard version of DTLS that Cisco use in AnyConnect. And I'd settle for generic PKCS#11 module support (even though there's still no sane PKCS#11 module for TPM access). Patches to openconnect to make it optionally use gnutls instead of openssl would be most welcome... and it could be done incrementally; using gnutls just for the TCP connection first and still using OpenSSL for DTLS (which happens in openconnect(8) not in libopenconnect). That would be enough to solve this issue, and adding PKCS#11 support and DTLS support could come later. -- 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
