For CVEs, we have own site listing each and what is affected, what is
not and whether fix is already available. CVE-2022-3924 [1] is not yet
released in RHEL. Of course if you look into upstream notes to check
what we have fixed in our distribution, it won't work well. Watching
your own distribution announces might help too, such as centos-announce
list [2].
[1] https://access.redhat.com/security/cve/CVE-2022-3924
[2]
https://lists.centos.org/pipermail/centos-announce/2023-March/thread.html
On 18. 04. 23 9:20, Havard Eidnes wrote:
You do not have to sift through lists.
That depends entirely what one wants to do. I see a couple of
scenarios where that may be required:
1) Let's say someone has flagged to you as a BIND administrator that
your BIND installatin is susceptible to CVE-2022-3924. This
could be done via an "external scan" and based on the BIND
version returned (if your BIND is configured to reveal such
details), or via other means. How do you as an administrator
figure out if the version you actually run has the fix for this
CVE included?
From the BIND change log, I can see
--- 9.16.37 released ---
6067. [security] Fix serve-stale crash when recursive clients soft quota
is reached. (CVE-2022-3924) [GL #3619]
and if I run straight "upstream" code, it's fairly straight-
forward to upgrade to this version, modulo, of course, the fact
that this involves building it from source.
On the other hand, looking at a version produced by a package
maintainer (RedHat, Debian, ...), and where the package
maintainer insists on sticking with whatever base version they
started from (strictly based on timing, in all probability) and
selectively applying patches, it will be much harder to figure
out whether the fix is actually included. And ... if the fix is
indeed included, you'll as administrator in all probability have
to mark the issue as "false positive" after having assured
yourself that the fix is included. However, getting to this
assurance can be quite a bit of work.
2) You will end up with a somewhat similar scenario for
non-security-related functionality fixes -- you may hit a
problem which has been fixed upstream since your distributor
forked off BIND, and you may be able to find the entry for the
fix in BIND's upstream change log, but figuring out if that
fix is indeed included in the code you run will make it
necessary to rummage through the "patch list" of the
package administrator.
Yes, that indeed is a bit tiresome. Our bugs often reference upstream
bugs if they fix them by upstream change backport. Or they are at least
related. But I do not know if our bugs can be searched by upstream bug
reference. It makes sense it should be possible and useful in few cases.
Useful especially for community distributions, because our customers can
just ask our support and they try to find it also in upstream issues.
And requests to include that fix. But I guess filling duplicate bugs is
not what we engineers would like, just because they were unable to find
already requested or fixed issue. Yes, we should try to improve that,
thank you for a suggestion!
It seems it can work on issues.redhat.com somehow, but
bugzilla.redhat.com does not offer simple way to search by upstream
issue link. Even if that is included in our bug.
We provide quite detailed git branch with each change we
make. It has references to bugs related too. I admit changes
listed in release notes of bind9 releases are nicer. But we do
not hide what and why we do changes, publish them quite nice
way for c9s [1]. It would be the same c8s as well soon.
For important changes they are mentioned in release notes of the minor
release. But I admit we do not mention explicitly each bug we fix the
way ISC does. It would make our documentation unreadable.
In any case, even if we fall behind a couple of releases, any our
packages of bind 9.16 are capable of automated DNSSEC deployment just
fine. Sure, even we do not support it for RHEL7 or older.
[1] https://gitlab.com/redhat/centos-stream/rpms/bind/-/commits/c9s
I certainly do appreciate that this is a considerable effort, and
that you do this as well as you can with all good intentions. Now,
even though the change log is available as stated (which is good, of
course) does not necessarily make it easy to find. And ... solving
the above two issues still requires a detailed sift through the
lists.
Regards,
- Håvard
Sure, in the end there is always some work required to do. We could
improve some things to require less work, but cannot eliminate it
altogether. I guess that is what you have meant.
Regards,
Petr
--
Petr Menšík
Software Engineer, RHEL
Red Hat, http://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
