See URL for full security advisory Vulnerability Details ===================== Issue 1 ------- Class: Information Leak Versions: 2.18rc1 - 2.18.3, 2.19 - 2.20rc2, 2.21 Description: config.cgi gives JavaScript and RDF information about Bugzilla to third-party clients, including a list of products in the Bugzilla installation. The "requirelogin" parameter requires that all people be logged into Bugzilla before seeing any data, as a security measure. In affected versions, config.cgi is always accessible, and always contains information to non-logged-in users, even when "requirelogin" is turned on, possibly exposing product names that administrators expected to be confidential. Reference: https://bugzilla.mozilla.org/show_bug.cgi?id=308256 Issue 2 ------- Class: Information Leak Versions: 2.19.1 - 2.20rc2, 2.21 Description: Bugzilla contains features to prevent users from "seeing" other users, enabled by the "usevisibilitygroups" parameter. Bugzilla also contains a feature called "user matching," which enables users to type in part of a username and get back a list of possible matches. If user matching is turned on and is in "substring" mode, all matching users will be returned to a query, regardless of the visibility groups settings, exposing users who should be invisible. Reference: https://bugzilla.mozilla.org/show_bug.cgi?id=308662 Vulnerability Solutions ======================= The fixes for all of the security bugs mentioned in this advisory are included in the 2.18.4, 2.20, and 2.21.1 releases. Upgrading to these releases will protect installations from possible exploits of these issues.
2.18.4 and 2.20 are in CVS.
yeah, i know. i'm waiting on confirmation from lance to get a perl module installed on bugs.g.o before i can even begin to test 2.20. i cant just drop in a new bugzilla install. ours is customized to all hell ;) -jeff
alright, i'm testing the new bugzilla.
Archs please test and mark stable 2.18.4 or 2.20... Target KEYWORDS="amd64 ppc ppc64 sparc x86"
Stable on ppc.
I get an interactive config.. From what I know.. shouldn't this be part of pkg_config? emerge is supposed to be completely autonomous
2.18.4 stable on ppc64.
(In reply to comment #6) > I get an interactive config.. From what I know.. shouldn't this be part of > pkg_config? emerge is supposed to be completely autonomous You'll want to set USE="vhosts" then. Also, please read man webapp-config.
Erm... I was not aware that interactive config should be toggled by a completely unrelated use-flag... Is the _really_ supposed to happen?
(In reply to comment #9) > Erm... I was not aware that interactive config should be toggled by a > completely unrelated use-flag... Is the _really_ supposed to happen? The "completely unrelated use-flag" instructs webapp-config to install the application into a vhost. Sometimes, that involves more than just copying / linking files into another directory. If you don't want that to happen, please turn on the USE flag.
Discussion about this on http://thread.gmane.org/gmane.linux.gentoo.devel/31939 How did ppc ever make it stable?
Waiting for bug 107918 to settle up.
Folks, The reconfig hook is no longer interactive. ppc and ppc64, please review the changes as you've already marked stable.
I appreciate your work to fix it.. unfortunately it seems to still be broken :/ without USE="vhosts", the checkconfig.pl does not get put into the /var/www/localhost/htdocs directory.. thus, it needs to be manually copied before doing anything... This is where pkg_config() would come in, correct? I will not be able to work on this tonight, but I'm willing to take a look at it come tommorow if no one figures out a fix before then :/
Looks good on ppc.
It looks pretty broken for initial installations to me. How exactly is it working on PPC when it has the issues listed in comment #14? Unless you manually copy checkconfig.pl into your vhost and manually edit localconfig, which the ebuild mentions nothing about, then manually run checkconfig.pl, your bugzilla installation will not work. Basically, if USE="vhosts" then it needs to tell you how to run webapp-config to install the app on your individual vhosts, then to edit localconfig and run checkconfig.pl afterwards. For USE="-vhosts", it should tell the user to run ebuild /var/db/pkg/www-apps/bugzilla/bugzilla*.ebuild config, to set up localconfig. An even better solution would be to put in some sort of marker, such as "localconfig.done" or something that is done by pkg_config, so that once a user has configured their bugzilla, the ebuild can automatically re-run checkconfig.pl non-interactively at merge time. If necessary, I can get an ebuild patch put together, but at this point, I will definitely say that a package that doesn't work and provides no instructions on how to get it to work probably isn't a good candidate for stable.
(1) wth is checkconfig.pl? I assume you're talking about checksetup.pl. (2) With USE="-vhosts", it _is_ copied into your ${MY_INSTALLDIR}, or /var/www/localhost/htdocs/bugzilla. Where are you copying it from? (3) With USE="vhosts", it _does_ tell you to run webapp-config to install the app. Really, it does. Try it. (4) Your collective fascination with pkg_config in the context of webapp-config tells me you're not familiar with how the thing works. Once again, pkg_config is not aware of where your vhosts reside, so it is of no help here. Please read man webapp.eclass and man webapp-config. (5) If you bother to follow the link to the installation manual, which the postinstall instructions _do_ tell you to do, you would see that you need to run ./checksetup.pl and edit localconfig. Previously, the reconfig hook did this for you - this was the whole issue with interactive package configurations, remember? (6) The marker is not going to work. For new installs, you can't run the script automatically as it's going to be interactive. For most upgrades, such as 2.18.4 -> 2.20, you'll need to edit localconfig to remove a few obsolete entries and add a few (e.g., db_driver). checksetup.pl warns you.
I apologize for the bug spam. I was only responding based on a conversation with Dan, one of the x86 AT. Anyway, 2.18.4 is stable on x86. The only issues that I see are that checksetup.pl isn't executable once installed.
proved on ppc64
amd64 stable
sparc stable.
Ready for GLSA vote
Looks rather minor to me, I tend to vote NO.
Security, please cast your vote.
Not sure, but I tend to vote NO.
Given lack of manpower, two half-votes are sufficient, feel free to reopen if you disagree.
