Re: Bug#573531: drbd8-modules-2.6.26-2-amd64: Can not load drbd module
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 <dannf@debian.org> 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
Reply to: