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.
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.
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.
Transition: krb5 to drop Kerberos IV (libkrb53 restructuring)
