whole pile o' updates

[Tomas Hoger]

On Thu, 14 Feb 2008 13:05:16 -0500 Luke Macken <lmacken at redhat.com>
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