Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 123022 - www-servers/lighttpd: source code disclosure
Summary: www-servers/lighttpd: source code disclosure
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Security
Classification: Unclassified
Component: Vulnerabilities (show other bugs)
Hardware: All Linux
: High trivial (vote)
Assignee: Gentoo Security
URL: http://www.lighttpd.net/news/
Whiteboard: C4 [noglsa] jaervosz
Keywords:
Depends on:
Blocks: 133500
  Show dependency tree
 
Reported: 2006-02-16 04:45 UTC by Tavis Ormandy (RETIRED)
Modified: 2019-12-19 00:39 UTC (History)
11 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
lighttpd-1.4.10-r2.ebuild (lighttpd-1.4.10-r2.ebuild,4.94 KB, text/plain)
2006-04-15 02:46 UTC, Eduardo Tongson
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Tavis Ormandy (RETIRED) gentoo-dev 2006-02-16 04:45:30 UTC
very low risk to us, user would have to be serving pages from a vfat mounted filesystem or something, nevertheless:


In lighttpd 1.4.8 and below is a CRITICAL bug which allows
unauthenticated users to read all files from the documentation root if
the used file-system is case-insensitive.
Comment 1 Tavis Ormandy (RETIRED) gentoo-dev 2006-02-16 05:01:03 UTC
ka0ttic: is 1.4.10 suitable for arch stabilisation?
Comment 2 Thierry Carrez (RETIRED) gentoo-dev 2006-02-16 12:36:19 UTC
status adjustment
Comment 3 Thierry Carrez (RETIRED) gentoo-dev 2006-02-21 10:26:47 UTC
ka0ttic, please confirm if we can call for stable on 1.4.10
Comment 4 Aaron Walker (RETIRED) gentoo-dev 2006-02-22 08:40:29 UTC
Sorry for the delayed response; I've not had the time lately.  1.4.10 needs a patch from upstream first and a tad bit more testing before I feel comfortable stabilizing.
Comment 5 Aaron Walker (RETIRED) gentoo-dev 2006-02-25 17:11:50 UTC
1.4.10-r1 is in cvs with more upstream patches.  I'd like to test it a bit more and see if I get any other bugs before going stable.
Comment 6 Thierry Carrez (RETIRED) gentoo-dev 2006-03-07 13:27:21 UTC
ka0ttic: is it OK to test for stable now ?
Comment 7 Gentoo User 2006-03-15 12:49:55 UTC
What's the status of this?
Comment 8 Thierry Carrez (RETIRED) gentoo-dev 2006-03-28 09:29:02 UTC
Without response from the maintainer, calling for stable now
Please test and mark 1.4.10-r1 stable
Comment 9 Mark Loeser (RETIRED) gentoo-dev 2006-03-28 22:24:35 UTC
Looks alright on x86, but it would be very cool if the ebuild set correct permissions on /var/log/lighttpd so the daemon could write there.  Right now it dies the first time you try to start it because it doesn't have permission to write there.
Comment 10 Sune Kloppenborg Jeppesen (RETIRED) gentoo-dev 2006-03-29 07:23:50 UTC
Aaron/security patchers please fix the ebuild.
Comment 11 Preston hunt 2006-04-14 23:10:17 UTC
Any update on getting a version bump in x86 stable for lighttpd?  Current release (1.3.16) is getting a little old.  It would be nice to get some of the new features in the 1.4.x trunk if possible :)  Thanks!
Comment 12 Eduardo Tongson 2006-04-15 02:46:40 UTC
Created attachment 84703 [details]
lighttpd-1.4.10-r2.ebuild

fixed permission problems.
Comment 13 Raphael Marichez (Falco) (RETIRED) gentoo-dev 2006-04-15 03:52:59 UTC
The permissions problem on /var/log/lighttpd comes from the new ebuild, which calls fowners in pkg_postinst() and not in src_install() anymore.
I think in pkg_postinst(), fowners applies in /var/tmp/.../image only, but *after* the merge, which is obviously wrong.

ed has moved the 3 lines enewgroup/enewuser/fowners from postinst() to src_install(). It should work now. But i don't see why fperms is needed.

Futhermore, in the logrotate conf file, it may be useful to specify
"create 640 lighttpd lighttpd" (not sure about this)
Comment 14 Thierry Carrez (RETIRED) gentoo-dev 2006-04-22 03:25:51 UTC
Anyone from www-servers to apply patch on ka0ttic's behalf ?
Comment 15 Thomas Cort (RETIRED) gentoo-dev 2006-04-28 08:23:27 UTC
lighttpd 1.4.11 (the latest release) has the source code disclosure bug fixed. It was released on 09-Mar-2006, it hasn't made its way into portage yet, see Bug #126603. Maybe someone might consider doing a version bump instead of patching 1.4.10.
Comment 16 José Alberto Suárez López (RETIRED) gentoo-dev 2006-05-04 00:17:05 UTC
i commited r2 to cvs. I prefer wait to ka0ttic for the version bump so i dont know lighttpd well :)
If ka0ttic dont back tell me.
Comment 17 Thierry Carrez (RETIRED) gentoo-dev 2006-05-04 09:47:51 UTC
archs please test and mark stable if you can
Comment 18 Eric Anderson 2006-05-04 10:03:36 UTC
The r2 is portage has a problem. When compiling I get the error:

 * 'enewgroup()' called from 'install()' which is not a pkg_* function.
 * Package fails at QA and at life.  Please file a bug.
Comment 19 Thomas Cort (RETIRED) gentoo-dev 2006-05-04 11:17:32 UTC
(In reply to comment #17)
> archs please test and mark stable if you can

There are tests that fail on amd64....

make  check-TESTS
make[3]: Entering directory `/var/tmp/portage/lighttpd-1.4.10-r2/work/lighttpd-1.4.10/tests'
preparing infrastructure                PASS: prepare.sh
./core-var-include....ok
./mod-auth............ok
./mod-rewrite.........ok
        5/5 skipped: no PHP running on port 1026
./core-keepalive......ok
./core-request........ok 1/33Use of uninitialized value in length at /LightyTest.pm line 175.
Use of uninitialized value in pattern match (m//) at /LightyTest.pm line 214.
Use of uninitialized value in concatenation (.) or string at /LightyTest.pm line 224.
# unexpected resp_line ''

#   Failed test 'Content-Length > max-request-size'
#   in ./core-request.t at line 221.
./core-request........ok 26/33# Looks like you failed 1 test of 33.
./core-request........dubious
        Test returned status 1 (wstat 256, 0x100)
DIED. FAILED test 25
        Failed 1/33 tests, 96.97% okay
./core-response.......ok
./mod-ssi.............ok
./core................ok
./mod-compress........ok
./mod-fastcgi.........ok 1/45# header vary is duplicated: Accept-Encoding and Accept-Encoding
./mod-fastcgi.........ok
        32/45 skipped: various reasons
./mod-redirect........ok
./mod-cgi.............ok
./mod-setenv..........ok
./mod-userdir.........ok
./mod-access..........ok
./core-condition......ok
./request.............ok
Failed Test      Stat Wstat Total Fail  Failed  List of Failed
-------------------------------------------------------------------------------
./core-request.t    1   256    33    1   3.03%  25
37 subtests skipped.
Failed 1/17 test scripts, 94.12% okay. 1/246 subtests failed, 99.59% okay.
FAIL: run-tests.pl
cleaning up                             PASS: cleanup.sh
================================
1 of 3 tests failed
Please report to jan@kneschke.de
================================
make[3]: *** [check-TESTS] Error 1
make[3]: Leaving directory `/var/tmp/portage/lighttpd-1.4.10-r2/work/lighttpd-1.4.10/tests'
make[2]: *** [check-am] Error 2
make[2]: Leaving directory `/var/tmp/portage/lighttpd-1.4.10-r2/work/lighttpd-1.4.10/tests'
make[1]: *** [check-recursive] Error 1
make[1]: Leaving directory `/var/tmp/portage/lighttpd-1.4.10-r2/work/lighttpd-1.4.10/tests'
make: *** [check-recursive] Error 1


# emerge --info
Portage 2.0.54 (default-linux/amd64/2006.0, gcc-3.4.5, glibc-2.3.5-r2, 2.6.15-gentoo-r7 x86_64)
=================================================================
System uname: 2.6.15-gentoo-r7 x86_64 AMD Turion(tm) 64 Mobile Technology ML-32
Gentoo Base System version 1.6.14
dev-lang/python:     2.4.2
dev-util/ccache:     [Not Present]
dev-util/confcache:  [Not Present]
sys-apps/sandbox:    1.2.12
sys-devel/autoconf:  2.13, 2.59-r7
sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1
sys-devel/binutils:  2.16.1
sys-devel/libtool:   1.5.22
virtual/os-headers:  2.6.11-r2
ACCEPT_KEYWORDS="amd64"
AUTOCLEAN="yes"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-march=athlon64 -O2 -pipe"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/lib/X11/xkb /usr/lib64/mozilla/defaults/pref /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/qmail/control"
CONFIG_PROTECT_MASK="/etc/eselect/compiler /etc/gconf /etc/terminfo /etc/env.d"
CXXFLAGS="-march=athlon64 -O2 -pipe"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoaddcvs autoconfig collision-protect cvs distlocks multilib-strict sandbox sfperms strict"
GENTOO_MIRRORS="http://gentoo.mirrored.ca/ http://adelie.polymtl.ca/ http://gentoo.osuosl.org/ "
MAKEOPTS="-j2"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage /home/tcort/cvs/quodlibet"
SYNC="rsync://rsync.namerica.gentoo.org/gentoo-portage"
USE="amd64 X aac acpi aim alsa audacious audiofile avi berkdb bitmap-fonts browserplugin bzip2 cdr cli crypt cups curl dbus dri eds emboss encode esd exif expat fam flac foomaticdb gd gdbm gif glut gnome gphoto2 gpm gstreamer gtk gtk2 gtkhtml hal icq idn imlib ipv6 isdnlog jabber java jpeg kde lcms libwww lua lzw lzw-tiff mad mikmod mng mono mozilla moznocompose moznoirc moznomail mp3 mpeg msn ncurses nls nocd nptl nptlonly nsplugin offensive ogg oggvorbis openal opengl oscar pam pcre pdflib perl png pppd python qt quicktime readline reflection sdl session shorten sndfile spell spl ssl symlink tcpd tetex tiff truetype truetype-fonts type1-fonts udev usb userlocales vorbis wxgtk1 xml2 xmms xorg xpm xv xvid yahoo zlib userland_GNU kernel_linux elibc_glibc"
Unset:  ASFLAGS, CTARGET, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, LINGUAS

Comment 20 Mark Loeser (RETIRED) gentoo-dev 2006-05-11 10:51:17 UTC
All the tests worked fine for me, but I found another problem :)  The init script needs to depend on famd if you build with USE=famd, otherwise the daemon fails to start.  This is probably an old problem, but I figured I'd comment on it before I went ahead.
Comment 21 Thierry Carrez (RETIRED) gentoo-dev 2006-05-14 09:50:14 UTC
BaSS/ka0ttic: some more work is apparently needed
Comment 22 Thilo Bangert (RETIRED) (RETIRED) gentoo-dev 2006-05-30 11:28:35 UTC
i added 1.4.11 to the tree - ARCH testers please test.

improvements / comments on the ebuild welcome.

about the fam issue (comment #20): AFAICT it shouldn't "need fam" as this breaks those setups using gamin. other opinions/solutions ?
Comment 23 Thilo Bangert (RETIRED) (RETIRED) gentoo-dev 2006-05-30 11:30:14 UTC
Add missing ARCH - please test 1.4.11
Comment 24 Markus Rothe (RETIRED) gentoo-dev 2006-05-30 13:27:49 UTC
1.4.11 just works :-)

stable on ppc64
Comment 25 Mark Loeser (RETIRED) gentoo-dev 2006-05-30 18:16:45 UTC
(In reply to comment #22)
> i added 1.4.11 to the tree - ARCH testers please test.
> 
> improvements / comments on the ebuild welcome.
> 
> about the fam issue (comment #20): AFAICT it shouldn't "need fam" as this
> breaks those setups using gamin. other opinions/solutions ?
> 

Well, this is still broken then.  If it won't work with regular fam, then depend on gamin.  If you use the virtual, it should work with everything that provides the virtual, and it currently doesn't.
Comment 26 Thilo Bangert (RETIRED) (RETIRED) gentoo-dev 2006-05-30 23:51:38 UTC
it does work with app-admin/fam

but i don't think it is broken (as in needs fixing). virtual/fam defaults to gamin (on x86) which works fine. fam works fine as well if started at bootup - which i dont find unreasonable to expect. somebody who can choose a different virtual will also be able to get lighttpd running.

last but not least - the reason why i hesitate is that the only solution i see, would also cause breakage. installing an init script which, if app-admin/fam is installed, needs fam - otherwise uses fam. but this will cause twice the above mentioned breakage  - namely in cases where the system is switched from fam to gamin or from gamin to fam...

IMHO the current situation is the one with the least breakage (no breakage for the  virtual/fam default)
if there is a solution that does not cause breakage, i'd be more than happy to implement it.

perhaps a warning at the end, if app-admin/fam is installed is a reasonable compromise...
Comment 27 Mark Loeser (RETIRED) gentoo-dev 2006-05-31 15:40:19 UTC
(In reply to comment #26)
> it does work with app-admin/fam

Not without prior knowledge of knowing the init script is broken

> but i don't think it is broken (as in needs fixing). virtual/fam defaults to
> gamin (on x86) which works fine. fam works fine as well if started at bootup -
> which i dont find unreasonable to expect. somebody who can choose a different
> virtual will also be able to get lighttpd running.

And people that had famd installed (like myself)?  If you use the virtual, then it should just work no matter which one is installed, which doesn't happen right now.  I don't have famd start up at boot, and you are relying on famd to start before lighttpd since there is no dependency, which isn't very good.

> 
> last but not least - the reason why i hesitate is that the only solution i see,
> would also cause breakage. installing an init script which, if app-admin/fam is
> installed, needs fam - otherwise uses fam. but this will cause twice the above
> mentioned breakage  - namely in cases where the system is switched from fam to
> gamin or from gamin to fam...

Right now, it doesn't work with fam, in my opinion, so it should just depend on gamin.  I had famd installed, but never had it start on bootup.  Silly, maybe, but I'm sure lots of other users have it that way, and lighttpd just randomly dies when trying to start it.  not very user friendly or "stable".


> IMHO the current situation is the one with the least breakage (no breakage for
> the  virtual/fam default)
> if there is a solution that does not cause breakage, i'd be more than happy to
> implement it.

Not breaking for the default doesn't mean anything.  There are alternatives, and it should work with those as well, or you should say it won't (which it doesn't in this case).

> 
> perhaps a warning at the end, if app-admin/fam is installed is a reasonable
> compromise...
> 

I'm not going to be marking this stable on x86 in its current state.  Anyone else on the x86 team is more than welcome to disagree with me, but making compromises like this is what makes users angry when things don't work, when they should "Just Work" (TM).
Comment 28 Joshua Jackson (RETIRED) gentoo-dev 2006-05-31 15:50:14 UTC
on this one I agree with Mark.A virtual should mean that anything under it will work. As you are using the virtual, then famd should work just as well as gamin. If this isn't the case then its broken. Either make it depend on either fam or gamin, or fix it so it forces famd  to start before it trys to start lighttpd.

If however no one wants to fix it, I'm perfectly fine masking the package until such time as it does get fixed, or its removed from the tree. Its up to you to decide what to do with it.
Comment 29 Jory A. Pratt 2006-05-31 16:06:13 UTC
why not just use a simple sed on the init script based on fam use flag to add it to depends, this would solve the entire discussion IMHO.
Comment 30 Jory A. Pratt 2006-05-31 16:07:14 UTC
why not just use a simple sed on the init script based on fam use flag to add it to depends, this would solve the entire discussion IMHO.(In reply to comment #29)
> why not just use a simple sed on the init script based on fam use flag to add
> it to depends, this would solve the entire discussion IMHO.
> 
rather to needs not depends but you get the point I am making
Comment 31 Mark Loeser (RETIRED) gentoo-dev 2006-05-31 17:03:33 UTC
Except for the fact that fam can pull in either gamin or fam.  One of them has a daemon, the other does not.  Having it so the installation has to even care which of them installed is broken, since I can't switch from gamin to fam or vice versa, since lighttpd needs to know which is installed.  Just pick which one you want to use for lighttpd and lets move on :)
Comment 32 Diego Elio Pettenò (RETIRED) gentoo-dev 2006-05-31 17:08:57 UTC
Uh, isn't "use famd" enough to say "if it's there use it, else don't bother?
It would just need to be enabled with fam useflag enabled and removed elseway (so even if famd is installed it won't hurt).

After all you can't have both fam and gamin installed.
Comment 33 Steev Klimaszewski (RETIRED) gentoo-dev 2006-05-31 18:07:51 UTC
I have made lighttpd 1.4.10-r2 and 1.4.11 both depend explicitly on gamin when using the fam useflag.  Can we mark 1.4.10-r2 stable now?
Comment 34 Jory A. Pratt 2006-05-31 18:52:47 UTC
(In reply to comment #33)
> I have made lighttpd 1.4.10-r2 and 1.4.11 both depend explicitly on gamin when
> using the fam useflag.  Can we mark 1.4.10-r2 stable now?
> 

This is not a proper solution those who have fam providing the virtual already should not be forced to gamin, exspecially in a server enviroment. I would recommend masking package until a better solution is found!!!
Comment 35 Jory A. Pratt 2006-05-31 19:08:47 UTC
Uberlord - Can you please provide some insight as to why use famd does not start fam like myself and flameeyes believe it should? Is this a possible bug in stable baselayout maybe.
Comment 36 Mark Loeser (RETIRED) gentoo-dev 2006-05-31 20:16:44 UTC
If you want to do "use famd", then it would help if some init script actually provided famd :)
Comment 37 Roy Marples (RETIRED) gentoo-dev 2006-06-01 02:15:46 UTC
(In reply to comment #35)
> Uberlord - Can you please provide some insight as to why use famd does not
> start fam like myself and flameeyes believe it should? Is this a possible bug
> in stable baselayout maybe.

It's very possible that this is a bug with the 1.11 branch of baselayout.

As such my recommendation is to default the script to have depend after famd instead of use. When lighttpd is built with USE fam then a simple sed call can change after to need like so in src_install

if use fam ; then
   sed -i 's/after famd/need famd/g' "${D}"/etc/init.d/lighttpd
fi

We do the same thing with bluez-utils now which makes script dependencies so much better :)
Comment 38 Roy Marples (RETIRED) gentoo-dev 2006-06-01 02:16:40 UTC
(In reply to comment #36)
> If you want to do "use famd", then it would help if some init script actually
> provided famd :)

famd provides famd .......
Comment 39 Roy Marples (RETIRED) gentoo-dev 2006-06-01 02:18:20 UTC
(In reply to comment #37)
> As such my recommendation is to default the script to have depend after famd
> instead of use. When lighttpd is built with USE fam then a simple sed call can
> change after to need like so in src_install
> 
> if use fam ; then
>    sed -i 's/after famd/need famd/g' "${D}"/etc/init.d/lighttpd
> fi
> 
> We do the same thing with bluez-utils now which makes script dependencies so
> much better :)

You would have to check that fam actually was installed instead of gamin though as that would obviously not work at all.
Comment 40 Thilo Bangert (RETIRED) (RETIRED) gentoo-dev 2006-06-01 15:05:57 UTC
use fam && has_version app-admin/fam && \
                sed -i 's/after famd/need famd/g' "${D}"/etc/init.d/lighttpd

how about this then. its in the tree...

the after famd is pretty useless obviously - but lets get this one out of the door. i'll clean it up later... (do file bugreports as you find stuff)
yes, all involved ARCH teams marked the current state stable (at some point) - so even though it may not be perfect, its no worse than what is in the tree already.

BTW its 1.4.11 we'd like to go stable.
good night and good luck...
Comment 41 Mark Loeser (RETIRED) gentoo-dev 2006-06-02 18:34:33 UTC
Works for me.  Stable on x86, thanks.(In reply to comment #37)
> (In reply to comment #35)
> > Uberlord - Can you please provide some insight as to why use famd does not
> > start fam like myself and flameeyes believe it should? Is this a possible bug
> > in stable baselayout maybe.
> 
> It's very possible that this is a bug with the 1.11 branch of baselayout.

Hmm, I'm not sure what I did, but now "use famd" does work for me.  And with "provided" I was thinking of things that were not named what you wanted them to provide, so my mistake on that one :)


> As such my recommendation is to default the script to have depend after famd
> instead of use. When lighttpd is built with USE fam then a simple sed call can
> change after to need like so in src_install
> 
> if use fam ; then
>    sed -i 's/after famd/need famd/g' "${D}"/etc/init.d/lighttpd
> fi
> 
> We do the same thing with bluez-utils now which makes script dependencies so
> much better :)

And then if someone changes from famd to gamin or vice versa, lighttpd is broken.

Was anyone else running into the problem I did with "use famd" not working?  If not, please change it back to use famd since that is how it should be.  I've never had to deal with init scripts really, so I missed that it should have worked how it was.

Comment 42 Mark Loeser (RETIRED) gentoo-dev 2006-06-02 18:45:29 UTC
Err, not sure why I did that O:)
Comment 43 Roy Marples (RETIRED) gentoo-dev 2006-06-03 01:52:30 UTC
(In reply to comment #41)
> > As such my recommendation is to default the script to have depend after famd
> > instead of use. When lighttpd is built with USE fam then a simple sed call can
> > change after to need like so in src_install
> > 
> > if use fam ; then
> >    sed -i 's/after famd/need famd/g' "${D}"/etc/init.d/lighttpd
> > fi
> > 
> > We do the same thing with bluez-utils now which makes script dependencies so
> > much better :)
> 
> And then if someone changes from famd to gamin or vice versa, lighttpd is
> broken.

Well, the init script is, but I cannot see a way around that. re-emerging lighttpd and replacing the init script will work, so hopefully our users will be savvy enough. Maybe a warning about this in the ebuild?
Comment 44 Mark Loeser (RETIRED) gentoo-dev 2006-06-03 08:30:38 UTC
(In reply to comment #43)
> > And then if someone changes from famd to gamin or vice versa, lighttpd is
> > broken.
> 
> Well, the init script is, but I cannot see a way around that. re-emerging
> lighttpd and replacing the init script will work, so hopefully our users will
> be savvy enough. Maybe a warning about this in the ebuild?
> 

Isn't this what "use famd" is for anyway?  That seemed to work for me.  I'm not sure why it didn't before, but it gives me the exact results I expect now.

Does "use famd" not work for anyone else?  Was I the only one?  If we can fix this without having users to know they have to re-emerge things, that should be the solution we go for, and it seems that's what "use famd" in the init script should do.  My knowledge of init scripts is just pretty basic though.
Comment 45 Roy Marples (RETIRED) gentoo-dev 2006-06-04 05:59:08 UTC
(In reply to comment #44)
> Does "use famd" not work for anyone else?

The issue is that if famd is stopped then lighttpd will stop working too, so the correct depend is "need famd" if it's been compiled for fam and not gamin.
Comment 46 Mark Loeser (RETIRED) gentoo-dev 2006-06-04 13:41:54 UTC
(In reply to comment #45)
> (In reply to comment #44)
> > Does "use famd" not work for anyone else?
> 
> The issue is that if famd is stopped then lighttpd will stop working too, so
> the correct depend is "need famd" if it's been compiled for fam and not gamin.
> 

Good point.  I didn't think of that.

I was going to try and come up with something to check for the existance of famd in the user's path, but the init scripts don't seem to like doing that all of the time.  If you switch from one to the other, it doesn't seem to pick up the dependency immediately because it caches them.

So, can you just add the ewarn at the end that you'll have to recompile lighttpd if you switch from famd to gamin, since I guess this is the best solution we can do for the time being?  After you do that, I'll go ahead and check everything one last time and mark it stable.

Thanks :)  (and sorry for being a pain in the ass, but I was hoping we could get a nice clean solution to this)
Comment 47 Thilo Bangert (RETIRED) (RETIRED) gentoo-dev 2006-06-06 12:12:29 UTC
> add the ewarn at the end that you'll have to recompile
> lighttpd if you switch from famd to gamin

well - i made it an einfo (by accident)... if you feel strongly about it being ewarn give me a shout (or do it yourself ;)

thanks
Comment 48 Mark Loeser (RETIRED) gentoo-dev 2006-06-06 19:03:47 UTC
That's fine how it is.

Thanks for working with me :)

x86 done
Comment 49 Thomas Cort (RETIRED) gentoo-dev 2006-06-06 19:27:16 UTC
amd64 stable.
Comment 50 Thilo Bangert (RETIRED) (RETIRED) gentoo-dev 2006-06-10 02:10:43 UTC
mips?

please test 1.4.11 and mark stable, if suitable.
thanks.

kind regards
bangert
Comment 51 Stephen Becker (RETIRED) gentoo-dev 2006-06-10 06:24:35 UTC
(In reply to comment #50)
> mips?
> 
> please test 1.4.11 and mark stable, if suitable.
> thanks.
> 
> kind regards
> bangert
> 

Well, ka0ttic was maintaining this for us on mips.  Otherwise, I'm about 99% certain that nobody except him was actually using it on mips.

-Steve
Comment 52 Thilo Bangert (RETIRED) (RETIRED) gentoo-dev 2006-06-12 12:30:34 UTC
so the security process continues without mips? or what?
Comment 53 Raphael Marichez (Falco) (RETIRED) gentoo-dev 2006-06-19 03:31:58 UTC
We can close this bug without waiting for mips stabilization, except if we want a GLSA. (i vote no glsa)
Comment 54 Wolf Giesen (RETIRED) gentoo-dev 2006-06-19 05:24:19 UTC
Hm. Tough one. There's nothing in the policy (AFAIR) that says "no GLSA is needed if the bug affects less than <TINYNUMBER> of installations", so I'd say YES, although it's really very specific and hard to argue that it might affect any default configuration (although possible)...
Comment 55 Stephen Becker (RETIRED) gentoo-dev 2006-06-19 08:33:14 UTC
We (mips) aren't security supported in Gentoo at this time, therefore you don't have to wait for us.  I'm hoping that ka0ttic wakes up sometime and picks up maintenance for us again.  It is tough to be asked to stabilize something you have never used (nor even intend to use) on an arch, and our policy is to not add/change keywords for anything that we haven't tested ourselves.  Anyone else from the mips team want to test this?  Otherwise, don't worry about us.

-Steve
Comment 56 Sune Kloppenborg Jeppesen (RETIRED) gentoo-dev 2006-06-19 09:26:47 UTC
Time for a GLSA vote then.
Comment 57 Thierry Carrez (RETIRED) gentoo-dev 2006-06-19 09:59:00 UTC
Definite NO
Comment 58 Matthias Geerdsen (RETIRED) gentoo-dev 2006-06-22 05:58:16 UTC
tend to vote NO
Comment 59 Raphael Marichez (Falco) (RETIRED) gentoo-dev 2006-06-25 11:35:04 UTC
i've already voted no too.

Closing without glsa, feel free to reopen if you disagree