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. 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? 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. > > 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. > 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. > 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? 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). Sorry for long and boring mail ;). -- Tomas Hoger Red Hat Security Response Team -- Fedora-security-list mailing list Fedora-security-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-security-list
