We processed a huge number of KDE security announcements for F18 last week: https://lwn.net/Articles/553900/ ... but the comments on that article indicate that almost all of them are not actually security fixes and are, instead, some kind of koji overreach? seemingly the same pile of fixes showed up for F17 yesterday ... is it just kdeplasma-addons that needs to be highlighted (perhaps with a mention that koji cascaded the bug into a bunch of unaffected packages?) ... or is there more? or are they truly all affected?
thanks,
jake
On Sun, 16 Jun 2013 08:31:19 -0600 Jake Edge jake@lwn.net wrote:
We processed a huge number of KDE security announcements for F18 last week: https://lwn.net/Articles/553900/ ... but the comments on that article indicate that almost all of them are not actually security fixes and are, instead, some kind of koji overreach? seemingly the same pile of fixes showed up for F17 yesterday ... is it just kdeplasma-addons that needs to be highlighted (perhaps with a mention that koji cascaded the bug into a bunch of unaffected packages?) ... or is there more? or are they truly all affected?
This is due to this being 1 single update with all the kde packages.
See:
https://admin.fedoraproject.org/updates/FEDORA-2013-10182/
So, all those packages are all "FEDORA-2013-10182"
and since you can only mark the single update security or not, the entire thing (and all packages) are marked security.
I don't know if this will be handled any better in bodhi 2.0, but we could surely look and try and handle things better. What would you like to see for an update like this? Different names for each package? Or some what to tag only those package(s) that are security updates?
kevin
On Sun, 16 Jun 2013 10:33:23 -0600 Kevin Fenzi wrote:
On Sun, 16 Jun 2013 08:31:19 -0600 Jake Edge jake@lwn.net wrote:
We processed a huge number of KDE security announcements for F18 last week: https://lwn.net/Articles/553900/ ... but the comments on that article indicate that almost all of them are not actually security fixes and are, instead, some kind of koji overreach? seemingly the same pile of fixes showed up for F17 yesterday ... is it just kdeplasma-addons that needs to be highlighted (perhaps with a mention that koji cascaded the bug into a bunch of unaffected packages?) ... or is there more? or are they truly all affected?
This is due to this being 1 single update with all the kde packages.
See:
https://admin.fedoraproject.org/updates/FEDORA-2013-10182/
So, all those packages are all "FEDORA-2013-10182"
and since you can only mark the single update security or not, the entire thing (and all packages) are marked security.
What I don't quite follow is whether all of those packages are in fact updated for security reasons or whether this is just an artifact of bodhi (or koji or something) ... I am sensing the latter ...
does 'kdepimlibs' or 'kdeedu' (to pick two at random) need to be updated for *security* reasons? or just because it got tagged with one (?) package that was updated to the same upstream revision (kdeplasma-addons ... others?)
I don't know if this will be handled any better in bodhi 2.0, but we could surely look and try and handle things better. What would you like to see for an update like this? Different names for each package? Or some what to tag only those package(s) that are security updates?
Well, I would think Fedora users would only want things that are actually security updates to marked as such ... or are all these packages dependent on the Plasma add-ons somehow? That's what's confusing here imo ...
jake
On Sun, 16 Jun 2013 10:39:34 -0600 Jake Edge jake@lwn.net wrote:
What I don't quite follow is whether all of those packages are in fact updated for security reasons or whether this is just an artifact of bodhi (or koji or something) ... I am sensing the latter ...
I'm not sure. :)
I think the issue was in a single package, but it may have needed the others updated as well if the fix was moving to a newer upstream version of that one package.
does 'kdepimlibs' or 'kdeedu' (to pick two at random) need to be updated for *security* reasons? or just because it got tagged with one (?) package that was updated to the same upstream revision (kdeplasma-addons ... others?)
Not sure. Or it could be that the one security update needed newer versions of the rest of the packages. I guess we should ask kde folks.
I don't know if this will be handled any better in bodhi 2.0, but we could surely look and try and handle things better. What would you like to see for an update like this? Different names for each package? Or some what to tag only those package(s) that are security updates?
Well, I would think Fedora users would only want things that are actually security updates to marked as such ... or are all these packages dependent on the Plasma add-ons somehow? That's what's confusing here imo ...
Yes, I think that version of plasma add-ons needs the newer rest of the kde stack, but not sure.
Copying kde maintainer here for some more info...
kevin
On 06/17/2013 09:12 PM, Kevin Fenzi wrote:
On Sun, 16 Jun 2013 10:39:34 -0600 Jake Edge jake@lwn.net wrote:
What I don't quite follow is whether all of those packages are in fact updated for security reasons or whether this is just an artifact of bodhi (or koji or something) ... I am sensing the latter ...
I'm not sure. :)
I think the issue was in a single package, but it may have needed the others updated as well if the fix was moving to a newer upstream version of that one package.
For what it's worth (with my KDE SIG maintainer hat on), it was a minor security issue in a single package (kdeplasma-addons), and we bundled the fix into a bigger kde-4.10.4 batch update, for what it's worth.
-- Rex
Hi Jake!
On Sun, 16 Jun 2013 10:39:34 -0600 Jake Edge wrote:
This is due to this being 1 single update with all the kde packages.
See:
https://admin.fedoraproject.org/updates/FEDORA-2013-10182/
So, all those packages are all "FEDORA-2013-10182"
and since you can only mark the single update security or not, the entire thing (and all packages) are marked security.
What I don't quite follow is whether all of those packages are in fact updated for security reasons or whether this is just an artifact of bodhi (or koji or something) ... I am sensing the latter ...
You can consider this an artifact of Bodhi (update system), or more of how it is used.
Bodhi allows creating update requests with multiple packages. Those are expected to be used when updating set of closely related packages that should either be all updated (updated as pushed to testing or stable repository) at once or not at all. E.g. various KDE sub packages may have strict versioned dependencies on a base KDE library package, or NSS update usually requires that all nss, nss-util and nss-softoken are updated in sync. Basically to avoid having some packages pushed to stable (because one package gets positive karma from a user who tested it with all packages from the set installed) while other are still in testing, leading to various problems.
There was a similar thread here started by you few years ago. It seems comments there remain relevant and may be a good reference.
https://lists.fedoraproject.org/pipermail/security/2008-February/001284.html
I presume change this was of a lower priority than other Bodhi changes that happened since then.
I don't know if this will be handled any better in bodhi 2.0, but we could surely look and try and handle things better. What would you like to see for an update like this? Different names for each package? Or some what to tag only those package(s) that are security updates?
Well, I would think Fedora users would only want things that are actually security updates to marked as such ... or are all these packages dependent on the Plasma add-ons somehow?
In this case, there's a security fix in kdeplasma-addons. Other packages are part of the same update request as it primarily is a "update to KDE 4.10.4" update. Without the security fix, this would contain the same set of packages, only update request would be of type bug fix or enhancement, rather than security.
This can be improved, either in tool (e.g. via ability to flag only specific components in an update request as security), or process (require 1 component per update request, or ask maintainers to split such requests to at least two, one with security and other with the rest, or via better update description, which would not help your automated processing I believe). All of those changes requires some additional effort, and I do not know if there is sufficient motivation to go that way.
Hi Tomas,
On Tue, 18 Jun 2013 13:03:20 +0200 Tomas Hoger wrote:
There was a similar thread here started by you few years ago. It seems comments there remain relevant and may be a good reference.
https://lists.fedoraproject.org/pipermail/security/2008-February/001284.html
related but not quite the same as all of those were actually linked to the library in question, so all of them really did need to be upgraded, which is not the case here ...
In this case, there's a security fix in kdeplasma-addons. Other packages are part of the same update request as it primarily is a "update to KDE 4.10.4" update. Without the security fix, this would contain the same set of packages, only update request would be of type bug fix or enhancement, rather than security.
Right, so some theoretical user that uses kdeedu, but not kdeplasma-addons (maybe they use those programs on GNOME?) does not really need to upgrade ... or at least not urgently ... so the upgrade being tagged as "SECURITY" is misleading (or wrong, really).
This can be improved, either in tool (e.g. via ability to flag only specific components in an update request as security), or process (require 1 component per update request, or ask maintainers to split such requests to at least two, one with security and other with the rest, or via better update description, which would not help your automated processing I believe). All of those changes requires some additional effort, and I do not know if there is sufficient motivation to go that way.
I would think that package maintainers would want to separate out the security piece as a separate update, even if updating that will pull in a bunch of not-directly-affected packages too (via the yum dependency resolution stuff) ... thus not "requiring" folks only using unaffected packages to update ...
our automated processing still has a fairly large human component, so better descriptions can only help there ... but the crux of the matter is that imo packages which are not being updated for security fixes not be marked that way (i.e. only mark "SECURITY" on actual security fixes) ... as a Fedora user (entirely separate from our daily security update postings), that's what *I* would want to see, anyway ...
thanks,
jake
On Tue, 18 Jun 2013 07:57:36 -0600 Jake Edge wrote:
On Tue, 18 Jun 2013 13:03:20 +0200 Tomas Hoger wrote:
There was a similar thread here started by you few years ago. It seems comments there remain relevant and may be a good reference.
https://lists.fedoraproject.org/pipermail/security/2008-February/001284.html
related but not quite the same as all of those were actually linked to the library in question, so all of them really did need to be upgraded, which is not the case here ...
Fair enough. I just assume that you do not normally expect to have to update all applications that use some library that gets security fixes, even if they may expose the library bug. Hence related in terms of having packages not including security fix include in security update.
In this case, there's a security fix in kdeplasma-addons. Other packages are part of the same update request as it primarily is a "update to KDE 4.10.4" update. Without the security fix, this would contain the same set of packages, only update request would be of type bug fix or enhancement, rather than security.
Right, so some theoretical user that uses kdeedu, but not kdeplasma-addons (maybe they use those programs on GNOME?) does not really need to upgrade ... or at least not urgently ... so the upgrade being tagged as "SECURITY" is misleading (or wrong, really).
Correct.
security@lists.fedoraproject.org
-
Jake Edge -
Kevin Fenzi -
Rex Dieter -
Tomas Hoger