[ Benjamin Kaduk ]
* New upstream prerelease:
- Add support for accessing KDCs via an https proxy using the MS-KKDCP
protocol, using a plugin provided by the new krb5-k5tls package, which
uses openssl for the TLS implementation. The openssl-using code is
confined to a separate, runtime-loadable, plugin module, in a separate
package, to ameliorate concerns about GPL code that links libkrb5 running
into issues with the openssl license. The Kerberos license is both
GPL and OpenSSL compatible. There might be an issue if an application
was GPL licensed and someone used the OpenSSL plugin with that
application. Even that is probably fine provided that no one
distributes a combination that tends to encourage such usage. There's
an existing krb5-pkinit plugin that also links to OpenSSL, but at time
of integration into Debian no GPLed applications in the archive called
APIs that would cause that plugin to be loaded.
The above concerns are still valid, and given that currently OpenSSL is neither GPLv2 or GPLv3 compatible doing this may not be feasible immediately.
The licensing choices will have to be re-evaluated again, once OpenSSL v3 is the default OpenSSL implementation in the archive, which is GPLv3 compatible.
krb5 (1.13~alpha1+ dfsg-1) experimental; urgency=low
[ Benjamin Kaduk ]
* New upstream prerelease:
- Add support for accessing KDCs via an https proxy using the MS-KKDCP
protocol, using a plugin provided by the new krb5-k5tls package, which
uses openssl for the TLS implementation. The openssl-using code is
confined to a separate, runtime-loadable, plugin module, in a separate
package, to ameliorate concerns about GPL code that links libkrb5 running
into issues with the openssl license. The Kerberos license is both
GPL and OpenSSL compatible. There might be an issue if an application
was GPL licensed and someone used the OpenSSL plugin with that
application. Even that is probably fine provided that no one
distributes a combination that tends to encourage such usage. There's
an existing krb5-pkinit plugin that also links to OpenSSL, but at time
of integration into Debian no GPLed applications in the archive called
APIs that would cause that plugin to be loaded.
The above concerns are still valid, and given that currently OpenSSL is neither GPLv2 or GPLv3 compatible doing this may not be feasible immediately.
The licensing choices will have to be re-evaluated again, once OpenSSL v3 is the default OpenSSL implementation in the archive, which is GPLv3 compatible.