mirror of
https://github.com/moparisthebest/curl
synced 2024-11-10 19:45:04 -05:00
9ad282b1ae
This is just fundamentally broken. SPNEGO (RFC4178) is a protocol which allows client and server to negotiate the underlying mechanism which will actually be used to authenticate. This is *often* Kerberos, and can also be NTLM and other things. And to complicate matters, there are various different OIDs which can be used to specify the Kerberos mechanism too. A SPNEGO exchange will identify *which* GSSAPI mechanism is being used, and will exchange GSSAPI tokens which are appropriate for that mechanism. But this SPNEGO implementation just strips the incoming SPNEGO packet and extracts the token, if any. And completely discards the information about *which* mechanism is being used. Then we *assume* it was Kerberos, and feed the token into gss_init_sec_context() with the default mechanism (GSS_S_NO_OID for the mech_type argument). Furthermore... broken as this code is, it was never even *used* for input tokens anyway, because higher layers of curl would just bail out if the server actually said anything *back* to us in the negotiation. We assume that we send a single token to the server, and it accepts it. If the server wants to continue the exchange (as is required for NTLM and for SPNEGO to do anything useful), then curl was broken anyway. So the only bit which actually did anything was the bit in Curl_output_negotiate(), which always generates an *initial* SPNEGO token saying "Hey, I support only the Kerberos mechanism and this is its token". You could have done that by manually just prefixing the Kerberos token with the appropriate bytes, if you weren't going to do any proper SPNEGO handling. There's no need for the FBOpenSSL library at all. The sane way to do SPNEGO is just to *ask* the GSSAPI library to do SPNEGO. That's what the 'mech_type' argument to gss_init_sec_context() is for. And then it should all Just Work™. That 'sane way' will be added in a subsequent patch, as will bug fixes for our failure to handle any exchange other than a single outbound token to the server which results in immediate success.
125 lines
5.6 KiB
Plaintext
125 lines
5.6 KiB
Plaintext
License Mixing with apps, libcurl and Third Party Libraries
|
|
===========================================================
|
|
|
|
libcurl can be built to use a fair amount of various third party libraries,
|
|
libraries that are written and provided by other parties that are distributed
|
|
using their own licenses. Even libcurl itself contains code that may cause
|
|
problems to some. This document attempts to describe what licenses libcurl and
|
|
the other libraries use and what possible dilemmas linking and mixing them all
|
|
can lead to for end users.
|
|
|
|
I am not a lawyer and this is not legal advice!
|
|
|
|
One common dilemma is that GPL[1]-licensed code is not allowed to be linked
|
|
with code licensed under the Original BSD license (with the announcement
|
|
clause). You may still build your own copies that use them all, but
|
|
distributing them as binaries would be to violate the GPL license - unless you
|
|
accompany your license with an exception[2]. This particular problem was
|
|
addressed when the Modified BSD license was created, which does not have the
|
|
announcement clause that collides with GPL.
|
|
|
|
libcurl http://curl.haxx.se/docs/copyright.html
|
|
|
|
Uses an MIT (or Modified BSD)-style license that is as liberal as
|
|
possible. Some of the source files that deal with KRB4 have Original
|
|
BSD-style announce-clause licenses. You may not distribute binaries
|
|
with krb4-enabled libcurl that also link with GPL-licensed code!
|
|
|
|
OpenSSL http://www.openssl.org/source/license.html
|
|
|
|
(May be used for SSL/TLS support) Uses an Original BSD-style license
|
|
with an announcement clause that makes it "incompatible" with GPL. You
|
|
are not allowed to ship binaries that link with OpenSSL that includes
|
|
GPL code (unless that specific GPL code includes an exception for
|
|
OpenSSL - a habit that is growing more and more common). If OpenSSL's
|
|
licensing is a problem for you, consider using GnuTLS or yassl
|
|
instead.
|
|
|
|
GnuTLS http://www.gnutls.org/
|
|
|
|
(May be used for SSL/TLS support) Uses the LGPL[3] license. If this is
|
|
a problem for you, consider using OpenSSL instead. Also note that
|
|
GnuTLS itself depends on and uses other libs (libgcrypt and
|
|
libgpg-error) and they too are LGPL- or GPL-licensed.
|
|
|
|
yassl http://www.yassl.com/
|
|
|
|
(May be used for SSL/TLS support) Uses the GPL[1] license. If this is
|
|
a problem for you, consider using OpenSSL or GnuTLS instead.
|
|
|
|
NSS http://www.mozilla.org/projects/security/pki/nss/
|
|
|
|
(May be used for SSL/TLS support) Is covered by the MPL[4] license,
|
|
the GPL[1] license and the LGPL[3] license. You may choose to license
|
|
the code under MPL terms, GPL terms, or LGPL terms. These licenses
|
|
grant you different permissions and impose different obligations. You
|
|
should select the license that best meets your needs.
|
|
|
|
axTLS http://axtls.sourceforge.net/
|
|
|
|
(May be used for SSL/TLS support) Uses a Modified BSD-style license.
|
|
|
|
c-ares http://daniel.haxx.se/projects/c-ares/license.html
|
|
|
|
(Used for asynchronous name resolves) Uses an MIT license that is very
|
|
liberal and imposes no restrictions on any other library or part you
|
|
may link with.
|
|
|
|
zlib http://www.gzip.org/zlib/zlib_license.html
|
|
|
|
(Used for compressed Transfer-Encoding support) Uses an MIT-style
|
|
license that shouldn't collide with any other library.
|
|
|
|
krb4
|
|
|
|
While nothing in particular says that a Kerberos4 library must use any
|
|
particular license, the one I've tried and used successfully so far
|
|
(kth-krb4) is partly Original BSD-licensed with the announcement
|
|
clause. Some of the code in libcurl that is written to deal with
|
|
Kerberos4 is Modified BSD-licensed.
|
|
|
|
MIT Kerberos http://web.mit.edu/kerberos/www/dist/
|
|
|
|
(May be used for GSS support) MIT licensed, that shouldn't collide
|
|
with any other parts.
|
|
|
|
Heimdal http://www.pdc.kth.se/heimdal/
|
|
|
|
(May be used for GSS support) Heimdal is Original BSD licensed with
|
|
the announcement clause.
|
|
|
|
GNU GSS http://www.gnu.org/software/gss/
|
|
|
|
(May be used for GSS support) GNU GSS is GPL licensed. Note that you
|
|
may not distribute binary curl packages that uses this if you build
|
|
curl to also link and use any Original BSD licensed libraries!
|
|
|
|
libidn http://josefsson.org/libidn/
|
|
|
|
(Used for IDNA support) Uses the GNU Lesser General Public
|
|
License [3]. LGPL is a variation of GPL with slightly less aggressive
|
|
"copyleft". This license requires more requirements to be met when
|
|
distributing binaries, see the license for details. Also note that if
|
|
you distribute a binary that includes this library, you must also
|
|
include the full LGPL license text. Please properly point out what
|
|
parts of the distributed package that the license addresses.
|
|
|
|
OpenLDAP http://www.openldap.org/software/release/license.html
|
|
|
|
(Used for LDAP support) Uses a Modified BSD-style license. Since
|
|
libcurl uses OpenLDAP as a shared library only, I have not heard of
|
|
anyone that ships OpenLDAP linked with libcurl in an app.
|
|
|
|
libssh2 http://www.libssh2.org/
|
|
|
|
(Used for scp and sftp support) libssh2 uses a Modified BSD-style
|
|
license.
|
|
|
|
[1] = GPL - GNU General Public License: http://www.gnu.org/licenses/gpl.html
|
|
[2] = http://www.fsf.org/licenses/gpl-faq.html#GPLIncompatibleLibs details on
|
|
how to write such an exception to the GPL
|
|
[3] = LGPL - GNU Lesser General Public License:
|
|
http://www.gnu.org/licenses/lgpl.html
|
|
[4] = MPL - Mozilla Public License:
|
|
http://www.mozilla.org/MPL/
|