From licquia at debian.org Mon Jan 6 12:53:01 2003 From: licquia at debian.org (Jeff Licquia) Date: Mon Jan 6 12:53:01 2003 Subject: [gnutls-dev]GNU TLS OpenSSL compatibility layer under GPL, not LGPL Message-ID: <1041826502.1366.39.camel@server1> I maintain the CUPS printing software for Debian, which (as distributed upstream) can use the OpenSSL library for SSL support. CUPS's libraries are distributed under the LGPL; this is an intentional decision by CUPS's upstream author that I wish to preserve in Debian. I have written a patch for CUPS to use the OpenSSL compatibility code in GNU TLS, but upstream noticed something I didn't: the compatibility library is in libgnutls-extra, which is still under the GPL. This seemed odd to me; all of the reasons expressed for relicensing under the LGPL seem to apply most notably to the OpenSSL layer, as this is what enables developers to easily transition to GNU TLS. So, I'm writing to ask a few questions: - Is this intentional? I can see the argument that a compatibility API is "extra" in the technical sense, so it might seem to belong there. - Would the authors consider changing the license on the OpenSSL layer to the LGPL? I am not concerned so much with the rest of gnutls-extra, or how the code ends up being organized. If this discussion has been hashed out elsewhere, I apologize for bringing it up again; please post a link. I could not find any such discussion in your list archives. From nmav at gnutls.org Tue Jan 7 08:42:03 2003 From: nmav at gnutls.org (Nikos Mavroyanopoulos) Date: Tue Jan 7 08:42:03 2003 Subject: [gnutls-dev]GNU TLS OpenSSL compatibility layer under GPL, not LGPL In-Reply-To: <1041826502.1366.39.camel@server1> References: <1041826502.1366.39.camel@server1> Message-ID: <20030107074301.GA1434@gnutls.org> On Sun, Jan 05, 2003 at 11:15:02PM -0500, Jeff Licquia wrote: > I have written a patch for CUPS to use the OpenSSL compatibility code in > GNU TLS, but upstream noticed something I didn't: the compatibility > library is in libgnutls-extra, which is still under the GPL. This > seemed odd to me; all of the reasons expressed for relicensing under the > LGPL seem to apply most notably to the OpenSSL layer, as this is what > enables developers to easily transition to GNU TLS. > - Is this intentional? I can see the argument that a compatibility API > is "extra" in the technical sense, so it might seem to belong there. Yes, the OpenSSL compatibility layer was written by Andrew McDonald to allow GPL programs, that depended on openssl, to compile out of the box with gnutls. This was the major problem back then. > - Would the authors consider changing the license on the OpenSSL layer > to the LGPL? I am not concerned so much with the rest of gnutls-extra, > or how the code ends up being organized. This is up to Andrew to decide, but I don't think that this is really needed. Programs that can use the compatibility layer (which is quite limited), can be easily modified to use the native gnutls API, and this is the recommended way. Isn't the upstream author interested into using gnutls? > If this discussion has been hashed out elsewhere, I apologize for > bringing it up again; please post a link. I could not find any such > discussion in your list archives. There was no such discussion in this list, so this was the right place to send it. -- Nikos Mavroyanopoulos From licquia at debian.org Wed Jan 8 23:03:01 2003 From: licquia at debian.org (Jeff Licquia) Date: Wed Jan 8 23:03:01 2003 Subject: [gnutls-dev]GNU TLS OpenSSL compatibility layer under GPL, not LGPL In-Reply-To: <20030107074301.GA1434@gnutls.org> References: <1041826502.1366.39.camel@server1> <20030107074301.GA1434@gnutls.org> Message-ID: <1041955625.795.27.camel@laptop2.internal.licquia.org> On Tue, 2003-01-07 at 02:43, Nikos Mavroyanopoulos wrote: > Yes, the OpenSSL compatibility layer was written by Andrew McDonald > to allow GPL programs, that depended on openssl, to compile out of the box > with gnutls. This was the major problem back then. I see. CUPS is admittedly unique in this respect; the libraries are LGPL, but the server and support programs are GPL (with optional OpenSSL exception). So, we have to be extra careful about the licensing; the licensing has to be GPL-compatible as well as not jeapordize the LGPL's looser restrictions. > > - Would the authors consider changing the license on the OpenSSL layer > > to the LGPL? I am not concerned so much with the rest of gnutls-extra, > > or how the code ends up being organized. > > This is up to Andrew to decide, but I don't think that this is > really needed. Programs that can use the compatibility layer (which > is quite limited), can be easily modified to use the native gnutls API, > and this is the recommended way. Isn't the upstream author interested > into using gnutls? Yes, he is. But he hasn't had the time to add the support, and from his perspective the current OpenSSL support is sufficient. If it comes down to it, I will probably write native GNU TLS support into CUPS myself. I probably would have done it anyway, as it's arguably the best way to do it, but I was hoping to get SSL-enabled CUPS into the hands of Debian users sooner. So I thought I'd ask, just in case you didn't object. If you or Andrew would please let me know what decision is reached, I would greatly appreciate it. Thanks for your work. -- Jeff Licquia From nmav at gnutls.org Fri Jan 10 18:22:02 2003 From: nmav at gnutls.org (Nikos Mavroyanopoulos) Date: Fri Jan 10 18:22:02 2003 Subject: [gnutls-dev]Re: [Help-gnutls] Re: Where is _gory_generate_elg_prime? In-Reply-To: <20030110070244.82759.qmail@web14005.mail.yahoo.com> References: <20030110070244.82759.qmail@web14005.mail.yahoo.com> Message-ID: <20030110084551.GA13663@gnutls.org> On Thu, Jan 09, 2003 at 11:02:44PM -0800, Adam wrote: > The libgcrypt.so installed on my system apparently does not have > gcry_generate_elg_prime. This is most likely a problem with the debian > package. Libgcrypt 1.1.11 does not export a required function for gnutls. Until a new version is released, a patch for libgcrypt is attached. Note that gnutls requires libgcrypt 1.1.11 in order to be used in multi-threaded environments. > Adam -- Nikos Mavroyanopoulos -------------- next part -------------- --- src/libgcrypt.vers.old Fri Jan 10 10:39:30 2003 +++ src/libgcrypt.vers Fri Jan 10 10:41:39 2003 @@ -17,9 +17,11 @@ # License along with this program; if not, write to the Free Software # Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA - +# WARNING: _gcry_generate_elg_prime is only a temporary solution for +# GNUTLS and should not be used by any otehr program. A new interface +# for prime generation will be available RSN (wk 2003-01-02) { - global: gcry*; + global: gcry*; _gcry_generate_elg_prime; local: *; }; From nmav at gnutls.org Mon Jan 20 15:45:01 2003 From: nmav at gnutls.org (Nikos Mavroyanopoulos) Date: Mon Jan 20 15:45:01 2003 Subject: [gnutls-dev]gnutls 0.8.0 Message-ID: <20030120144634.GA1272@gnutls.org> I've just released gnutls 0.8.0. - Added gnutls_x509_extract_dn_string() which returns a distinguished name in a single string. - Added gnutls_openpgp_extract_key_name_string() which returns an openpgp user ID in a single string. - Added gnutls_x509_extract_certificate_ca_status() which returns the CA status of the given certificate. - Added SRP-6 support. Follows draft-ietf-tls-srp-04. - If libtasn1 is not present in the system, it is included in the main gnutls library. - If liblzo is present in the system, then the included minilzo will not be used, and libgnutls-extra will depend on liblzo. - GNUTLS_E_PARSING_ERROR error code was replaced by GNUTLS_E_BASE64_DECODING_ER and GNUTLS_E_SRP_PWD_PARSING_ERROR. GNUTLS_E_ASCII_ARMOR_ERROR was also replaced by GNUTLS_E_BASE64_DECODING_ERROR. I've increased the version number to 0.8.0 to indicate that we are heading for a stable 1.0.0 release. All new features such as X.509 CRL and PKCS12 support will be added in 0.9.x releases. -- Nikos Mavroyanopoulos From nmav at gnutls.org Wed Jan 22 21:31:02 2003 From: nmav at gnutls.org (Nikos Mavroyanopoulos) Date: Wed Jan 22 21:31:02 2003 Subject: [gnutls-dev]gnutls 0.8.1 Message-ID: <20030122203204.GA18795@gnutls.org> I've released gnutls 0.8.1 which fixes some problems in the makefiles. All the changes since 0.8.0 are: - Improved the SRP support, to prevent attackers guessing the available usernames by brute force. - Improved the SRP detection in gnutls-cli-debug - Some fixes which now allow compilation. -- Nikos Mavroyanopoulos