#740 Security updates should consult affected packages' maintainers to prevent breakages.
Closed None Opened 8 years ago by abbra.

= phenomenon =
FEDORA-2011-17400 brough nss update that fixed CVE-2011-3389. Unfortunately, the update was done without checking dependant packages and FreeIPA installation is now impossible in Fedora 16.

= background analysis =
Please see http://bugzilla.redhat.com/show_bug.cgi?id=771357 for details.

In this particular case CVE-2011-3389 was public since September 2011, Fedora updates were pushed in November.

https://bugzilla.redhat.com/show_bug.cgi?id=737506 contains details of the fix for Java packages.

nss fix came with upstream update of firefox 9.

This is fourth or more breakage for FreeIPA in second half of 2011 caused by neglected reverse dependency checks. In all cases updates for packages on which FreeIPA depends caused either semantical change in API or ABI.

= implementation recommendation =
I'd recomment implementing mandatory reverse depends checks for anything that:
- changes ABI
- changes API semantics without directly changing ABI

The first one could be detected for all ELF objects. The second one occurs with security fixes and should be taken seriously into account.

Upon detection of changes, affected package maintainers should be involved into update process.


The specific case in question was pushed alongside security fixes for Firefox and Thunderbird, which resulted in the NSS packages being pushed to stable through acquisition of stablekarma, despite several negative karma comments indicating its unsuitability for other purposes.

I'd like to suggest that we may want to disallow autokarma for critpath packages, so that at least the package owner must review any issues identified in the comments before pushing it to stable.

"fourth or more breakage for FreeIPA in second half of 2011"

Is this always NSS, or other packages as well?

No. Curl, 389-ds-base are other examples.

I'd also like to add that we've had similar issues with both Mozilla NSS and OpenLDAP in the SSSD in the last year. Changes to NSS broke certificate validation in SSSD for a while (https://bugzilla.redhat.com/show_bug.cgi?id=750376).

Similarly, SSSD is currently broken in rawhide due to https://bugzilla.redhat.com/show_bug.cgi?id=771484 (a regression in OpenLDAP).

Temporarily replacing my FESCo hat with my Red Hat hat...

I/Red Hat certainly won't stand in the way of such a check being added; it could be a good thing. However, I see some obvious communication/organization issues that can be tackled on the Red Hat side that can help here, and I'm intending to pursue that.

Meanwhile, carry on.

sgallagh, I do not think that we necessarily have to disallow autokarma for critpath packages completely. I'd say it would be sufficient to not allow lower than something autokarma setting for critpath and to automatically disable the autopush when there is negative karma comment (and that not only for critpath but for regular pkgs as well). So the maintainer when he gets a negative karma on update must request the push to stable manually.

Replying to [comment:8 tmraz]:

sgallagh, I do not think that we necessarily have to disallow autokarma for critpath packages completely. I'd say it would be sufficient to not allow lower than something autokarma setting for critpath and to automatically disable the autopush when there is negative karma comment (and that not only for critpath but for regular pkgs as well). So the maintainer when he gets a negative karma on update must request the push to stable manually.

Yes, I agree. My original comment was supposed to read "I'd like to suggest that we may want to disallow autokarma for critpath packages that have negative karma", but I mistyped. I don't know if we want to force this for non-critpath packages, as I know it's a fairly common issue to get "-1: this doesn't fix my bug that isn't reported as being fixed".

APPROVED, vote was +8, -0, 0:0. Bodhi process will be modified.

Login to comment on this ticket.

Metadata