On Thu, Jan 30, 2020 at 08:46:55AM -0600, Richard Shaw wrote:
Not replying to anyone in particular but to the thead as a whole...
1. Nothing in the packager introduction process prepares a packager for
what to do when they get a CVE filed against one of their packages. I found
the whole ordeal rather stressful.
FWIW, while it might look scary the first time a CVE is filed in
a package you maintainer, in a Fedora context there is little reason
to allow yourself to get stressed about dealing with the vast majority
Personally I find the most stressful part of CVE handling is dealing
with creation of patches for an embargoed bug, which I do frequently
for RHEL. This shouldn't apply in Fedora as the CVEs BZs in Fedora
are not filed until /after/ any embargo is lifted.
Most CVEs are going to be low/moderate, so you won't need to "drop
everything" to rush to fix them. Low bugs can certainly be dealt
with by simply waiting to rebase to next upstream release, and
arguably the same applies for most moderate bugs too.
The higher the severity of the bug, the more likely it is that a
patch will be clearly provided for you, having been prepared by
upstream and/or Red Hat security team who filed the BZ, or by
other distro/vendor engineers.
2. The process is somewhat confusing with all the linked bugs.
Yeah, can't disagree with that. Not very well documented either.
3. When there's a link to RHEL for details it's useless
unless you have a
RHEL account, so then I have to go find it somewhere else, I typically go
The bug that's filed against Fedora, should be marked as blocking
a parent "CVE tracker" bug. This parent bug ought to have the info
required for you to fix the issue. While this may initially be
private for embargoed bugs, the relevant information is supposed
to be made public once embargo lifts & so be visible to Fedora
maintainers when the Fedora BZ is filed.
If this is not the case, then do feel free to add comments to the
CVE against Fedora & put the bz in "needinfo" state on the person
who filed it.
If they still fail to provide sufficient info, then CANTFIX is
a valid outcome at least for low/moderate bugs
4. I'm not a C/C++ programmer and certainly not a security
expert. If I can
find a link to a fix for another distro, such as debian, I'll apply it but
more often than not there's nothing there when I look. I'll even file an
issue upstream but most of the time it's ignored.
Generally I'd expect that whoever filed the CVE bug in Fedora should
have already notified the upstream. This doesn't mean upstream has
actually responded or provided a patch, but they should at least know
about it. If upstream hasn't provided a patch, and nor has the Red
Hat security team, then the bug is likely going to be low/moderate
and can be ignored until a patch becomes available.
I would *NOT* expect Fedora maintainers to be writing code for
At the very most they should have to re-base a patch apply to the
version of the package Fedora ships. Given that, Fedora maintainers
should NOT need to be a C/C++ programmer to deal with CVEs filed in
Fedora, nor should they need to know much about secure programming
IOW, handling security fixes in Fedora should be *no different* from
fixing any other bugs in Fedora for the vast majority of cases. The
only differences are going to be when a bug is critical or high
severity, in which case the patch needs to be shipped in a faster
5. A of times it's for an EPEL package that's much older than
release so the fix for Fedora can't be easily applied to EPEL.
Yeah, backporting upstream patches to older versions is generally
the most painful part of things. This is a key reason why I don't
maintain EPEL branches for any of the stuff I package in Fedora.
So with all of that it seems the easiest thing to do is, well...
don't know if it's OK to close the bugs as WONTFIX or CANTFIX (seems
there's might be an option for low security bugs) or what else I can do
while I have a $DAYJOB and 120+ packages to maintain.
Yes, WONTFIX and CANTFIX are both *definitely* valid outcomes for
CVE fixes, most especially for low / moderate rated bugs. As is
just waiting for next upstream release to automatically pull in
For high/critical bugs you'll very likely be given a patch enabling
the bug to be easily patched, with at most needing rebasing to an
older version of the software.