From bugzilla at redhat.com Sun Feb 3 17:37:09 2008 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 3 Feb 2008 12:37:09 -0500 Subject: [Bug 237533] CVE-2007-2165: proftpd auth bypass vulnerability In-Reply-To: Message-ID: <200802031737.m13Hb9qs002732@bz-web1.app.phx.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: CVE-2007-2165: proftpd auth bypass vulnerability Alias: CVE-2007-2165 https://bugzilla.redhat.com/show_bug.cgi?id=237533 bugzilla at redhat.com changed: What |Removed |Added ---------------------------------------------------------------------------- Version|f8test3 |8 ------- Additional Comments From matthias at rpmforge.net 2008-02-03 12:37 EST ------- I'm confused. The package in F-7 updates has been newer than that one in F-8 for ages, and I haven't received any nag mails about it. Still they're all 1.3.1, so the security fix is included. Nevertheless, I'll be pushing 1.3.1-3 as an F-8 update. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Sun Feb 3 17:41:39 2008 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 3 Feb 2008 12:41:39 -0500 Subject: [Bug 237533] CVE-2007-2165: proftpd auth bypass vulnerability In-Reply-To: Message-ID: <200802031741.m13HfdBQ003447@bz-web1.app.phx.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: CVE-2007-2165: proftpd auth bypass vulnerability Alias: CVE-2007-2165 https://bugzilla.redhat.com/show_bug.cgi?id=237533 ------- Additional Comments From kevin at tummy.com 2008-02-03 12:41 EST ------- How about also updating EPEL-5 too? It has version 1.3.0a still... -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Sun Feb 3 17:47:26 2008 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 3 Feb 2008 12:47:26 -0500 Subject: [Bug 237533] CVE-2007-2165: proftpd auth bypass vulnerability In-Reply-To: Message-ID: <200802031747.m13HlQsd004266@bz-web1.app.phx.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: CVE-2007-2165: proftpd auth bypass vulnerability Alias: CVE-2007-2165 https://bugzilla.redhat.com/show_bug.cgi?id=237533 ------- Additional Comments From matthias at rpmforge.net 2008-02-03 12:47 EST ------- (In reply to comment #10) > How about also updating EPEL-5 too? > It has version 1.3.0a still... Ouch, you're absolutely right! I'll do that now. I still can't reproduce the EL-4 build failure from bug #250223 on my machine, so I think I'll give up on EL-4 proftpd, though. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Sun Feb 3 18:12:58 2008 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 3 Feb 2008 13:12:58 -0500 Subject: [Bug 237533] CVE-2007-2165: proftpd auth bypass vulnerability In-Reply-To: Message-ID: <200802031812.m13ICwe9008593@bz-web1.app.phx.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: CVE-2007-2165: proftpd auth bypass vulnerability Alias: CVE-2007-2165 https://bugzilla.redhat.com/show_bug.cgi?id=237533 matthias at rpmforge.net changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |CLOSED Resolution| |CURRENTRELEASE ------- Additional Comments From matthias at rpmforge.net 2008-02-03 13:12 EST ------- Both EL-5 and EL4 build fine, so those are updated too now. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From jake at lwn.net Thu Feb 14 15:25:19 2008 From: jake at lwn.net (Jake Edge) Date: Thu, 14 Feb 2008 08:25:19 -0700 Subject: whole pile o' updates Message-ID: <47B45D5F.2080206@lwn.net> (Josh Bressers suggested I send my questions here rather than asking him or someone else directly) Yesterday you folks released an enormous number of security updates. While I could selfishly complain about it being done on a Wednesday, my real issues are the following: - it seems deliberate that the same alert ID tag was reused (FEDORA-2008-1435 and FEDORA-2008-1535), it would seem to be a bit confusing to refer to multiple alerts with the same ID, take a peek at: http://lwn.net/Alerts/Fedora/ to see what I mean. - those were all related to the same gecko vulnerabilites, which is what (I presume) motivated reusing the same IDs, but at least one (perhaps two, I can't remember for sure) of those, ruby-gnome2 also fixed a separate CVE that was unrelated to the mozilla pile - How is it that so many packages were affected by these mozilla vulns? Are they statically linked? Reusing the code? Have very restrictive dynamic library version numbers? It just seems that a vulnerability in a component shouldn't necessarily have this kind of cascading effect. - Overall, we have been noticing a decline in the quality of Fedora security alerts. They are often missing basic information about what bug they are fixing (other than perhaps a reference to bugzilla, sometimes a link to the CVE). I think if you read a lot of those alerts as if you were just a plain old user, you would find that some provide very little useful information to try and determine what problem is being fixed. I can provide examples if necessary. Is there something that can be done to standardize the format a bit? thanks! jake -- Jake Edge - LWN - jake at lwn.net - http://lwn.net From jkeating at redhat.com Thu Feb 14 15:41:08 2008 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 14 Feb 2008 10:41:08 -0500 Subject: whole pile o' updates In-Reply-To: <47B45D5F.2080206@lwn.net> References: <47B45D5F.2080206@lwn.net> Message-ID: <20080214104108.2f18de91@redhat.com> On Thu, 14 Feb 2008 08:25:19 -0700 Jake Edge wrote: > - those were all related to the same gecko vulnerabilites, which is > what (I presume) motivated reusing the same IDs, but at least one > (perhaps two, I can't remember for sure) of those, ruby-gnome2 also > fixed a separate CVE that was unrelated to the mozilla pile > > - How is it that so many packages were affected by these mozilla > vulns? Are they statically linked? Reusing the code? Have very > restrictive dynamic library version numbers? It just seems that a > vulnerability in a component shouldn't necessarily have this kind of > cascading effect. Here is what happens. There are a /ton/ of packages in Fedora that build against gecko libs, or otherwise link to them. In Fedora 8, the gecko lib location would change every time gecko is rebuilt. So in order for these packages to continue working, they have to be rebuilt for the new location. So when a gecko security issue happens, a big pile of packages have to be rebuilt so that they'll work with the new gecko. In order to ensure that they all get pushed at the same time, all the builds are attached to a single update request in our update tool, bodhi. See https://admin.fedoraproject.org/updates/F8/FEDORA-2008-1535 As for ruby-gnome2's other CVE fix, that was released earlier in a different update, https://admin.fedoraproject.org/updates/F8/FEDORA-2007-4216 > > - Overall, we have been noticing a decline in the quality of Fedora > security alerts. They are often missing basic information about what > bug they are fixing (other than perhaps a reference to bugzilla, > sometimes a link to the CVE). I think if you read a lot of those > alerts as if you were just a plain old user, you would find that some > provide very little useful information to try and determine what > problem is being fixed. I can provide examples if necessary. Is > there something that can be done to standardize the format a bit? Recently the Fedora project granted the Security team the task of reviewing all updates that are to go out tagged as security. It's the Security's responsibility to ensure that the messaging is correct. This is a fairly recent change so it may take a little bit to start to notice an overall trend back into the consistent messaging. Prior to this, all Fedora maintainers were able to generate whatever message they wanted to for security updates. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From lkundrak at redhat.com Thu Feb 14 15:53:09 2008 From: lkundrak at redhat.com (Lubomir Kundrak) Date: Thu, 14 Feb 2008 16:53:09 +0100 Subject: whole pile o' updates In-Reply-To: <47B45D5F.2080206@lwn.net> References: <47B45D5F.2080206@lwn.net> Message-ID: <1203004390.8631.67.camel@localhost.localdomain> Hi Jake, On Thu, 2008-02-14 at 08:25 -0700, Jake Edge wrote: > (Josh Bressers suggested I send my questions here rather than asking him > or someone else directly) > > Yesterday you folks released an enormous number of security updates. > While I could selfishly complain about it being done on a Wednesday, my > real issues are the following: > > - it seems deliberate that the same alert ID tag was reused > (FEDORA-2008-1435 and FEDORA-2008-1535), it would seem to be a bit > confusing to refer to multiple alerts with the same ID, take a peek at: > > http://lwn.net/Alerts/Fedora/ > > to see what I mean. Basically there are to be considered just two updates, FEDORA-2008-1535 for Fedora 8 gecko-libs issues and FEDORA-2008-1435 for Fedora 7 gecko-libs issues. 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 > - those were all related to the same gecko vulnerabilites, which is what > (I presume) motivated reusing the same IDs, but at least one (perhaps > two, I can't remember for sure) of those, ruby-gnome2 also fixed a > separate CVE that was unrelated to the mozilla pile > > - How is it that so many packages were affected by these mozilla vulns? > Are they statically linked? Reusing the code? Have very restrictive > dynamic library version numbers? It just seems that a vulnerability in > a component shouldn't necessarily have this kind of cascading effect. Due to upstream (Mozilla) policy on ABI stability, all packages that are dynamically linked to gecko libraries need to be rebuilt. (So basically you were correct, it's the "restrictive dynamic library version numbers"). This is definitely not ideal, but also not our fault -- situation is expected to improve a lot with advent of xulrunner in Fedora 9 though. I'm not expert on this, I might redirect you to our Mozilla guys if you need more information. They are all pushed as a single update to prevent dependency breakage and if the update contains a security fix it is marked as security update. It is possible that attack vectors don't exist for many of the packages. > - Overall, we have been noticing a decline in the quality of Fedora > security alerts. They are often missing basic information about what > bug they are fixing (other than perhaps a reference to bugzilla, > sometimes a link to the CVE). I think if you read a lot of those alerts > as if you were just a plain old user, you would find that some provide > very little useful information to try and determine what problem is > being fixed. I can provide examples if necessary. Is there something > that can be done to standardize the format a bit? We are attempting to concentrate the detail of fixed issues in bugzilla, while using descriptive titles of bugs. The update description relies upon decision of the maintainers. I was personally convinced that it is nod needed provided references to bugzilla are good enough. What can be done is to motivate the maintainers to provide useful descriptions. Luke: Would it be possible to complement "Notes:" in bodhi with something like: "Please provide 2-3 sentences to briefly describe nature of each of problems being fixed" or something like that? Thanks, -- Lubomir Kundrak (Red Hat Security Response Team) From jake at lwn.net Thu Feb 14 16:25:16 2008 From: jake at lwn.net (Jake Edge) Date: Thu, 14 Feb 2008 09:25:16 -0700 Subject: whole pile o' updates Message-ID: <47B46B6C.1000505@lwn.net> (sorry if this starts a new thread, you folks answered before I had a chance to subscribe :) Jesse wrote: > As for ruby-gnome2's other CVE fix, that was released earlier in a > different update, > https://admin.fedoraproject.org/updates/F8/FEDORA-2007-4216 So this getting into our system is an artifact of how we process the alerts. Our program looks for CVE references anywhere in the alert and believes the alert fixes those CVEs. In this case (and presumably others), that CVE was fixed in an earlier release and only appeared in the Changelog in the message. I have sometimes wondered about those changelogs. It would seem to me that unless they only refer to the changes since the last release, they are fairly confusing to someone reading them. Is there a way for a human (or program) to determine which of those changelog entries actually correspond to the changes in the release that goes with the alert? jake -- Jake Edge - LWN - jake at lwn.net - http://lwn.net From lmacken at redhat.com Thu Feb 14 18:05:16 2008 From: lmacken at redhat.com (Luke Macken) Date: Thu, 14 Feb 2008 13:05:16 -0500 Subject: whole pile o' updates In-Reply-To: <1203004390.8631.67.camel@localhost.localdomain> References: <47B45D5F.2080206@lwn.net> <1203004390.8631.67.camel@localhost.localdomain> Message-ID: <20080214180516.GA31194@crow> On Thu, Feb 14, 2008 at 04:53:09PM +0100, Lubomir Kundrak wrote: > Hi Jake, > > On Thu, 2008-02-14 at 08:25 -0700, Jake Edge wrote: > > (Josh Bressers suggested I send my questions here rather than asking him > > or someone else directly) > > > > Yesterday you folks released an enormous number of security updates. > > While I could selfishly complain about it being done on a Wednesday, my > > real issues are the following: > > > > - it seems deliberate that the same alert ID tag was reused > > (FEDORA-2008-1435 and FEDORA-2008-1535), it would seem to be a bit > > confusing to refer to multiple alerts with the same ID, take a peek at: > > > > http://lwn.net/Alerts/Fedora/ > > > > to see what I mean. > > Basically there are to be considered just two updates, > FEDORA-2008-1535 for Fedora 8 gecko-libs issues and > FEDORA-2008-1435 for Fedora 7 gecko-libs issues. 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. > 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. > > - Overall, we have been noticing a decline in the quality of Fedora > > security alerts. They are often missing basic information about what > > bug they are fixing (other than perhaps a reference to bugzilla, > > sometimes a link to the CVE). I think if you read a lot of those alerts > > as if you were just a plain old user, you would find that some provide > > very little useful information to try and determine what problem is > > being fixed. I can provide examples if necessary. Is there something > > that can be done to standardize the format a bit? > > We are attempting to concentrate the detail of fixed issues in bugzilla, > while using descriptive titles of bugs. The update description relies > upon decision of the maintainers. I was personally convinced that it is > nod needed provided references to bugzilla are good enough. > > What can be done is to motivate the maintainers to provide useful > descriptions. Luke: Would it be possible to complement "Notes:" in bodhi > with something like: "Please provide 2-3 sentences to briefly describe > nature of each of problems being fixed" or something like that? I agree that are security notices are lacking in detail. Encouraging developers to elaborate a bit more on the update notes may help, but that still doesn't give us any sort of standard advisory format to try and live up to. 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. At the moment some of this data exists in the bugzilla, but it's probably not obvious to our end users. If we want to keep this data in bugzilla, that's fine, but we need to make sure our users know where to find it. 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? I'm open to anything, really. Suggestions welcome. luke -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From thoger at redhat.com Fri Feb 15 16:10:22 2008 From: thoger at redhat.com (Tomas Hoger) Date: Fri, 15 Feb 2008 17:10:22 +0100 Subject: whole pile o' updates In-Reply-To: <20080214180516.GA31194@crow> References: <47B45D5F.2080206@lwn.net> <1203004390.8631.67.camel@localhost.localdomain> <20080214180516.GA31194@crow> Message-ID: <20080215171022.379d264f@redhat.com> On Thu, 14 Feb 2008 13:05:16 -0500 Luke Macken 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/.../ as soon as possible or let them wait just that users with 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-- Additionally, following packages were rebuilt to work correctly with updated packages listed above: epiphany-- galeon-- [...] 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 From peak at argo.troja.mff.cuni.cz Sun Feb 17 18:07:57 2008 From: peak at argo.troja.mff.cuni.cz (Pavel Kankovsky) Date: Sun, 17 Feb 2008 19:07:57 +0100 (CET) Subject: whole pile o' updates In-Reply-To: <20080214104108.2f18de91@redhat.com> Message-ID: <20080217190749.841.0@paddy.troja.mff.cuni.cz> On Thu, 14 Feb 2008, Jesse Keating wrote: > There are a /ton/ of packages in Fedora that build against gecko libs, > or otherwise link to them. In Fedora 8, the gecko lib location would > change every time gecko is rebuilt. This is rather silly, isn't it? --Pavel Kankovsky aka Peak [ Boycott Microsoft--http://www.vcnet.com/bms ] "Resistance is futile. Open your source code and prepare for assimilation." From jkeating at redhat.com Sun Feb 17 19:30:37 2008 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 17 Feb 2008 14:30:37 -0500 Subject: whole pile o' updates In-Reply-To: <20080217190749.841.0@paddy.troja.mff.cuni.cz> References: <20080214104108.2f18de91@redhat.com> <20080217190749.841.0@paddy.troja.mff.cuni.cz> Message-ID: <20080217143037.66974056@redhat.com> On Sun, 17 Feb 2008 19:07:57 +0100 (CET) Pavel Kankovsky wrote: > This is rather silly, isn't it? I didn't say that it wasn't. Blame mozilla.org. They're "fixing" it somewhat with xulrunner though. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From lmacken at redhat.com Tue Feb 19 14:17:44 2008 From: lmacken at redhat.com (Luke Macken) Date: Tue, 19 Feb 2008 09:17:44 -0500 Subject: whole pile o' updates In-Reply-To: <20080215171022.379d264f@redhat.com> References: <47B45D5F.2080206@lwn.net> <1203004390.8631.67.camel@localhost.localdomain> <20080214180516.GA31194@crow> <20080215171022.379d264f@redhat.com> Message-ID: <20080219141744.GB5195@crow> On Fri, Feb 15, 2008 at 05:10:22PM +0100, Tomas Hoger wrote: > On Thu, 14 Feb 2008 13:05:16 -0500 Luke Macken > 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/.../ as soon as possible > or let them wait just that users with 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-- > > Additionally, following packages were rebuilt to work correctly with > updated packages listed above: > > epiphany-- > galeon-- > [...] > > 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 From lmacken at redhat.com Tue Feb 19 15:05:38 2008 From: lmacken at redhat.com (Luke Macken) Date: Tue, 19 Feb 2008 10:05:38 -0500 Subject: whole pile o' updates In-Reply-To: <47B46B6C.1000505@lwn.net> References: <47B46B6C.1000505@lwn.net> Message-ID: <20080219150538.GF5195@crow> On Thu, Feb 14, 2008 at 09:25:16AM -0700, Jake Edge wrote: > (sorry if this starts a new thread, you folks answered before I had a > chance to subscribe :) > > Jesse wrote: > > > As for ruby-gnome2's other CVE fix, that was released earlier in a > > different update, > > https://admin.fedoraproject.org/updates/F8/FEDORA-2007-4216 > > So this getting into our system is an artifact of how we process the > alerts. Our program looks for CVE references anywhere in the alert and > believes the alert fixes those CVEs. In this case (and presumably others), > that CVE was fixed in an earlier release and only appeared in the Changelog > in the message. > > I have sometimes wondered about those changelogs. It would seem to me that > unless they only refer to the changes since the last release, they are > fairly confusing to someone reading them. Is there a way for a human (or > program) to determine which of those changelog entries actually correspond > to the changes in the release that goes with the alert? The changelogs are /supposed/ to be from the last time that package was updated. However, there are still some bugs that need to get worked out in the generation of these. luke From lkundrak at redhat.com Fri Feb 22 13:12:51 2008 From: lkundrak at redhat.com (Lubomir Kundrak) Date: Fri, 22 Feb 2008 14:12:51 +0100 Subject: Reading DRAM modules after loss of power Message-ID: <1203685971.8258.14.camel@localhost.localdomain> Is this a hoax? http://citp.princeton.edu/memory/exp/ I thought there was a good reason for DRAM memory cells to be refreshed every 64ms. Anyone tried that? -- Lubomir Kundrak (Red Hat Security Response Team) From ivazqueznet at gmail.com Fri Feb 22 16:29:40 2008 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Fri, 22 Feb 2008 11:29:40 -0500 Subject: Reading DRAM modules after loss of power In-Reply-To: <1203685971.8258.14.camel@localhost.localdomain> References: <1203685971.8258.14.camel@localhost.localdomain> Message-ID: <1203697780.6446.43.camel@ignacio.lan> On Fri, 2008-02-22 at 14:12 +0100, Lubomir Kundrak wrote: > Is this a hoax? > http://citp.princeton.edu/memory/exp/ > > I thought there was a good reason for DRAM memory cells to be refreshed > every 64ms. Anyone tried that? The discharge curve of DRAM is logarithmic, not linear; it's still possible to have enough charge for the discriminators to pick up even after several minutes of discharge. So yes, this is entirely feasible. And no, there's nothing we (Fedora) can do about it. -- Ignacio Vazquez-Abrams PLEASE don't CC me; I'm already subscribed -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From lkundrak at redhat.com Sun Feb 24 10:28:25 2008 From: lkundrak at redhat.com (Lubomir Kundrak) Date: Sun, 24 Feb 2008 11:28:25 +0100 Subject: whole pile o' updates In-Reply-To: <20080219150538.GF5195@crow> References: <47B46B6C.1000505@lwn.net> <20080219150538.GF5195@crow> Message-ID: <1203848905.4652.3.camel@localhost.localdomain> On Tue, 2008-02-19 at 10:05 -0500, Luke Macken wrote: > On Thu, Feb 14, 2008 at 09:25:16AM -0700, Jake Edge wrote: > > (sorry if this starts a new thread, you folks answered before I had a > > chance to subscribe :) > > > > Jesse wrote: > > > > > As for ruby-gnome2's other CVE fix, that was released earlier in a > > > different update, > > > https://admin.fedoraproject.org/updates/F8/FEDORA-2007-4216 > > > > So this getting into our system is an artifact of how we process the > > alerts. Our program looks for CVE references anywhere in the alert and > > believes the alert fixes those CVEs. In this case (and presumably others), > > that CVE was fixed in an earlier release and only appeared in the Changelog > > in the message. > > > > I have sometimes wondered about those changelogs. It would seem to me that > > unless they only refer to the changes since the last release, they are > > fairly confusing to someone reading them. Is there a way for a human (or > > program) to determine which of those changelog entries actually correspond > > to the changes in the release that goes with the alert? > > The changelogs are /supposed/ to be from the last time that package was > updated. However, there are still some bugs that need to get worked out > in the generation of these. At present time they are not of much use, and generally they are likely to contain duplicate or uninteresting (to package consumer; like formatting changes or license tag change) entries. What's interesting is fixed bugs which are covered by references section and packager can point out other interesting changes in notes. There are indeed cases that they are useful or at least nice to have, but for updates that fix multiple packages (thing mozilla) they can be really hard to be included in a bearable fashion. -- Lubomir Kundrak (Red Hat Security Response Team) From lkundrak at redhat.com Sun Feb 24 10:30:01 2008 From: lkundrak at redhat.com (Lubomir Kundrak) Date: Sun, 24 Feb 2008 11:30:01 +0100 Subject: whole pile o' updates In-Reply-To: <47B45D5F.2080206@lwn.net> References: <47B45D5F.2080206@lwn.net> Message-ID: <1203849001.4652.6.camel@localhost.localdomain> On Thu, 2008-02-14 at 08:25 -0700, Jake Edge wrote: > (Josh Bressers suggested I send my questions here rather than asking > him > or someone else directly) > > Yesterday you folks released an enormous number of security updates. > While I could selfishly complain about it being done on a Wednesday, > my > real issues are the following: (...lot of stuff) https://fedorahosted.org/fedora-infrastructure/ticket/392#comment:2 We're eager to hear your comments. -- Lubomir Kundrak (Red Hat Security Response Team) From jake at lwn.net Sun Feb 24 21:09:49 2008 From: jake at lwn.net (Jake Edge) Date: Sun, 24 Feb 2008 14:09:49 -0700 Subject: whole pile o' updates In-Reply-To: <1203849001.4652.6.camel@localhost.localdomain> References: <47B45D5F.2080206@lwn.net> <1203849001.4652.6.camel@localhost.localdomain> Message-ID: <47C1DD1D.6040702@lwn.net> Lubomir Kundrak wrote: > https://fedorahosted.org/fedora-infrastructure/ticket/392#comment:2 > We're eager to hear your comments. I think my questions were answered. I like what I see in the template for security reports and the fact that y'all are giving them some attention at the moment. I definitely agree that changelogs are only interesting if they reflect the changes in the package for that release (unlike they sometimes have in the past). If it is 'easy', it would be helpful to update readers to have the CVE references be links to CVE or NVD rather than just link to the redhat bugzilla ... jake -- Jake Edge - LWN - jake at lwn.net - http://lwn.net From lkundrak at redhat.com Mon Feb 25 13:48:26 2008 From: lkundrak at redhat.com (Lubomir Kundrak) Date: Mon, 25 Feb 2008 14:48:26 +0100 Subject: whole pile o' updates In-Reply-To: <47C1DD1D.6040702@lwn.net> References: <47B45D5F.2080206@lwn.net> <1203849001.4652.6.camel@localhost.localdomain> <47C1DD1D.6040702@lwn.net> Message-ID: <1203947306.4652.30.camel@localhost.localdomain> On Sun, 2008-02-24 at 14:09 -0700, Jake Edge wrote: > Lubomir Kundrak wrote: > > > https://fedorahosted.org/fedora-infrastructure/ticket/392#comment:2 > > We're eager to hear your comments. > > I think my questions were answered. I like what I see in the template > for security reports and the fact that y'all are giving them some > attention at the moment. I definitely agree that changelogs are only > interesting if they reflect the changes in the package for that release > (unlike they sometimes have in the past). > > If it is 'easy', it would be helpful to update readers to have the CVE > references be links to CVE or NVD rather than just link to the redhat > bugzilla ... Our decision was not to, because: 1.) Sometimes we get the CVE name after we ship the update, and unlike the update mails, we can easily update bugzilla. 2.) In most cases our bugzilla contains verbatim copy of the CVE text, and in all cases it has links to CVE, NVD and alias that is equal to the CVE name. Our bugzilla even substitutes the CVE names with links to CVE. Regards, -- Lubomir Kundrak (Red Hat Security Response Team) From jake at lwn.net Tue Feb 26 19:19:06 2008 From: jake at lwn.net (Jake Edge) Date: Tue, 26 Feb 2008 12:19:06 -0700 Subject: whole pile o' updates In-Reply-To: <1203947306.4652.30.camel@localhost.localdomain> References: <47B45D5F.2080206@lwn.net> <1203849001.4652.6.camel@localhost.localdomain> <47C1DD1D.6040702@lwn.net> <1203947306.4652.30.camel@localhost.localdomain> Message-ID: <47C4662A.5040905@lwn.net> Lubomir Kundrak wrote: > On Sun, 2008-02-24 at 14:09 -0700, Jake Edge wrote: >> If it is 'easy', it would be helpful to update readers to have the CVE >> references be links to CVE or NVD rather than just link to the redhat >> bugzilla ... > > Our decision was not to, because: > > 1.) Sometimes we get the CVE name after we ship the update, and unlike > the update mails, we can easily update bugzilla. > > 2.) In most cases our bugzilla contains verbatim copy of the CVE text, > and in all cases it has links to CVE, NVD and alias that is equal to the > CVE name. Our bugzilla even substitutes the CVE names with links to CVE. Ok, I am looking at today's (or maybe late yesterday's) report for qemu for F7: FEDORA-2008-2001 It doesn't list the CVE number, so I click through to bugzilla, which does list the CVE number (as an Alias), but doesn't link to CVE/NVD (which is just a placeholder at this point anyway, but will presumably be updated soon). Does the changelog reflect the changes in this release? Which would imply that there are fixes for other, non-security bugs in the release. It just strikes me as difficult for people receiving the advisories (or reading them on our or other sites) to figure out the *exact* bug being fixed without a CVE reference in the advisory. Maybe the timing is too tight, but that is very unfortunate. jake -- Jake Edge - LWN - jake at lwn.net - http://lwn.net From lmacken at redhat.com Tue Feb 26 20:51:47 2008 From: lmacken at redhat.com (Luke Macken) Date: Tue, 26 Feb 2008 15:51:47 -0500 Subject: whole pile o' updates In-Reply-To: <47C4662A.5040905@lwn.net> References: <47B45D5F.2080206@lwn.net> <1203849001.4652.6.camel@localhost.localdomain> <47C1DD1D.6040702@lwn.net> <1203947306.4652.30.camel@localhost.localdomain> <47C4662A.5040905@lwn.net> Message-ID: <20080226205147.GC4888@crow.redhat.com> On Tue, Feb 26, 2008 at 12:19:06PM -0700, Jake Edge wrote: > Lubomir Kundrak wrote: >> On Sun, 2008-02-24 at 14:09 -0700, Jake Edge wrote: > >>> If it is 'easy', it would be helpful to update readers to have the CVE >>> references be links to CVE or NVD rather than just link to the redhat >>> bugzilla ... >> >> Our decision was not to, because: >> >> 1.) Sometimes we get the CVE name after we ship the update, and unlike >> the update mails, we can easily update bugzilla. >> >> 2.) In most cases our bugzilla contains verbatim copy of the CVE text, >> and in all cases it has links to CVE, NVD and alias that is equal to the >> CVE name. Our bugzilla even substitutes the CVE names with links to CVE. > > Ok, I am looking at today's (or maybe late yesterday's) report for qemu for > F7: FEDORA-2008-2001 > > It doesn't list the CVE number, so I click through to bugzilla, which does > list the CVE number (as an Alias), but doesn't link to CVE/NVD (which is > just a placeholder at this point anyway, but will presumably be updated > soon). The summary of security bugs are *supposed* to begin with the CVE id, according to the security bug tracking procedure[0]. It looks like this update got added to our updates system before the bug summary was properly updated. > Does the changelog reflect the changes in this release? Which would imply > that there are fixes for other, non-security bugs in the release. Yes, the ChangeLog /should/ be the changes in that package, for that release, from the last update of that package. It looks like the F7 qemu update[1] pulled in a bit too much of the changelog. The F8 notice looks fine, but the F7 changelog mentions qemu-0.9.0-3.fc7[2], which was pushed as a bugfix update in October. As far as I can tell, it looks like Lubomir is proposing[3] to remove the RPM ChangeLogs all together from our security notices, which would help mitigate the inconsistencies mentioned above. However, I have a feeling that many people would complain if the changelogs disappeared. I'm all for removing it, but I think it may be worth assessing what kind of value we want these changelogs to provide vs. the value they are actually providing to the end user. With all of the proper bugs listed, and fairly informative update details, I'm not sure what value the RPM changelog provide alongside of them ? > It just strikes me as difficult for people receiving the advisories (or > reading them on our or other sites) to figure out the *exact* bug being > fixed without a CVE reference in the advisory. Maybe the timing is too > tight, but that is very unfortunate. I agree, I think we should be linking to CVEs somewhere, at *least* from the bodhi-view of updates[4]. I can easily make all CVE ids in the bug titles linkable back to mitre within bodhi, but whether or not we put the CVE urls along with the Bugzillas in the references in our advisories is still up for discussion. Thanks for your input on this, Jake. It's always good to have someone on the outside to let us know when stuff doesn't make sense :) luke [0]: http://fedoraproject.org/wiki/Security/TrackingBugs [1]: https://www.redhat.com/archives/fedora-package-announce/2008-February/msg00857.html [2]: https://www.redhat.com/archives/fedora-package-announce/2007-October/msg00043.html [3]: https://fedorahosted.org/fedora-infrastructure/ticket/392#comment:2 [4]: https://admin.fedoraproject.org/updates/FEDORA-2008-2001 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: