As noted in bug #12505, the embedded copy of heimdal in samba is outdated, at least in respect to the krb5_storage_free function and this seems to cause some crashes in samba at times. There are probably other bugs in samba's copy of heimdal that were fixed in heimdal upstream. https://git.samba.org/?p=samba.git;a=blob;f=source4/heimdal/lib/krb5/store.c;hb=HEAD#l270 https://github.com/heimdal/heimdal/blob/master/lib/krb5/store.c#L289 https://bugzilla.samba.org/show_bug.cgi?id=11824 https://bugzilla.samba.org/show_bug.cgi?id=12505 https://www.spinics.net/lists/samba/msg133243.html samba's copy of heimdal needs to either be deleted or constantly kept up to date with the latest upstream release. My personal preference would be to just delete it. Given the recent rate of heimdal upstream releases, deleting it would probably be less work in the long run. Given the recent security issue for heimdal (CVE-2017-11103), deleting it would probably result in less work for distro security teams, especially since samba builds take much longer than heimdal. https://github.com/heimdal/heimdal/releases https://orpheus-lyre.info/ If there are modifications to samba's copy of heimdal then it will need to be kept up to date instead. If possible, any such modifications should be sent upstream to heimdal. If they are not appropriate for upstream, then the release process for samba should be adjusted to include a check for the latest heimdal upstream release version.
We are well aware. This is more difficult than it looks however.
Fixed in 4.16
Thanks for updating the heimdal copy in samba! Since heimdal is bound to get new releases in the future, is there a process for ensuring that the heimdal copy in samba is updated before every new release of samba?
We continue to update to current Heimdal master when we need to bring in new features and so this is keeping it up to date. We have moved the Heimdal code to third_party/ to discourage local patching, which must now be done via the 'lorikeet-heimdal' tree, which we encourage to be rebased on Heimdal master, and encourage that, where possible, patches are first accepted upstream. Long term this work depends on developer resources being available.
Thanks for the info, that sounds like a reasonable approach.