Discussion:
Bug#868640: hdb_generate_key_set_password broke ABI
Add Reply
Ryan Tandy
2017-07-17 03:10:03 UTC
Reply
Permalink
Raw Message
Package: libhdb9-heimdal
Version: 7.4.0.dfsg.1-1
Severity: important
Control: affects -1 slapd-smbk5pwd

Dear maintainer,

In heimdal 7.2.0 the arguments to hdb_generate_key_set_password changed;
see https://github.com/heimdal/heimdal/issues/246

I just updated openldap to build against the new (old) signature, but
there was no library transition or symbols file update, so things still
break in the event of a partial upgrade.

Old slapd-smbk5pwd with new libhdb simply segfaults when the function is
called; I haven't tested the reverse but I suspect it would be the same.

thanks,
Ryan
Brian May
2017-07-17 08:00:02 UTC
Reply
Permalink
Raw Message
Post by Ryan Tandy
In heimdal 7.2.0 the arguments to hdb_generate_key_set_password changed;
see https://github.com/heimdal/heimdal/issues/246
I just updated openldap to build against the new (old) signature, but
there was no library transition or symbols file update, so things still
break in the event of a partial upgrade.
Old slapd-smbk5pwd with new libhdb simply segfaults when the function is
called; I haven't tested the reverse but I suspect it would be the same.
Thanks for the report.

Looks like this a fix for a previously undetected regression. i.e. it
changes the signature back to what it should have been. I fix that was
included in 7.4.0, that is now in unstable.

Unfortunately, as stable now has the bad signature, I really have no
idea what to do with this.

Suggestions? Maybe I should ask on debian-devel?
--
Brian May <***@debian.org>
Ryan Tandy
2017-07-17 15:30:01 UTC
Reply
Permalink
Raw Message
Hi Brian,
Post by Brian May
Looks like this a fix for a previously undetected regression. i.e. it
changes the signature back to what it should have been. I fix that was
included in 7.4.0, that is now in unstable.
Unfortunately, as stable now has the bad signature, I really have no
idea what to do with this.
Right. Unfortunately the different signature was in Debian for a long
time (since squeeze, I think). I for one always assumed the change was
intentional and it would just stay that way.
Post by Brian May
Suggestions? Maybe I should ask on debian-devel?
Possibly, yeah. The pedantic answer is this requires a SONAME bump and
transition; but that may be overkill in this case. smbk5pwd is for sure
the only user in Debian, and I'd be surprised if there are any external
users (maybe an occasional user building their own smbk5pwd).

A symbols file update would be nice, so future builds of slapd-smbk5pwd
pick up a minimum dependency. If libhdb would add a Breaks on
slapd-smbk5pwd (<< 2.4.44+dfsg-8), that would fix partial upgrades from
the other direction too.

thanks,
Ryan
Brian May
2017-07-17 22:30:01 UTC
Reply
Permalink
Raw Message
Post by Ryan Tandy
Right. Unfortunately the different signature was in Debian for a long
time (since squeeze, I think). I for one always assumed the change was
intentional and it would just stay that way.
Oh, yes, looks like you are right. I thought this was introduced in
Stretch, but looks like Wheezy and Jessie has it too.
Post by Ryan Tandy
Possibly, yeah. The pedantic answer is this requires a SONAME bump and
transition; but that may be overkill in this case. smbk5pwd is for sure
the only user in Debian, and I'd be surprised if there are any external
users (maybe an occasional user building their own smbk5pwd).
The problem with bumping the SONAME, is this means that we are forever
out of sync with the upstream SONAME.
Post by Ryan Tandy
A symbols file update would be nice, so future builds of slapd-smbk5pwd
pick up a minimum dependency. If libhdb would add a Breaks on
slapd-smbk5pwd (<< 2.4.44+dfsg-8), that would fix partial upgrades from
the other direction too.
We had a similar issue just before the release of Stretch. See
#848694. Two symbols were removed from the upstream library. Adding
breaks headers was suggested, but the release team strongly disliked
this solution.

We ended up patching these symbols back in.

I am not particularly keen on maintaining a growing set of patches that
maintain backward compatability for eternanity while deliberately
breaking compatability with other non-Debian-distributions however.
--
Brian May <***@debian.org>
Brian May
2017-07-17 22:40:02 UTC
Reply
Permalink
Raw Message
Hello Debian-Devel!

I have this tricky situation. It appears in 2011, upstream made a change
to Heimdal that broken the shared library ABI, and didn't change the
SONAME.

=== cut ===
commit af011f57fc4ae6e865bab471c20aa9047e4e19d4
Author: Roland C. Dowdeswell <***@imrryr.org>
Date: Mon Nov 28 15:18:52 2011 +0000

Provide server side kadm5_chpass_principal_3() with ks_tuple implementation.

We enable kadm5_chpass_principal_3() in the server side of the
library. The client kadm5 library calls will still return the
error KAMD5_KS_TUPLE_NO_SUPP.

Signed-off-by: Nicolas Williams <***@cryptonector.com>
=== cut ===

This change was undetected, and included in Debian in Wheezy, Jessie,
Stretch.

Now Upstream has realized their
error. https://github.com/heimdal/heimdal/issues/246

There response was to restore the ABI to the previous state. This change
is now in testing and unstable.

What should I do? It appears patch the ABI back to the previous state,
and break compatability with other distributions. Or I can keep it as it
and break upgrades.

Please read the bull details of 868640 for more information, and for
details of similar situation that occured before the Stretch
release. #848694
--
Brian May <***@debian.org>
Ryan Tandy
2017-07-18 07:20:02 UTC
Reply
Permalink
Raw Message
Post by Brian May
The problem with bumping the SONAME, is this means that we are forever
out of sync with the upstream SONAME.
One possible alternative is renaming the package without actually
bumping SONAME; for example libhdb9a. Then you get to re-sync with
upstream at the next increment.

Random examples: libdkim1d, libmutter0i, various toolchain transitions
(*c2a, *v5).
Post by Brian May
Post by Ryan Tandy
A symbols file update would be nice, so future builds of slapd-smbk5pwd
pick up a minimum dependency. If libhdb would add a Breaks on
slapd-smbk5pwd (<< 2.4.44+dfsg-8), that would fix partial upgrades from
the other direction too.
We had a similar issue just before the release of Stretch. See
#848694. Two symbols were removed from the upstream library. Adding
breaks headers was suggested, but the release team strongly disliked
this solution.
We ended up patching these symbols back in.
I am not particularly keen on maintaining a growing set of patches that
maintain backward compatability for eternanity while deliberately
breaking compatability with other non-Debian-distributions however.
I think following upstream on this one is the right thing to do. I don't
want to create extra work for you, but I do think we should handle this
breakage somehow since we know it can happen. If that's best achieved by
a change on the openldap side, I'm of course open to that too.

If you were to perform a transition for heimdal (the package rename
technique seems like it could apply to libroken as well), we're probably
at a good point in the release cycle for it...

thanks,
Ryan
Brian May
2017-07-18 08:00:03 UTC
Reply
Permalink
Raw Message
Post by Ryan Tandy
One possible alternative is renaming the package without actually
bumping SONAME; for example libhdb9a. Then you get to re-sync with
upstream at the next increment.
The obvious way to do this would be to remove the stupid -heimdal
postfix from these package names (it seemed like a good idea at the
time...). Should I limit this to just the two libraries with known
problems, or all the Heimdal libraries?

However, unfortunately, that would mean the new packages conflict with
the old packages, which is undesirable. Maybe the lesser evil however???
Post by Ryan Tandy
Post by Brian May
I am not particularly keen on maintaining a growing set of patches that
maintain backward compatability for eternanity while deliberately
breaking compatability with other non-Debian-distributions however.
I think following upstream on this one is the right thing to do. I don't
want to create extra work for you, but I do think we should handle this
breakage somehow since we know it can happen. If that's best achieved by
a change on the openldap side, I'm of course open to that too.
Yes, I much prefer following upstream. Means binaries are more likely to
work across distributions.

I only hope that upstream have finished breaking ABI compatability...
--
Brian May <***@debian.org>
Loading...