Hi Christian! On Tue, 15 Mar 2011 22:29:11 +0100 Christian Krause wrote: > https://fedoraproject.org/wiki/Security/TrackingBugs > > From a maintainer's point of view this page needs some improvements: The page is fairly outdated and can definitely benefit from some improvement. > - the page lacks of the description of the very specific tasks for the > maintainers The fixing process for maintainer should not really differ from the normal bug fixing process, hence this part did not get much attention previously. I agree that it may be good to explicitly document "add that extra bug to bodhi update request, everything else is what already know quite well". > - some information is outdated and/or wrong - e.g. the description how > many tracking bugs are created More on that below. > I took the opportunity to clarify some parts of this page and I also > added a section with step-by-step instructions for the maintainers: > > https://fedoraproject.org/wiki/User:Chkr/Drafts/Security/TrackingBugs Few comments on the things that changed: - "don't explicitly refer to the CVE from in the notes text box, the reference is implicit created by referring both bugs" I think is based on old "There is no need to refer to CVE from Bodhi, security bugzillas allways refer to CVE themselves", which was about a bit different thing. Bodhi used to have an extra "CVE list" field. That field was obsoleted by a CVE listed inferred from CVE mentioned in the linked bugzillas. It's OK to mention CVE, upstream advisory id, upstream announcement, or any other useful info in the update Description. - "Bodhi is able to identify if a bug is a tracking bug and doesn't include it in the new package announce mail." I don't think that's true. See e.g.: https://lwn.net/Articles/431813/ which links BZ#638428. - "Bodhi closes the tracking bug, and in case all other bugs that Parent depends on it also closes the Parent." "To keep track, Bodhi adds comments to both Parent and Tracking bug." That's broken currently and Bodhi does not update Security Response bugs at all: https://fedorahosted.org/bodhi/ticket/485 For the unchanged text, there's no really much guarantee that CVE is assigned before update is pushed to stable. There's also problem with Bodhi caching, so BZ summary changes done after the bug was added to Bodhi are usually not picked up. That's where CVE in the Description has some benefits. > I find the idea of having multiple tracking bugs quite helpful since > it really simplifies the maintainer's job: He can make full use of > bodhi's feature to close the bug reports automatically. Not all maintainers view it the same. For some, it's sufficient to get CC on SR bug and frown upon having one extra fedora-all bug filed. Based on the past experience, there's attempt to file less bugs rather than more (fedora-all/epel-all if all versions affected, fedora-X if only some). That's even more nasty if you file lot of tracking bugs incorrectly (e.g. you've missed already built updates in koji, or the fact that some issue is not compiled in). If we want to go back to an old "separate bug for each affected version", we probably want to have it discussed on devel and/or reviewed by FESCo. > a) the security engineer (who opens the security bugs) checks, which > Fedora branches are affected and creates the appropriate tracking bugs > or > b) the step-by-step section could contain the explicit suggestion that > the maintainer could (or should?) create the appropriate number of > tracking bugs for each release himself We should think of a way to mark SR bugs as needing further triage. RH SRT folks may not always have time to look in detail on all Fedora / EPEL branches for every issue. So it may be better to note that based on the available info, this should affect certain Fedora and EPEL versions and ask for another pair of eyes to double-check before annoying someone with lot of incorrect bugs. Thank you for your feedback and asking about your concerns! -- Tomas Hoger / Red Hat Security Response Team -- security mailing list security@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/security
