On Fri, Feb 15, 2008 at 05:10:22PM +0100, Tomas Hoger wrote: > On Thu, 14 Feb 2008 13:05:16 -0500 Luke Macken <lmacken@xxxxxxxxxx> > wrote: > > > This behavior has existed for while now, but seems to be confusing > > when we have updates that contain a ton of builds. I'm in the process > > of revamping a good chunk of bodhi's model, so if we wanted to make > > the updateID<->build relationship 1-to-1, now would be the time. > > For security update with bunch of rebuilds because of soname change, it > may be possible to have field for "packages that needed to be rebuild > because of changed dependencies". Those may be either announced as > separate bugfix updates or included in security announcement mail in > section that would indicate rebuild is the reason why packages are > updated. But on the other hand, I'm not sure this is worth the effort > because of one or two packages where such rebuilds are needed (firefox, > maybe clamav sometimes, any other?). > There's another question - are we going to continue pushing security fix > + rebuilds in one request? We already know this is confusing. Some developers push updates differently than others. Some put all packages and deps in 1 update, some submit individual requests. It's really just a matter of what fits their workflow the best (web submission, cli, etc). If a security update contains other packages in the same bodhi "update", each build still gets a separate email generated and sent to the list. If we're planning on generating multi-build update notices, then having a section for 'rebuilt dependencies' might be a good thing. > Additionally, such rebuilds may further delay push of fixed packages. > And here is another RelEng vs. Security question - do we prefer to push > update FF when all rebuilds are not yet ready to provide fixes to users > without epiphany/galeon/liferea/blam/.../<whatever> as soon as possible > or let them wait just that users with <long list here again> installed > won't see yum error message? We've gotten a little better at this over time, but it's still an issue that needs to be addressed. If we push a security fix without it's rebuilt dependencies, then isn't there a good chance that people won't be able to install this due to broken deps? Sounds like an issue that is best resolved server-side, instead of pushing brokenness on to our users. > And another note not related to security updates at all - there are > some updates where multiple nvrs in one request may make more sense, > e.g. KDE or xfce updates. Yeah. Again, that's really up to the developer. I'm thinking it might be useful to have bodhi keep track of which groups of packages have been pushed together, and allow developers to say "update the gnome stack", or something of the sort. > > > What is confusing here is that the announcement was split across > > > separate mails for each package. We are currently tracking the > > > problem for the the update system [1]. > > > > > > [1] https://fedorahosted.org/fedora-infrastructure/ticket/392 > > > > Suggestions welcome for how you want the multi-package update > > notification template to look. I'd be glad to implement it. > > Assuming special handling of security fix + rebuilds cases briefly > described above: > > Following package(s) address security issues: > > firefox-<ver>-<rel> > > Additionally, following packages were rebuilt to work correctly with > updated packages listed above: > > epiphany-<ver>-<rel> > galeon-<ver>-<rel> > [...] > > Which can probably be turned to more general concept (for both security > and non-security requests) - have field for nvrs that really fix some > bugs and other field for nvrs that are just rebuilds. Sounds good, but integrating this with our current template may be a little bit more difficult. Right now we have: Header (date, update ID) RPM Details (name, product, version, url, summary, description) Update Information (what the developer typed into bodhi) RPM ChangeLog References (bugzillas) Foot notes So, how do we want to handle multiple builds with the above template? We could possibly cut down the RPM Details to only display the nvr and summary, and then just stuff each builds ChangeLog together. > > Right now our update notices don't give any hint as to the severity of > > any given issue, as well as any details such as if it is > > remotely/locally exploitable, etc. > > Correct. Do we want to have that? Maybe yes. But it can hardly be > achieved without developer wanting to provide such info in the > updates. Current approval process will not help much unless reviewer > has time to fix up description and if (s)he has something to fix up at > the beginning. Yeah, true. It'll require more effort from the developers as well as the security team. Probably not the best use of our time at the moment. > > Maybe we could encourage developers / security team to elaborate a > > little on the impact of the issues as well in the description ? We > > could possibly add more fields other than just "Update Details", such > > as "Synopsis", "Impact", etc? > > Some of those fields might make sense. But will those be filled-in > right? Yeah, probably not. Again, this will require at least another set of eyes to revise this data before it gets approved. > Moreover, we should try to make our security updates CVE compatible. > We may need to have possibility to edit CVE id list even for older > updates, as CVE id may not be available at the time of submission or > may change later (splits / duplicate rejections / ...). Do we want to > delay pushing of updates until we have CVE id for the issues > addressed? It's not that rare that updates are pushed without CVE id > there days (which has pros in terms of fixes getting out quickly for > the price of inconsistency). I don't think we're actually not too far away from being "CVE Compatible" as it is. 1. CVE Searchable: A user can search using a CVE name to find related information. 2. CVE Output: Information is presented which includes the related CVE name(s). 3. Mapping: The repository owner has provided a mapping relative to a specific version of CVE, and has made a good faith effort to ensure accuracy of that mapping. 4. Documentation: The organization's standard documentation includes a description of CVE, CVE compatibility, and the details of how its customers can use the CVE-related functionality of its product or service. 1 and 2 are pretty much done ( may need a little bit of tweaking ). Not sure where we are with 3, but 4 should be pretty easy. Bodhi used to keep track of CVEs in it's own db table, but that recently changed as we now track them using Bugzilla, but it will still be easy to get bodhi to find & recognize them. Regarding delaying updates for CVE ids, I'm not quite sure where we stand with this. Sounds like an issue that needs to be addressed with our security update policy. luke -- Fedora-security-list mailing list Fedora-security-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-security-list
