The workaround suggested (https://github.com/krb5/krb5/commit/26d8744129) is still valid, and appears on upstream's 1.12 release branch already (as https://github.com/krb5/krb5/commit/c7bb9278ad12c9). It will appear in the 1.12.2 release. Furthermore, I have applied it to the Debian packaging as http://anonscm.debian.org/cgit/pkg-k5-afs/debian-krb5-2013.git/commit/?id=3d3bf0c075af62f278b6 (though it has not yet been uploaded to Debian proper). This workaround should not introduce any regressions.
I should also note that, if I understand correctly, we expect a no-change rebuild of krb5 using the gcc currently in utopic to also be a valid workaround. However, the gcc in trusty is still expected to produce krb5 packages which exhibit this bug.
The workaround suggested (https:/ /github. com/krb5/ krb5/commit/ 26d8744129) is still valid, and appears on upstream's 1.12 release branch already (as https:/ /github. com/krb5/ krb5/commit/ c7bb9278ad12c9). It will appear in the 1.12.2 release. Furthermore, I have applied it to the Debian packaging as http:// anonscm. debian. org/cgit/ pkg-k5- afs/debian- krb5-2013. git/commit/ ?id=3d3bf0c075a f62f278b6 (though it has not yet been uploaded to Debian proper). This workaround should not introduce any regressions.
I should also note that, if I understand correctly, we expect a no-change rebuild of krb5 using the gcc currently in utopic to also be a valid workaround. However, the gcc in trusty is still expected to produce krb5 packages which exhibit this bug.