Bugzilla Bug 181977

See subject, new version available.

*** Bug 182708 has been marked as a duplicate of this bug. ***

i'm preparing the dbtool patch for sleuthkit-2.09. But appart from that,
sleuthkit-2.09 fixes the recent "file" vulnerabities in its "file" embedded
code: glsa-200703-26, glsa-200704-13, 200705-25. I suggest a GLSA.

ChangeLog:
5/17/07: Update: Updated file to 4.20
(...)
6/13/07: Update: Updated file to 4.21

There is also a number of DoS fixed in this upgrade.

Seems like this would be very hard to exploit in a meaningful way.  As I
understand it, it essentially would require enticing a user to run the forensic
tools on a crafted file.  The attendant problems with that scenario are pretty
obvious. :)  Also I would expect that sleuthkit is not a common package by any
means.  Still, it is definitely a B2, so I guess we should.

bumped and trying to fix bug 131268 at the same time.

Hi arches,

sleuthkit was shipped with a vulnerable version of the 'file' utility. There is
pretty much change between sleuthkit-0.3 and sleuthkit-0.9.

Please can you test sleuthkit-0.9 and mark is table if applicable, thanks.

ppc stable

http://distfiles.gentoo.org/distfiles/sleuthkit-2.09_dbtool.patch.bz2 gives a
404...

>>> Test phase [test]: app-forensics/sleuthkit-2.09
sh ./check-install

Checking Tools
ERROR: Missing 'file' command
Done

>>> Install sleuthkit-2.09 into ...

Stable for HPPA nonetheless.

Where is it?  Emerge can't locate the download...

>>> Downloading 'ftp://cudlug.cudenver.edu/pub/mirrors/distributions/gentoo/distfiles/sleuthkit-2.09_dbtool.patch.bz2'
--12:09:32-- 
ftp://cudlug.cudenver.edu/pub/mirrors/distributions/gentoo/distfiles/sleuthkit-2.09_dbtool.patch.bz2
           => `/usr/portage/distfiles/sleuthkit-2.09_dbtool.patch.bz2'
Resolving cudlug.cudenver.edu... 132.194.22.137
Connecting to cudlug.cudenver.edu|132.194.22.137|:21... connected.
Logging in as anonymous ... Logged in!
==> SYST ... done.    ==> PWD ... done.
==> TYPE I ... done.  ==> CWD /pub/mirrors/distributions/gentoo/distfiles ...
No such directory `pub/mirrors/distributions/gentoo/distfiles'.

!!! Couldn't download 'sleuthkit-2.09_dbtool.patch.bz2'. Aborting.

!!! Fetch for /usr/portage/app-forensics/sleuthkit/sleuthkit-2.09.ebuild
failed, continuing...



!!! Some fetch errors were encountered.  Please see above for details.

   app-forensics/sleuthkit-2.09

(In reply to comment #10)
> Where is it?  Emerge can't locate the download...

See comment #2 and comment #7 ... It's not ready yet, it appears. For now you
will have to contend yourself with a lesser version or with:

echo app-forensics/sleuthkit -dbtool >> /etc/portage/package.use

So what are we going to do with this package?  Are arches still needed here?

(In reply to comment #11)
> (In reply to comment #10)
> > Where is it?  Emerge can't locate the download...
> 
> See comment #2 and comment #7 ... It's not ready yet, it appears.

@Jer: you say it's not ready yet (sure, it isn't ready even for ~arch) but ... 
why did you mark it as stable in hppa? This is not the first time I saw you
marking stable packages after you discovered there are problems with them, so I
would like to know the reason to not stop the process of stabilization.

Thanks.

(In reply to comment #13)
> > See comment #2 and comment #7 ... It's not ready yet, it appears.
> 
> @Jer: you say it's not ready yet (sure, it isn't ready even for ~arch) 

I meant the dbtool patch not being ready yet. The rest of the package works
fine.

> This is not the first time I saw you marking stable packages after you
> discovered there are problems with them, so I would like to know the reason 
> to not stop the process of stabilization.

See comment #2, "But appart from that," and so on. I read that as the dbtool
patch being of no consequence to the included vulnerable version of file. 

`USE=-dbtool emerge =sleuthkit-2.09` works otherwise.

I think it's up to the maintainer to stop the stabilisation process. falco CC'd
the arches.

Besides, dertobil23 marked ppc stable before I did. Why did you ask me, not
him?

(In reply to comment #14)
> (In reply to comment #13)
> > > See comment #2 and comment #7 ... It's not ready yet, it appears.
> > 
> > @Jer: you say it's not ready yet (sure, it isn't ready even for ~arch) 
> 
> I meant the dbtool patch not being ready yet. The rest of the package works
> fine.

IMHO, something triggered via USE flag is a part of our "package" too, but
well, keep reading please. 

> 
> > This is not the first time I saw you marking stable packages after you
> > discovered there are problems with them, so I would like to know the reason 
> > to not stop the process of stabilization.
> 
> See comment #2, "But appart from that," and so on. I read that as the dbtool
> patch being of no consequence to the included vulnerable version of file. 
> 
> `USE=-dbtool emerge =sleuthkit-2.09` works otherwise.

What we get here is to give our users a broken stable branch (via USE flag or
not) what gives a very poor QA. When you are using the stable branch, you hope
everything to works fine, everything means whatever combination of USE flags
you have. 

Sometimes is not possible to test all the USE flags combinations but in this
case, where we already know there is a broken combination, seems like a no-no
to me marking as stable this version.

> 
> I think it's up to the maintainer to stop the stabilisation process. falco CC'd
> the arches.

falco CC'd the arches (look when this happened) and didn't mention something
about a broken USE. We don't know if he is aware of the not working USE. I'm
quite sure that anybody is going to ask for stable a version with a known
broken USE.

> 
> Besides, dertobil23 marked ppc stable before I did. Why did you ask me, not
> him?
> 

dertobi123 probably has tested the package without the broken USE, so he didn't
realize of the problem. Best thing to me, seems like what opfer has done, ask
the maintainer and see what's happing here.

Believe me that this is nothing personal with you, just wanted to know your
reasons for going to a stable with a broken USE. I understand your position of
respecting the maintainer desires but, in this case, I'm not sure if falco
knows about the problem and anyway, and always IMHO, Gentoo shouldn't allow a
broken stable branch on any arch.

@dertobi123: maybe you are interested in the problem with this version. Sorry
to CC'd you, if don't.

Falco uploaded the file so it's on the mirrors now.

Arches, please go for stabling here.
hppa and ppc, you are already stable, but maybe you want to retry with the
dbtool-patch.

(In reply to comment #16)
> Falco uploaded the file so it's on the mirrors now.

 Hooray!  x86 stable

It appears to work.

(In reply to comment #16)
> hppa and ppc, you are already stable, but maybe you want to retry with the
> dbtool-patch.
> 

worksforme

sparc stable

Marked stable on amd64.

B2 -> GLSA. Please file a request.

(In reply to comment #22)
> B2 -> GLSA. Please file a request.
> 

done. but I think you can do it yourself now ;)

GLSA 200710-19, eventually