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.
ka0ttic: is 1.4.10 suitable for arch stabilisation?
status adjustment
ka0ttic, please confirm if we can call for stable on 1.4.10
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.
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.
ka0ttic: is it OK to test for stable now ?
What's the status of this?
Without response from the maintainer, calling for stable now Please test and mark 1.4.10-r1 stable
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.
Aaron/security patchers please fix the ebuild.
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!
Created attachment 84703 [details] lighttpd-1.4.10-r2.ebuild fixed permission problems.
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)
Anyone from www-servers to apply patch on ka0ttic's behalf ?
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.
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.
archs please test and mark stable if you can
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.
(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
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.
BaSS/ka0ttic: some more work is apparently needed
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 ?
Add missing ARCH - please test 1.4.11
1.4.11 just works :-) stable on ppc64
(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.
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...
(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).
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.
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.
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
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 :)
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.
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?
(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!!!
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.
If you want to do "use famd", then it would help if some init script actually provided famd :)
(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 :)
(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 .......
(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.
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...
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.
Err, not sure why I did that O:)
(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?
(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.
(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.
(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)
> 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
That's fine how it is. Thanks for working with me :) x86 done
amd64 stable.
mips? please test 1.4.11 and mark stable, if suitable. thanks. kind regards bangert
(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
so the security process continues without mips? or what?
We can close this bug without waiting for mips stabilization, except if we want a GLSA. (i vote no glsa)
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)...
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
Time for a GLSA vote then.
Definite NO
tend to vote NO
i've already voted no too. Closing without glsa, feel free to reopen if you disagree