FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 02-22-2009, 10:16 PM
Sam Hartman
 
Default Transition: krb5 to drop Kerberos IV (libkrb53 restructuring)

[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

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,

--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
 

Thread Tools




All times are GMT. The time now is 09:36 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org