As reported by me on oss-security at $URL, thttpd, at least on gentoo, has a world-redable log/logdir: # ls -la /var/log/thttpd.log -rw-r--r-- 1 thttpd thttpd 0 Feb 22 14:05 /var/log/thttpd.log
I committed the fix upstream: http://opensource.dyc.edu/gitweb/?p=sthttpd.git;a=commit;h=d2e186dbd58d274a0dea9b59357edc8498b5388d This is not a gentoo only bug. You need to chmod() the log file after its fopen(). I'll push this out to the tree as thttpd-2.26.4-r2 after dealing with other bugs. I don't think this is that big of a deal, and I'm not sure why you think you needed a CVE for it.
(In reply to comment #1) > I'm not sure why you think you needed a CVE for it. An unauthorized user can disclose sensitive information.
Okay I've pushed thttpd-2.26.4-r2.
Okay time to stabilize: TARGETS="amd64 arm ppc ppc64 sparc x86"
(In reply to comment #4) > Okay time to stabilize: TARGETS="amd64 arm ppc ppc64 sparc x86" Okay I took care of ppc and ppc64
amd64 stable
x86 stable
arm stable
sparc stable
(In reply to comment #0) > As reported by me on oss-security at $URL This is NOT how Gentoo developers should be reporting vulnerabilities they find. Please see our methodology on the Audit subproject page [1]. GLSA vote: NO. [1] http://www.gentoo.org/proj/en/security/audit.xml
(In reply to comment #10) > (In reply to comment #0) > > As reported by me on oss-security at $URL > > This is NOT how Gentoo developers should be reporting vulnerabilities they > find. Please see our methodology on the Audit subproject page [1]. > > GLSA vote: NO. > > > [1] http://www.gentoo.org/proj/en/security/audit.xml Thanks for that reference. It didn't seem right to me to request a CVE for something this trivial. I totally agree with solar's emphasis on peer-review. We need more of it everywhere in gentoo.
NO too, closing.