New features:

• You can now create a new attachment simply by pasting some text into a text field, in addition to the normal upload process for attachments.
• By default, bugmails (email notifications about changes to bugs) are now sent in an HTML format that is more readable than the old text format. Those who prefer the old text format can still choose it in their Preferences, however.
• The Custom Search section in the Advanced Search page has been redesigned to work in a more sensible way. Complex queries are easier to build and have more sensible results, as they are built using a more intuitive logic. Some very complicated queries are still impossible to generate, though. Things should improve in future releases.
• Older components, versions and milestones can now be disabled. Bugs already using them are not affected, but these values will no longer be available for new bugs.
• A custom field can now be displayed based on multiple values of another field. (For example, one custom field could now appear in multiple products.) Previously, you could only display a custom field based on a single value of another field.
• Most changes made through the admin interface are now logged to the database, in the audit_log table. There is no UI to access this table yet.
• A project has started thanks to Francisco Donalisio from IBM to make Bugzilla compliant with the W3C Web Accessibility Initiative standards. A lot more work still needs to be done, but we expect a much better compatibility for the next major release.

• A CSRF vulnerability in the implementation of the XML-RPC API when running under mod_perl could be used to make changes to bugs or execute some admin tasks without the victim's knowledge.

This defect does not affect any devZing customers. However, all new devZing hosted Bugzilla installs will be created with Bugzilla 4.0.5.

You can read more about the release at the Bugzilla site.

A number of changes were released to address this http://www.bugzilla.org/security/3.4.13/:

• When a user creates a new account, Bugzilla doesn't correctly reject email addresses containing non-ASCII characters, which could be used to impersonate another user account. Such email addresses could look visually identical to other valid email addresses, and an attacker could try to confuse other users and be added to bugs he shouldn't have access to.
• Due to a lack of validation of the Content-Type header when making POST requests to jsonrpc.cgi, a possible CSRF vulnerability was discovered. If a user visits an HTML page with some malicious JS code in it, an attacker could make changes to a remote Bugzilla installation on behalf of the victim's account by using the JSON-RPC API. The user would have had to be already logged in to the target site for the vulnerability to work.

Source: Duncan Mac-Vicar

This downtime will last approximately 10 hours.

During this time all equipment will be moved to a new data center. Because this move is an entire data center and not just devZing equipment we do not have any flexibility with regard to the timing of this downtime.

As a result of this move our IP addresses will be changing.

If you have a custom domain name please make sure you are using a CNAME record pointing to app.devzing.com rather than an A record pointing to our IP address.

Please be advised that there will be an extended system outage starting December 3 03:00 UTC (Dec 2 22:00 New York, Dec 3 14:00 Sydney).

This downtime will last approximately 10 hours.

During this time all equipment will be moved to a new data center. Because this move is an entire data center and not just devZing equipment we do not have any flexibility with regard to the timing of this downtime.

As a result of this move our IP addresses will be changing.

If you have a custom domain name please make sure you are using a CNAME record pointing to app.devzing.com rather than an A record pointing to our IP address.

Please be advised that there will be an extended system outage starting November 26 03:00 UTC (Nov 25 22:00 New York, Nov 26 14:00 Sydney).

This downtime will last approximately 10 hours.

During this time all equipment will be moved to a new data center. Because this move is an entire data center and not just devZing equipment we do not have any flexibility with regard to the timing of this downtime.

As a result of this move our IP addresses will be changing.

If you have a custom domain name please make sure you are using a CNAME record pointing to app.devzing.com rather than an A record pointing to our IP address.

Now you can file bugs simply by sending an email.

Bugzilla, hosted by devZing, has a feature that allows a user to send an email to an email address. Bugzilla reads the email and automatically puts the bug into tracking phase.

Interested? Here’s how it works...

Set up

Administrators: Start with an email address your users can send their defects and comments to. Log into your devZing account (http://devzing.com/login) and click the Manage Global Settings link and scroll down to the Email Bugs section.

Enter the information about your email account.

The port number depends on how the mail server is set up.

Typical port assignment:

POP3=110, IMAP=143, Secure IMAP (IMAP4-SSL)=585, IMAP4 over SSL (IMAPS)=993, Secure POP3 (SSL-POP)=995.

If you don’t know the value for one of the fields check with your System Administrator. (Or check your email provider’s help documents.)

Helpful hint: Use the devZing history section to track errors once users start sending emails.

Sending the Emails

Users must follow a few guidelines when they send emails to the administrator. These are necessary steps to enable Bugzilla to receive and correctly read the emails.

First get the email address from your Bugzilla administrator. Your email address must be the same address you use to login to Bugzilla.

Subject Line: Put a summary of the bug as your subject line.

Follow this guide for writing the email contents...

Any fields (see below) must be specified before your bug description.

Here is a list of all the different fields you can specify in your email:

* The value must match exactly one of the names defined in your Bugzilla for this field.
** It is possible that your Bugzilla administrator has provided a default value for this field.

In addition to the above parameters, if your installation has any custom fields, you can set them just by passing in the name of the field and its value as a string.

The values for the fields can be split across multiple lines, but note that a newline will be parsed as a single space, for the value. So, for example:

@summary This is a very long
description

Will be parsed as "This is a very long description".

Note that signatures must start with '-- ', the standard signature border.

Modifying an Existing Bug

Bugzilla determines what bug you want to modify in one of two ways:

• Your subject starts with [Bug 123456] -- then it modifies bug 123456.
• You include @id 123456 in the first lines of the email.

If you do both, @id takes precedence.

You send your email in the same format as for creating a bug, except that you only specify the fields you want to change. If the very first non-blank line of the email doesn't begin with@, then it will be assumed that you are only adding a comment to the bug.

Note that when updating a bug, the Subject header is ignored, except for getting the bug ID. If you want to change the bug's summary, you have to specify @summary as one of the fields to change.

Please remember not to include any extra text in your emails, as that text will also be added as a comment. This includes any text that your email client automatically quoted and included, if this is a reply to another email.

Errors

If your request cannot be completed for any reason, Bugzilla will send an email back to you. If your request succeeds, Bugzilla will not send you anything.

If any part of your request fails, all of it will fail. No partial changes will happen.

Caution

The script does not do any validation that the user is who they say they are. That is, it accepts any 'From' address, as long as it's a valid Bugzilla account. So make sure that your MTA validates that the message is actually coming from who it says it's coming from, and only allow access to the inbound email system from people you trust.