Bugzilla Bug 107796

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.