>>>>> "Sam" == Sam Hartman <hartmans@debian.org> writes:
>>>>> "Sebastian" == Sebastian Ramacher <sramacher@debian.org> writes:
>>> I've uploaded to unstable. There's what tracker lists as a
>>> regression in CI tests:
>>> https://ci.debian.net/data/autopkgtest/testing/ppc64el/s/squid/8297228/log.gz
>>>
>>> I don't think that regression looks caused by krb5 after
>>> examining the log.
Sebastian> Looks like some symbols were removed without bumping the
Sebastian> SONAME of librkb5 (#975344).
Sam> Sure. These symbols were never part of the public API. The
Sam> public api is defined by krb5.h without defining KRB5_PRIVATE.
Sam> The symbols were defined in k5-int.h, which is not even an
Sam> installed header. I mean I agree we need to block the
Sam> transition until we figure out what to do about things, but
Sam> this doesn't seem like krb5's fault. I'm responding to that
Sam> bug in a moment.
Oof. If you take a look at src/mit-internals.h in the
libapache2-mod-auth-kerb sources, you'll see the scope of the problem.
Significant internals were copied from the krb5 sources (2005 era code)
directly into the libapache2-mod-auth-kerb sources.
My surprise is that it worked for 15 years not that it's breaking now.
I'm uploading a version of krb5 to unstable that breaks
libapache2-mod-auth-kerb.
I realize unversioned breaks are bad (and this situation is bad) but I
hope to replace that with a versioned breaks assuming we find a fix.
I note that libapache2-mod-auth-kerb seems to be QA maintained
effectively in Debian.
I haven't looked at upstream to see if they have a fix.
I'll dig into that after the upload.
Attachment:
signature.asc
Description: PGP signature