[1202] in athena10
[Sam Hartman] Transition: krb5 to drop Kerberos IV (libkrb53 restructuring)
daemon@ATHENA.MIT.EDU (Sam Hartman)
Sun Feb 22 19:41:38 2009
From: Sam Hartman <hartmans@debian.org>
To: debathena@mit.edu
Date: Sun, 22 Feb 2009 19:40:45 -0500
Message-ID: <tslab8ec7ea.fsf@mit.edu>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="==-=-="
--==-=-=
Hi, folks. I wanted to let you know that will be removing krb4 from
Debian unstable in the very near future.
This does not directly affect athena10 as it will take a while for
this to get into Ubuntu and of course it will not get into existing Ubuntu releases.
However it will be an issue for SIPB and people using debathena
packages on Debian.
My hope is that you will transition away from krb4 as well--using
passwords to access mail until NIST permits GSS-API authentication.
However if you do choose to retain krb4 support I think it would be
highly desirable to do so in a way that will not make it harder for
you to take the krb5 1.7 packages. In particular I think it would be
really bad to simply replace the krb5 packages with ones that do
enable krb4.
Instead, I'd do something like create a new source package that takes
k5-int.h and other dependencies from a krb5 source tree and builds
krb4 libraries. That way, you could presumably drop in a k5-int.h
from 1.7 when that becomes an issue and build krb4 libraries that
would work against 1.7. The main interaction between the krb4 and
krb5 libraries is the krb5int_accessor function.
I'd be happy to discuss either what is needed to avoid keeping krb4 in
debathena or to discuss ways of doing krb4 support that minimize
impacts to work on the krb5 package.
--==-=-=
Content-Type: message/rfc822
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
Return-Path: <bounce-debian-devel=debian.devel=mailboxes.suchdamage.org@lists.debian.org>
Received: from localhost ([unix socket])
by mail.suchdamage.org (Cyrus v2.2.13-Debian-2.2.13-10) with LMTPA;
Sun, 22 Feb 2009 18:31:10 -0500
X-Sieve: CMU Sieve 2.2
Received: from liszt.debian.org (liszt.debian.org [82.195.75.100])
(using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))
(No client certificate requested)
by mail.suchdamage.org (Postfix) with ESMTP id E706B2027F
for <debian.devel@mailboxes.suchdamage.org>; Sun, 22 Feb 2009 18:30:57 -0500 (EST)
Received: from localhost (localhost [127.0.0.1])
by liszt.debian.org (Postfix) with QMQP
id 042BE13A62FB; Sun, 22 Feb 2009 23:26:35 +0000 (UTC)
Old-Return-Path: <hartmans@debian.org>
X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on liszt.debian.org
X-Spam-Level:
X-Spam-Status: No, score=-2.8 required=4.0 tests=FVGT_m_MULTI_ODD,
IMPRONONCABLE_1,IMPRONONCABLE_2,LDO_WHITELIST,MURPHY_DRUGS_REL8,
MURPHY_WRONG_WORD2 autolearn=no version=3.2.3
X-Original-To: lists-debian-devel@liszt.debian.org
Delivered-To: lists-debian-devel@liszt.debian.org
Received: from localhost (localhost [127.0.0.1])
by liszt.debian.org (Postfix) with ESMTP id 4139713A62F8
for <lists-debian-devel@liszt.debian.org>; Sun, 22 Feb 2009 23:26:28 +0000 (UTC)
Received: from liszt.debian.org ([127.0.0.1])
by localhost (lists.debian.org [127.0.0.1]) (amavisd-new, port 2525)
with ESMTP id 23246-65 for <lists-debian-devel@liszt.debian.org>;
Sun, 22 Feb 2009 23:26:24 +0000 (UTC)
X-policyd-weight: using cached result; rate: -5
X-Greylist: delayed 569 seconds by postgrey-1.27 at liszt; Sun, 22 Feb 2009 23:26:24 UTC
Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178])
(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
(Client did not present a certificate)
by liszt.debian.org (Postfix) with ESMTP id 9595B13A5798
for <debian-devel@lists.debian.org>; Sun, 22 Feb 2009 23:26:18 +0000 (UTC)
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042)
id 22C75423F; Sun, 22 Feb 2009 18:16:33 -0500 (EST)
From: Sam Hartman <hartmans@debian.org>
To: debian-devel@lists.debian.org
Cc: kstart@packages.debian.org,zephyr@packages.debian.org,owl@packages.debian.org
Subject: Transition: krb5 to drop Kerberos IV (libkrb53 restructuring)
User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux)
mail-copies-to: hartmans@debian.org
Date: Sun, 22 Feb 2009 18:16:17 -0500
Message-ID: <tsliqn2cbb2.fsf@mit.edu>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-=";
micalg=pgp-sha1; protocol="application/pgp-signature"
X-Virus-Scanned: at lists.debian.org with policy bank en-ht
X-Amavis-Spam-Status: No, score=-4.76 tagged_above=3.6 required=5.3
tests=[BAYES_00=-2, FVGT_m_MULTI_ODD=0.02, IMPRONONCABLE_1=1,
IMPRONONCABLE_2=1, LDO_WHITELIST=-5, MURPHY_DRUGS_REL8=0.02,
MURPHY_WRONG_WORD2=0.2]
X-Rc-Virus: 2007-09-13_01
X-Rc-Spam: 2008-11-04_01
Resent-Message-ID: <HoiW2dNOspO.A.x8E.q8doJB@liszt>
Resent-From: debian-devel@lists.debian.org
X-Mailing-List: <debian-devel@lists.debian.org> archive/latest/247016
X-Loop: debian-devel@lists.debian.org
List-Id: <debian-devel.lists.debian.org>
List-Post: <mailto:debian-devel@lists.debian.org>
List-Help: <mailto:debian-devel-request@lists.debian.org?subject=help>
List-Subscribe: <mailto:debian-devel-request@lists.debian.org?subject=subscribe>
List-Unsubscribe: <mailto:debian-devel-request@lists.debian.org?subject=unsubscribe>
Precedence: list
Resent-Sender: debian-devel-request@lists.debian.org
Resent-Date: Sun, 22 Feb 2009 23:26:35 +0000 (UTC)
X-DSPAM-Result: Innocent
X-DSPAM-Processed: Sun Feb 22 18:31:10 2009
X-DSPAM-Confidence: 0.9989
X-DSPAM-Probability: 0.0000
X-DSPAM-Signature: 8042,49a1e03e21681731772882
X-DSPAM-Factors: 27,
Content-Type*multipart/signed, 0.00010,
Content-Type*signature", 0.00010,
From*Hartman+<hartmans, 0.00010,
Received*(Client, 0.00011,
List-Help*request, 0.00014,
List-Subscribe*<mailto, 0.00019,
List-Post*<mailto, 0.00019,
List-Help*<mailto, 0.00021,
Content-Type*boundary="=+=, 0.00052,
Content-Type*sha1, 0.00052,
Content-Type*=+=", 0.00052,
Content-Type*application/pgp+signature, 0.00083,
Content-Type*application/pgp, 0.00083,
X-Greylist*22, 0.00104,
User-Agent*(gnu/linux), 0.00119,
User-Agent*Emacs/21.4, 0.00119,
User-Agent*(No+Gnus, 0.00119,
X-Greylist*26, 0.00139,
Message-ID*mit.edu>, 0.00139,
X-Greylist*by, 0.00148,
X-Greylist*delayed, 0.00149,
X-Greylist*24, 0.00166,
Precedence*list, 0.00171,
User-Agent*Gnus, 0.00175,
User-Agent*(No, 0.00177,
Received*Feb+2009, 0.99822,
Received*Feb+2009, 0.99822
--=-=-=
Content-Transfer-Encoding: quoted-printable
[There are some questions at the end; comments would be greatly
appreciated on the questions if you have ever been involved in the
release process or library transitions before. This is my first big
transition.]
The libkrb53 package (providing the MIT Kerberos shared libraries) has
been stable for the last eight years. However, in 2006, MIT announced
its plans to remove support for the Kerberos 4 protocol [1]. Kerberos
5 has been the current version of Kerberos since the mid 1990s;
increasing security and code quality concerns motivated MIT's
decision. In the upcoming 1.7 release of MIT Kerberos, the code will
be removed. However, for well over 10 years, MIT Kerberos supports
building with the Kerberos 4 code disabled.
[1] http://web.mit.edu/kerberos/krb4-end-of-life.html=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20
I believe in managing things in small chunks. I'd rather handle
removing Kerberos 4 independently of upgrading to a new version of
Kerberos (1.7). As such, I plan to turn off Kerberos 4 in Debian
unstable in the very near future. Only two packages in Debian
actually rely on krb4 support: kstart and zephyr. In the case of
kstart, I believe disabling krb4 support will be relatively simple.
In the case of zephyr, things are more complicated because most of the
zephyr community uses krb4 to authenticate access. The zephyr
maintainer is well aware of the krb4 issue and has been working to
resolve it. I do not believe keeping krb4 support in Debian for
zephyr makes sense, especially since it would definitely be removed on
the 1.7 release of krb5. Two additional packages (barnowl and owl)
link against libkrb4 but use no symbols from that library.
However, things are more complicated. The krb4 and krb5 shared
libraries are all in the libkrb53 package. Since libraries will be
removed, that package name needs to change. I propose to split out
each library into a single package per our current best practice. See
the version of the krb5 package in experimental for specific details
of the split.
I propose to upload a version of krb5 to unstable in about a week that
is basically identical to the krb5 in experimental. I will include
some debconf fixes, a news file, and other minor changes. See the
experimental branch of [2] for ongoing work towards this upload.
[2] git://git.debian.org/git/pkg-k5-afs/debian-krb5.git
Unfortunately, there are a lot of packages that reverse depend on
libkrb53. All of these packages will need to be rebuilt.
Here's where I need sanity checking.
I assume that after the new krb5 has made its way into unstable and
has built on all arches, I should send mail to all these packages
asking them to upload a new version built against the new krb5. I
assume that some time (1 week?) later, I should do a mass bug filing
against anything that is still uninstallable in unstable because of a
libkrb53 dependency. I assume that doing NMUs to fix these bugs would
be appropriate. Do I have things right so far?
When I file bugs, do I advise people to upgrade their build
dependencies to the version of krb5 that introduces the new library
packages? Clearly the packages need to be built against that version
for unstable. However it seems like that build dependency would make
things like backports harder. Would it be better to have an explicit
build dependency or just make sure that things are rebuilt after krb5
is built on all arches?
Also, note that the ABI of the libraries that will remain is *not*
changing. (In a somewhat related note, the soname of libraries that
remain will not need to change for 1.7; we won't expect any transition
beyond the krb5 package at that point). So, packages not using the
krb4 libraries would actually work fine against the libkrb53 in
testing. It seems like if I use an alternative dependency in the
symbols files for the new package, I could allow packages rebuilt for
unstable to migrate into testing ahead of the new version of krb5.
That is, if I made the dependency in libkrb5-3.symbols look like
libkrb5-3|libkrb53 (and similar changes for other symbols files), then
both the packages in unstable and testing would satisfy the
dependencies. It seems like this would significantly reduce the
impact of the transition. Am I missing something or would this change
be a good idea?
Attached is a list of the packages that appear to reverse-depend on
libkrb53.
Thanks for your consideration and review,
=2D-Sam
alpine
aolserver4-nsimap
asterisk-bristuff
asterisk-classic
audispd-plugins
auditd
autofs5-ldap
balsa
barnowl
bind9
bind9-host
bind9utils
bitstormlite
boinc-client
boinc-manager
centericq
centericq-fribidi
centericq-utf8
cgi-mapserver
crossfire-client
crossfire-client-gtk
crossfire-client-gtk2
crossfire-client-x11
cups
cups-driver-gutenprint
cupsddk
cupsddk-drivers
curl
cvsnt
diatheke
dnsutils
dovecot-common
epdfview
etpan-ng
evolution-data-server
fetchmail
flickcurl-utils
freeradius-krb5
ghostscript
gmyth-utils
gnustep-gui-runtime
gpredict
gtklp
gtorrent-viewer
heirloom-mailx
iceape-browser
iceweasel
inn2
ipopd
ipsec-tools
jabberd2
jp2a
kdelibs4c2a
kdelibs5
krb5-auth-dialog
kredentials
kstart
libapache-mod-php4
libapache-mod-php5
libapache2-mod-auth-kerb
libapache2-mod-php4
libapache2-mod-php5
libapache2-mod-php5filter
libapache2-webauth
libauthen-krb5-perl
libauthen-krb5-simple-perl
libc-client2002edebian
libc-client2007b
libcamel1.2-10
libcamel1.2-11
libcamel1.2-8
libclamav2
libcups2
libcurl3
libcurl3-gnutls
libdns43
libdns45
libexchange-storage1.2-1
libexchange-storage1.2-3
libflickcurl0
libgnomecups1.0-1
libgnomeprint2.2-0
libgnomevfs2-extra
libgs8
libgsasl7
libgssapi-perl
libgtk2.0-0
libkrb5-ruby1.8
libkrb5-ruby1.9
liblua5.1-curl0
libmail-cclient-perl
libneon27
libneon27-gnutls
libnet-cups-perl
libnss-ldap
libnss-ldapd
libpam-afs-session
libpam-krb5
libpam-pkcs11
libpam-smbpass
libpq4
libpq5
libremctl1
libroot5.18
libsasl2-modules-gssapi-mit
libsmbclient
libsword6
libtinymail-camel-1.0-0
libtunepimp5
libwebauth1
libwfut-0.2-1
libzephyr3-krb
lprng
lwresd
mailsync
mailutils
mailutils-imap4d
mailutils-mh
mailutils-pop3d
mapserver-bin
mpop
msmtp
mutt
mutt-patched
nepenthes
netatalk
netsurf
nfs-common
nfs-kernel-server
openafs-krb5
openssh-client
openssh-server
owl
perl-mapscript
php4-cgi
php4-cli
php4-curl
php4-imap
php4-mapscript
php5-cgi
php5-cli
php5-curl
php5-imap
php5-mapscript
pike7.6-core
postgresql-7.4
postgresql-8.1
postgresql-8.3
postgresql-client-7.4
postman
python-kerberos
python-mapscript
python-pycurl
python-pycurl-dbg
python-remctl
python-samba
racoon
remctl-server
root-plugin-krb5
root-system-proofd
root-system-rootd
root-system-xrootd
rpm
rsyslog-gssapi
samba
samba-common
samba-tools
sasl2-bin
smbclient
smbfs
squid
swat
tla
tshark
uw-imapd
uw-mailutils
wfut
winbind
wireshark
wireshark-common
xfprint4
xpp
zephyr-server-krb
--=-=-=
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAkmh3MEACgkQ/I12czyGJg+2JACfbFVaECtHSJkFwwDz9oO0DBYv
VVMAn0H8prG70cv3L1QfoHxFG4ExV+o4
=NhWR
-----END PGP SIGNATURE-----
--=-=-=--
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
--==-=-=--
