On Mon, Mar 15, 2010 at 08:45:46PM +0100, Moritz Muehlenhoff wrote: > On Mon, Mar 15, 2010 at 01:39:08PM -0600, dann frazier wrote: > > On Mon, Mar 15, 2010 at 07:39:58PM +0100, Moritz Muehlenhoff wrote: > > > On Mon, Mar 15, 2010 at 12:13:06PM -0600, dann frazier wrote: > > > > On Mon, Mar 15, 2010 at 06:50:58PM +0100, Moritz Muehlenhoff wrote: > > > > > On 2010-03-15, dann frazier <[email protected]> wrote: > > > > > > On Mon, Mar 15, 2010 at 11:30:31AM -0400, David Miller wrote: > > > > > >> I've also been bitten by this bug - noticed it last Friday and it > > > > > >> doesn't seem to be fixed this morning. > > > > > >> > > > > > >> Is there an ETA on a fix with packages? > > > > > > > > > > > > Packages are now available in the security repo (an apt-get upgrade > > > > > > should suffice). > > > > > > > > > > > > I'm hoping to get a CVE ID before sending out a formal DSA. > > > > > > > > > > Why? That should be covered by the CVE ID for the original connector > > > > > security bug. > > > > > > > > Just to make sure we're talking about the same thing... > > > > > > > > One reason for this upload is to deal with the ABI breakage from the > > > > kernel upload which fixed CVE-2009-3725. I agree that no additional > > > > CVE is warranted to deal with that. > > > > > > > > However, as part of fixing this, we discovered that drbd contains a > > > > security issue as well. This issue is in the same class as the issues > > > > covered by CVE-2009-3725. However, CVE-2009-3725 has an explicit list > > > > of 4 subsystems it covers, and drbd is not one of them. > > > > > > Ack. But since the underlying issue is identical I don't think a separate > > > CVE ID is warranted. The CVE description can still be updated later if > > > needed. > > > > I would agree with the above if the same fix for issues 1-4 also fixed > > this issue - but in this case, it doesn't. > > > > All of these fixes required an underlying change in the connector > > subsystem (allowing the passing of creds into the callback). But, > > *using* that change requires a separate change in each subsystem. It > > is completely possible to fix one subsystem and leave the others > > unfixed. They will compile fine, though there would be a non-fatal > > compiler warning that could go unnoticed. > > > > I don't think it makes sense to go back and add drbd to the CVE after > > the fact, because it changes the semantics. It is quite possible that > > some other vendor is out there shipping drbd and has already fixed > > CVE-2009-3725. Doing an update instead of a new CVE may cause this > > additional issue to go unnoticed/unfixed. > > > > In other words I think that, once distros have fixed a CVE, it isn't > > ok to add more fixes to that CVE which contradict the distro's > > statement that the CVE is fixed. Particularly when a new CVE could be > > used instead. > > > > For some precedence, see the recent regression fixes in > > CVE-2009-453[6-8]. Those are fixes for regressions introduced by > > previous CVE fixes - but they chose to allocate new CVEs instead of > > updating the existing ones. I'm sure we could dig up precedence to > > the contrary - CVE-2010-0307 might be an example, if we consider > > 1dfc76ec to be a security fix vs. just a regression. > > > > That said, it really is MITRE's call - so we'll see how they respond > > to my request. If they prefer to update the existing CVE, that's fine > > by me. > > Ok. But I recommend against holding back the update until a CVE is > assigned. MITRE isn't working properly these days, we already needed > to release several DSA w/o CVE IDs being assigned so far. Just write > "Not yet available" as done for DSA 2013, DSA 2016 and DSA 2008.
ok, I'll do that. fyi, it should go out in a couple hours (last build just completed). -- dann frazier -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
