From willy at lukoil.uu.ru Sat Nov 16 03:19:50 2002 From: willy at lukoil.uu.ru (Vitaly Fedrushkov) Date: Sat, 16 Nov 2002 08:19:50 +0500 (YEKT) Subject: Bugzilla 2.16.1 in Russian is available Message-ID: Good $daytime, Russian templates for Bugzilla 2.16.1 are available at http://sourceforge.net/projects/bugzilla-ru/ At the moment, most templates are done (all but account management). However, there's much to do on help files and documentation. But first and foremost, we need a peer review by those who speak Russian, as some bug tracking terms have no stable match in Russian and may look awkward. Questions, comments and assistance are welcome. Regards, Willy. -- No easy hope or lies | Vitaly "Willy the Pooh" Fedrushkov Shall bring us to our goal, | Control Systems and Processes Division But iron sacrifice | LUKOIL Company, Chelyabinsk Branch Of Body, Will and Soul. | willy at lukoil.uu.ru +7 3512 620367 R.Kipling | VVF1-RIPE From justdave at syndicomm.com Tue Nov 19 10:12:32 2002 From: justdave at syndicomm.com (David Miller) Date: Tue, 19 Nov 2002 05:12:32 -0500 Subject: Bugzilla Status Update Message-ID: The following document can be viewed in HTML format with hyperlinks and tooltips and so forth at http://www.bugzilla.org/status_updates/2002-11-18.html Bugzilla Status Update J. Paul Reed and the Bugzilla Team Monday, November 18th, 2002 Copyright ? 2002 The Mozilla Organization. State of Bugzilla ================= We have come to an exciting time in the life of the Bugzilla project. In the last few months, we've had a few major companies adopt Bugzilla for their internal bug-tracking systems. OK, nothing new here; lots of companies use Bugzilla. So what's the big deal? These particular companies are contributing back. We've gotten a number of major features in the last couple months, and some other major features in the works, all contributed by companies who are paying their employees to make Bugzilla meet their needs. This is a really good thing for Bugzilla, because it means we're gaining more features that will appeal to the enterprise market rather than just small companies and Open Source groups. It also puts enterprise-level features into the hands of the small companies and Open Source groups. And those same enterprise-level corporations are the ones who can afford to put full-time manpower on improving the product, which just repeats the cycle. I think of it as a "coming of age" for Bugzilla, and a really good demonstration of the power of Open Source. But this isn't all flowery and sweet-smelling. With that type of contribution level also comes a great challenge. Not everyone who wants to use Bugzilla is going to want all of these features. Sure, a lot of them are really cool--you can read about some of them below--but each software development environment is different, and not everyone will have a use for every feature. So the Bugzilla team is now presented with the challenge of making sure Bugzilla remains easily configurable and scalable from the very small to the very large. There's also the challenge of making sure new features don't slow Bugzilla down beyond a reasonable level, as we've already run into in some cases with the changes to products, components, and groups. There's also the sense of "too many cooks in the kitchen" that has to be addressed. We love getting all this help but to ensure that Bugzilla's goals continue to get met, I feel it's necessary to institute an "approval" process for checkins. This new policy comes as an addition to our existing review policy. Previously, the only thing developers had to do to check something into Bugzilla's CVS tree was get one or two people on the review team to say "yes, this is quality code" and they could check it in. That process isn't going away, but in addition to that, approval will now need to be obtained from myself or a designee before it can be checked in. This won't amount to a code review, rather a 'yes' or 'no' to whether this feature or bugfix in this form at this time is the best course of action to fulfill Bugzilla's design goals. Our core development team has always been very good about ensuring that their individual work is peer reviewed for quality, and their checkin coordinated with other work going on in the tree to ensure the greatest benefit for Bugzilla, both from a code/feature perspective and a software engineering/management perspective. This new policy simply ensures that all our "master chefs" in the "kitchen" are working on the same course, preparing the same style of food, ensuring that we continue to provide the best damn bug-tracking package available today and tomorrow, for open source project and enterprise customer alike. -- Dave Miller, Bugzilla project lead Since the Last Status Report... =============================== The Bugzilla Team has been working furiously over the past two weeks on readying the trunk for a 2.17.1 development release. I know many of you reading this were hoping to see that tarball of 2.17.1 by now, but there were some regressions found during the recent mozilla.org upgrade to 2.17.1 from cvs, which we decided were glaring enough that we really should fix them first before we rolled the tarball. 2.17.1 is slated to be released within the week; the Bugzilla team is currently stamping out the last few of the above-mentioned regressions which have cropped up. 2.17.1 is intended for developers wishing to base large landings or patches off an official bugzilla.org release. It should not be used for production purposes, except in special circumstances. 2.17.1 is not a solution for Win32 users (see below). The vast majority of sites wanting to test or use Bugzilla in production should install 2.16.1. If you're not sure whether you should use 2.17.1 or or 2.16.1, you want 2.16.1. Administrators' Mailing List Reminder ===================================== We'd like to remind all Bugzilla administrators that to assist them in keeping up-to-date with release announcements and security advisories, we've started a mailing list for people who administer Bugzillas. It is very low traffic - release announcements and security advisories only. We advise all Bugzilla administrators to subscribe, so they can keep up with important Bugzilla news. The (Unchanged) Win32 Situation =============================== Bugzilla-on-Win32 is still unchanged: administrators using Win32 as their platform for Bugzilla do not want the 2.16 branch, including 2.16.1, nor do they want 2.17.1. The plan is to make the trunk Win32-friendly (which involves a number of quite large changes, and which unfortunately did not happen in this release cycle) and then announce that fact, allowing Win32 Bugzilla administrators to pull from the trunk on a known tag. This may become a 2.17.2 release. Interested admins can search bugzilla on the [needed for Win32bz] status whiteboard entry to track bugs that are part of this process. The Bugzilla Team continues to recommend Unix-based operating systems, including Linux, as the best platform for a Bugzilla installation; please consider it if you are starting a new Bugzilla installation and have some say in the platform decision. Trust us: it makes life easier for everyone. Upcoming Major Features ======================= Major new features are being worked on. If you would like to know when we plan on adding one of these features, you can get that information from the bug requesting its implementation. These include: * Ability to send email via SMTP instead of relying on a local installation of sendmail. (Bug 84876) * PostgreSQL support. (Bug 98304) * Sybase support. (Bug 173130) * Ability to add generic customized fields to bugs (Bug 91037) * Customised resolutions, that allow adding, removing, deactivating and renaming of resolutions. (Bug 94534) * Expanding the e-mail preferences to allow watching components, keywords, etc. (Bug 73665) * mod_perl support. (Bug 87406) * New makefile-based installation system (Bug 104660, Bug 105854, Bug 105855, and Bug 105856) * Generic charting. Allows users to define arbitrary data sets for which historical data will be recorded, and then plot those data sets. Bug 16009. * Rearchitect product groups. Gives administrators much more control over how products and groups are related. Bug 147275. New Bugzilla Features ===================== Reporting Improvements ---------------------- Bugzilla has a new mechanism for generating reports of the current state of the bug database. It has two, related parts: a table-based view, and several graphical views. The table-based view allows you to specify an x, y and z (multiple tables of data) axis to plot, and then restrict the bugs plotted using the standard query form. You can take the data as HTML or CSV, for importing into a spreadsheet. Each number in the HTML version of the table is linked to a query which produces the list. So, for example, a Netscape manager could plot assignee vertically, and severity horizontally, and restrict assignee to the names of his managees. He would then be able to see which of his managees was overloaded with severe bugs. There are also bar, line and pie charts, which are defined in a very similar way. These views may be more appropriate for particular data types, and are suitable for saving and then putting into presentations or web pages. Note that no attempt is made to prevent you from plotting silly data sets. For example, if you plot a graph of "assignee" along the X axis, and choose a line graph, your line won't mean very much. Example: http://bugzilla.mozilla.org/report.cgi?x_axis_field=bug_status&y_axis_field=component&product=MailNews&cumulate=1&format=table&ctype=html&action=wrap (You can switch between report types using the controls at the bottom.) Request Tracker --------------- The Request Tracker (RT) is a set of enhancements that make attachment statuses more powerful and easier to administer. It includes the following changes: * Additional states: Previously attachment statuses could be in one of two states: off or on. RT adds two more states for a total of four: off, granted, denied, and (optionally) requested, where "granted" is the equivalent of "on". These additions mean it is no longer necessary to define a status to negate another status (f.e. "needs-work" to negate "has-review") because negation is built into each status via the status' "denied" state. * Bug statuses: Previously only attachments could have these kinds of statuses. RT enables them for bugs as well. Since the word "status" already has a meaning for bugs, attachment statuses have been renamed to "flags" to avoid confusion. * Requests: Flags can now optionally be made requestable, which means users can ask other users to set them. When a user requests a flag, Bugzilla emails the requestee and adds the request to a browsable queue so both the requester and the requestee can keep track of its status. Once the requestee fulfills the request by setting the flag to either granted or denied, Bugzilla emails the requestee and removes the request from the queue. This feature supports workflow like the mozilla.org code review and milestone approval processes, whereby code is peer reviewed before being committed and patches get approved by product release managers for inclusion in specific product releases. * Product/component specificity: Previously flags were product-specific, and if you wanted the same flag for multiple products you had to define multiple flags with the same name. Flags are now product/component-specific, and a single flag can be enabled or disabled for multiple product/component combinations via inclusions and exclusions lists. Flags are enabled for all combinations on their inclusions list except those that appear on their exclusions list. For more information see the brief online documentation. User Wildcard Matching ---------------------- Sites can now enable the use of wildcards and substrings in bug entry and editing forms. If the usermatchmode param is set to wildcard, then any "*" included in email addreses will be treated as a wildcard and cause the entry provided to be matched against all active userids and real names in the system. If usermatchmode is set to search, addresses that do not exactly match an existing email address will be matched as a substring as well. Two other paramaters influence the behavior of wildcards, maxusermatches and confirmuniqueusermatch permit a site to determine how broadly to apply ambiguous wildcards and to determine if all wildcard expansions should be confirmed. Support for "Insiders" ---------------------- If the insidergroup parameter is defined, a specific group of users can be designated insiders who can designate comments and attachments as private to other insiders. These comments and attachments will be invisible to other users who are not members of the insiders group even if the bugs to which they apply are visible. Other insiders will see the comments and attachments with a visual tinting indicating that they are private. Enterprise Group Support ------------------------ The 55 group limit is now gone along with the groupset and blessgroupset bitset fields. Each user is now a member of a list of groups. It is now possible to define a group in terms of other groups as well as to place individual users in a group directly. Bugzilla now keeps track of whether a user was added to a group via a regular expression match or whether they were explicitly added to that group. Changes to regular expressions for group membership now take effect instantly for all users when updated, and no longer apply only to new accounts. If a member no longer matches the group's regexp, and they were originally added to that group because they matched the regexp, they are removed from that group. Note that the upgrade process has no way to know who was added to a group explicitly and who was added by a regexp, so all members of a group prior to this feature will remain members of that group until explicitly removed from it via the user editor, wether they still match the regexp or not. Estimated/Actual/Remaining Time ------------------------------- If the timetrackinggroup parameter is defined, members of the named group get controls for tracking the time spent fixing a bug added to the bug form. Any time comments are added to the bug, members of the time tracking group can add an amount of time they spent, and it's figured into the total and displayed at the top of the bug. Shown in the bug are your original estimate, the amount of time spent so far, the revised estimate of how much time is remaining, and your gain/loss on the original estimate. Support for database replication -------------------------------- The shadow database is a read-only copy of the Bugzilla database which can be used for queries. Until now, keeping the main database in sync with the shadow was handled internally by Bugzilla. This has several issues with performance, stability, and accuracy, and so Bugzilla now supports using MySQL's replication to handle the mirroring (bug 124589). As announced before the release of Bugzilla 2.16, the only supported way for a read-only database will soon become replication (bug 180870). It is not expected that this will cause any problems for sites, as the only installation known to be using the shadowdb is bugzilla.mozilla.org. The old code will be removed from Bugzilla as soon as bmo upgrades, and well before the next stable release (2.18). Miscellaneous Improvements -------------------------- 2.17.1 also introduces a number of general improvements; these features are now available on bmo. * Autolinkification Page - It's now possible to apply Bugzilla's comment hyperlinking algorithm to any text you like. This should be useful for status updates and other web pages which give lists of bugs. The bug links created include the subject, status and resolution of the bug as a tooltip. * There are more tags on the links toolbar for navigating quickly between different areas * Buglists are now available as comma-separated value files (CSV) (link at the bottom) * Keywords and dependencies can now be entered during initial bug entry * The performance of some queries and CGIs has been improved; unfortunately, some have also gotten worse; "hey, that's life." Trunk Checkins Since the Last Status Update =========================================== The following is a list of specific bugs fixed (and their checkin messages) since the last Bugzilla status report. It is ordered by the checkin date, as ordered by Bonsai. It includes checkins on the trunk from 09/22/2002 to 11/17/2002. This list was generated by filtering Bonsai's output on that query. Bold italic bugs are security-sensitive bugs. Checkins made without reference to any specific bugs: * Various build bustage fixes (Myk and JayPee) * (11/4/2002) Some installation documentation updates (mbarnson) Checkin manifest: (omitted for brevity - please see the online version [link at the top of this email]) 2.16-Branch Checkins Since the Last Status Update ================================================= None. 2.14-Branch Checkins Since the Last Status Update ================================================= None. The Bugzilla team will stop officially supporting the 2.14 branch after December, 2002. All 2.14 users are strongly encouraged to upgrade to the 2.16 branch to pick up new features, such as template support, request tracking, and improved attachment handling, among tons of other goodies. Copyright ? 2002 The Mozilla Organization. -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From justdave at syndicomm.com Tue Nov 19 12:46:21 2002 From: justdave at syndicomm.com (David Miller) Date: Tue, 19 Nov 2002 07:46:21 -0500 Subject: Security announcement for cvs pulls of Bugzilla Message-ID: There have been a few security bugs fixed in Bugzilla in the last week. The bugs listed here did NOT affect any released version of Bugzilla, but only versions of Bugzilla pulled from CVS during the time periods listed with each bug (+/- 15 minutes due to cvs-mirror lag). If you pulled a copy of Bugzilla from CVS during one of the time periods listed below, you are advised to update to the cvs-tip using the "cvs update -AdP" command, then re-run checksetup.pl. --------------- Bug 178841 - attachment file name field contained full path 2002/09/21 16:57:07 to 2002/11/09 01:23:07 US/Pacific The patch which allowed downloading an attachment to suggest a filename to be used for downloading (instead of attachment.cgi) also introduced the capability to display and edit that attachment name on the edit attachments page. It was discovered that some older browsers violated the RFCs on file uploads and submitted the entire local pathname for the file instead of just the name of the file itself. To be affected, an uploader of the attachment would have to have been using one of those browsers which leaked this information when the upload took place. The patch checked in to fix this causes checksetup.pl to check all existing attachments for full paths in their filenames, and removes the portion of the path prior to the basename of the file, and also strips the pathname off if the browser submits a file with a full pathname. --------------- Bug 179491 - Search of attachments data didn't enforce insiders 2002/08/19 21:17:20 to 2002/11/12 01:58:02 US/Pacific It was possible to search on attachment titles/status, and get results even if you couldn't see the attachment. Only existence or absence could be tested; the exact contents and description of the summary remained hidden. This only affects installations who used the 'insidergroup' feature. --------------- Bug 180545 - people without editbugs could change product/component 2002/08/12 05:42:55 to 2002/11/18 04:27:34 US/Pacific People who were not in the editbugs group could change the product or component of a bug. This was a regression from the conversion to using ID numbers instead of names for products and components internally. The routine which was checking the permissions was looking for changed to the product name (which was no longer getting changes submitted for it) rather than changes to the product ID number. The change was still logged in the activity log and mails were still sent out (as would happen with a permitted user changing these fields). --------------- -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From justdave at syndicomm.com Tue Nov 26 07:50:04 2002 From: justdave at syndicomm.com (David Miller) Date: Tue, 26 Nov 2002 02:50:04 -0500 Subject: [ANN] Bugzilla 2.17.1 Released Message-ID: The Bugzilla Team is pleased to announce the posting of Bugzilla 2.17.1, a snapshot of the current development sources from CVS. Bugzilla 2.17.1 is a Development Release and is intended for developers wishing to base large landings or patches off an official bugzilla.org release. It should not be used for production purposes, unless you have a Perl programmer on staff willing to put out any fires that may arise. The vast majority of sites wanting to test or use Bugzilla in production should continue to use version 2.16.1. To download 2.17.1, see http://www.bugzilla.org/download.html . Most of the details on new features available were posted in the last status update, which was posted here on November 18th, and is also available on our website at http://www.bugzilla.org/status_updates/2002-11-18.html#newfeatures -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From justdave at syndicomm.com Tue Nov 26 20:34:12 2002 From: justdave at syndicomm.com (David Miller) Date: Tue, 26 Nov 2002 15:34:12 -0500 Subject: XSS vulnerability in Bugzilla if upgraded from 2.10 or earlier Message-ID: Bugzilla Security Advisory November 26th, 2002 Severity: Minor Summary ======= The Bugzilla team recently discovered a cross-site scripting vulnerability. The vulnerability, present in Bugzilla's 'quips' feature, affects all installations who originally installed Bugzilla 2.10 or earlier and which have been upgraded from there. If you originally installed version 2.12 (released 2001 Apr 27) or later, or you have never had quips enabled, then you are not vulnerable to this attack. Vulnerability Details ===================== This vulnerability affects installations using the "quips" feature to put short, user-submitted phrases at the top of bug lists. 2.10 and earlier versions allowed users to enter unchecked input which was displayed as-entered back to the user. Version 2.12 and later attempted to fix this problem by preventing users from entering HTML in new quips, and also escaping existing quips when displaying them to users in the bug list. However, the output of existing quips from "show all quips" choice on the quips management page was not properly escaped, so any *existing* quips still in the database from before the input checks were put in place would be displayed to a user with unescaped HTML if they chose to view a list of all of the existing quips at once. If you originally installed a version older than 2.12, had quips enabled, and have not cleaned up your quips database since you upgraded to 2.12, your installation may contain scripting attacks in your quips file from ages ago, still able to affect end users. Vulnerability Solutions ======================= The best way to fix this vulnerability is to audit the contents of your quips file. Quips are stored in the file 'data/comments' in Bugzilla 2.14.x and 2.16.x, and in the database, in a 'quips' table, in 2.17.x). In addition to auditing quips, Bugzilla administrators can also force quips to be properly encoded to prevent HTML attacks by applying one of the following one-line patches. The Bugzilla team recommends both auditing your quips and applying the patches. Because of the low severity of this vulnerability, the small size of the required changes to fix it, and the small number of installations believed in existence at the point in time when this was corrected for new installations, we have not released any updated versions of Bugzilla, however, these fixes have been checked into the associated branches (so if you update via CVS you'll get them) and will be included in any future versions we release. Please note that Bugzilla 2.14.x will no longer be supported after December 31, 2002, so Bugzilla 2.14.x sites are encouraged to upgrade to 2.16.1. Patch for Bugzilla 2.14.4: Index: quips.cgi =================================================================== RCS file: /cvsroot/mozilla/webtools/bugzilla/quips.cgi,v retrieving revision 1.1 diff -u -r1.1 quips.cgi --- quips.cgi 29 May 2001 04:01:48 -0000 1.1 +++ quips.cgi 22 Nov 2002 21:04:08 -0000 @@ -49,7 +49,7 @@ if (open (COMMENTS, ") { - print $_,"
\n"; + print html_quote($_),"
\n"; } close COMMENTS; } Patch for Bugzilla 2.16.1: Index: template/en/default/list/quips.html.tmpl =================================================================== RCS file: /cvsroot/mozilla/webtools/bugzilla/template/en/default/list/quips.html.tmpl,v retrieving revision 1.4.2.1 diff -u -r1.4.2.1 quips.html.tmpl --- template/en/default/list/quips.html.tmpl 23 May 2002 08:14:23 -0000 1.4.2.1 +++ template/en/default/list/quips.html.tmpl 22 Nov 2002 21:19:22 -0000 @@ -59,7 +59,7 @@
    [% FOREACH quip = quips %] -
  • [% quip %]
    • +
  • [% quip FILTER html %]
    • [% END %]
[% ELSE %] For Bugzilla 2.17 from CVS: Run a 'cvs update' to pick up the fix. Bugzilla 2.17.1 already contains this fix. For More Information ==================== References: Bugzilla bug 179329 http://bugzilla.mozilla.org/show_bug.cgi?id=179329 General information about the Bugzilla bug-tracking system can be found at http://www.bugzilla.org/ Comments and follow-ups can be directed to the netscape.public.mozilla.webtools newsgroup or the mozilla-webtools mailing list; http://www.mozilla.org/community.html has directions for accessing these forums. -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/