--- Begin Message ---
- To: Debian Bug Tracking System <submit@bugs.debian.org>
- Subject: unblock: krb5/1.18.3-5
- From: Sam Hartman <hartmans@debian.org>
- Date: Sun, 28 Mar 2021 14:13:29 -0400
- Message-id: <161695520878.1293136.14571770007530623733.reportbug@mount-peerless>
Package: release.debian.org
Severity: normal
User: release.debian.org@packages.debian.org
Usertags: unblock
Please review and give pre-approval comments for an upload of krb5.
[ Reason ]
In #985739 it was pointed out that internal symbols disappeared from libk5crypto.
My bad; I noticed this, confirmed they were not externally visible, approved the symbols file change, but didn't think about the upgrade implications.
What happens is that if the new libk5crypto3 is unpacked before the
new libkrb5-3, the old libkrb5-3 breaks. In the bug, the user managed
to get into a position where pam_krb5 was broken and logins didn't
work.
So, update the breaks, or add an equals binary:Version depends, no big, right?
While I wasn't looking, krb5 has apparently become part of
pseudo-essential.
login->libpam-modules->libnsl->libtirpc3->libgssapi-krb5-2->libk5crypto3|libkrb5-3
The only reason I even know that is because I've been tracking pam.
Long term, we don't want that.
As a result, it's probably the case in #985739 that pam_unix is broken as well as pam_krb5.
I'm not really an expert on all the ways that dependency resolution
gets complex for essential packages. I do know that dependencies for
essential packages are supposed to be pre-depends. That's not
currently the case for anything in krb5, or for libkeyutils,
libcomerr-2, etc.
So, we have a few options.
1) Add the breaks. Things are fairly stable in this part of the
dependency graph; it was 2016 when libk5crypto last had an
internally-incompatible break. That will probably work in practice.
On #debian-devel, Adrian Bunk argues that it should be a versioned conflicts not a break
because it's essential. I'm not sure--I think in most situations the
fact that you cannot unpack the breaking package without deconfiguring
the broken package means that apt will simply reorder things so that
libk5crypto3 comes before libkrb5-3 and all happens to be well with
the breaks.
2) Do we also want to add the pre-depends to krb5. I'm nervous adding
additional pre-depends this late in the process.
3) Do we want to add pre-depends to the entire dependency chain from
libpam-modules to libkeyutils|libcom-err2? I think this is
technically correct, but I am uncomfortable with it.
4) Do we want to do enough surgery to pam to avoid krb5 being
essential. With my pam hat on in January, I concluded it was too late
in the process for me to feel comfortable adequately testing a (not
yet developed) patch. That was before I realized how big of a deal it
might be that krb5 had become essential.
The solution basically involves making pam_unix dlopen its dependencies for nis rather than link-time dependencies. So, ugly games with c macros or wrappers trying to get some internally typed NIS APIs right.
I definitely do not have time to develop the patch, although I could potentially make time to review and help test.
I consider this risky for bullseye.
I think my recommendation is go approve the breaks change, and hope that's good enough in practice.
[ Tests ] (What automated or manual tests cover the affected code?)
I've done some manual tests to look at how apt tends to resolve
things. I realize that's horribly unreliable because of all the
complex dependencies someone might have.
One thing I have determined is that an = binary:version dependency from
libkrb5-3 to libk5crypto3 tends to make it more likely that apt will
pick the unpack order that breaks things.
[ Checklist ]
[x ] all changes are documented in the d/changelog
[x ] I reviewed all changes and I approve them
[x] attach debdiff against the package in testing
unblock krb5/1.18.3-5
diff --git a/debian/changelog b/debian/changelog
index e7224b1253..b0f668489d 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+krb5 (1.18.3-5) unstable; urgency=medium
+
+ * Update breaks on libk5crypto3 toward other internal libraries because
+ of removed internal symbols, Closes: #985739
+
+ -- Sam Hartman <hartmans@debian.org> Sun, 28 Mar 2021 13:43:01 -0400
+
krb5 (1.18.3-4) unstable; urgency=medium
diff --git a/debian/control b/debian/control
index 55fea8c334..c0e10fe25d 100644
--- a/debian/control
+++ b/debian/control
@@ -352,7 +352,7 @@ Description: MIT Kerberos runtime libraries - Administration Clients
Package: libk5crypto3
Section: libs
-Breaks: libkrb5-3 (<= 1.8~aa), libgssapi-krb5-2 (<= 1.10+dfsg~alpha1)
+Breaks: libkrb5-3 (<= 1.18~), libgssapi-krb5-2 (<= 1.18~)
Architecture: any
Depends: ${misc:Depends}, ${shlibs:Depends}
Suggests: krb5-doc, krb5-user
--- End Message ---