On Fri, Sep 23, 2022 at 12:09:45AM +0200, Ondřej Surý wrote: > Nope, the plan to follow upstream releases was acked by both the security > and release teams, so I am not doing anything really surprising here.
Well, it is really surprising to users :-) Other packages that have been doing the same thing (e.g. firefox and chromium) have been explicit about fixing-by-wholesale-upgrading in the advisory in the past. > So, let’s focus on what could be improved here. I don’t think anything like > this will happen ever again in 9.16, but I’ll try to be more vigilant about > possibly breaking changes next time. > > Also Steinar, while I understand this has caused you some distress, this is > not really a grave bug. It does not make: the package in question unusable > or mostly so, or causes data loss, or introduces a security hole allowing > access to the accounts of users who use the package. I'm fine with downgrading the severity (it's mostly semantics anyway); but do note that security updates are treated differently from nearly every other update. In particular, unattended-upgrades will install them by default, and administrators are urged to install them as quickly as possible on their production servers without testing in a staging environment first. This makes them much more sensitive than a normal stable update, which goes through proposed-stable-updates first. In our case, it happened to break the entire system; it uses 127.0.0.1 in resolv.conf, and login uses Kerberos, which is dependent on DNS... Note that if we add “inline-signing yes;” on all of the zones with dnssec-policy on, BIND crashes with an assertion failure on reloading the config: Sep 22 22:32:52 cirkus named[3064511]: rbtdb.c:6837: REQUIRE(((rbtnode->nsec == DNS_RBT_NSEC_NSEC3 && (rdataset->type == ((dns_rdatatype_t)dns_rdatatype_nsec3) || rdataset->covers == ((dns_rdatatype_t)dns_rdatatype_nsec3))) || (rbtnode->nsec != DNS_RBT_NSEC_NSEC3 && rdataset->type != ((dns_rdatatype_t)dns_rdatatype_nsec3) && rdataset->covers != ((dns_rdatatype_t)dns_rdatatype_nsec3)))) failed, back trace Sep 22 22:32:52 cirkus named[3064511]: #0 0x55dd86375f1d in ?? Sep 22 22:32:52 cirkus named[3064511]: #1 0x7fddb899090a in ?? Sep 22 22:32:52 cirkus named[3064511]: #2 0x7fddb8ac981c in ?? Sep 22 22:32:52 cirkus named[3064511]: #3 0x7fddb8b9a461 in ?? Sep 22 22:32:52 cirkus named[3064511]: #4 0x7fddb89c36bd in ?? Sep 22 22:32:52 cirkus named[3064511]: #5 0x7fddb89ac6a9 in ?? Sep 22 22:32:52 cirkus named[3064511]: #6 0x7fddb89ac825 in ?? Sep 22 22:32:52 cirkus named[3064511]: #7 0x7fddb89ad003 in ?? Sep 22 22:32:52 cirkus named[3064511]: #8 0x7fddb876ee7d in ?? Sep 22 22:32:52 cirkus named[3064511]: #9 0x7fddb8780a23 in ?? Sep 22 22:32:52 cirkus named[3064511]: #10 0x7fddb876f714 in ?? Sep 22 22:32:52 cirkus named[3064511]: #11 0x7fddb89ac8d7 in ?? Sep 22 22:32:52 cirkus named[3064511]: #12 0x7fddb89c5ec6 in ?? Sep 22 22:32:52 cirkus named[3064511]: #13 0x7fddb8745ea7 in ?? Sep 22 22:32:52 cirkus named[3064511]: #14 0x7fddb8327aef in ?? Sep 22 22:32:52 cirkus named[3064511]: exiting (due to assertion failure) This is the old version, though, so it might be better with the new one. > As I said in the other email, I’ll take a look if I can soften the > requirement for the configuration in the Debian package tomorrow. Perhaps > just downgrade it to a prominent warning instead of hard error. That would be most appreciated, yes. /* Steinar */ -- Homepage: https://www.sesse.net/
