RT Training Reminder — Amsterdam, Netherlands — March 20th & 21st, 2013

Best Practical Solutions provides unparalleled instruction in how to get the most out of RT.

Our first training session of 2013 will be held in Amsterdam on March 20th and 21st. We only have a few spots remaining so register soon or we may not be able to guarantee you a seat.

If you can't make it to this training session, feel free to drop us a line to suggest locations for the future.

This training will introduce you to the new features in RT4 as part of a comprehensive overview of RT. Whether you're an old hand at RT or a recent convert, you'll have a good understanding of all of RT's features and functionality by the end of the session.

The first day starts off with a tour of RT's web interface and continues with a detailed exploration and explanation of RT's functionality, aimed at non-programmer RT administrators. We'll walk through setting up a common helpdesk configuration, from rights management, constructing workflows and notifications, and the basics of Lifecycles.

The second day of training picks up with server-side RT administration and dives into what you need to safely customize and extend RT. We'll cover upgrading and deploying RT, database tuning, advanced Lifecycle configurations, writing tools with RT's API, building an extension, and demonstrate how to extensibly alter the web UI and internal functions.

It goes without saying that you'll get the most out of training if you attend both days of the course, but we've designed the material so that you can step out after the first day with a dramatically improved understanding of how to use RT or show up on the second day and get quickly up to speed on how to make RT do your bidding.

Pricing and Payment

The cost of the class includes training materials, a continental breakfast and an afternoon snack. Please note that lunch will not be provided.

Single Day - USD 995
Both Days - USD 1495 (25% savings)

Please contact us at training@bestpractical.com for discounted pricing if you are from an academic institution or if you'd like to send more than 3 people.

If you'd like to pay with Visa, MasterCard or Discover, please visit Best Practical's online store. Unfortunately we are unable to accept American Express or PayPal.

If you'd prefer to pay with a purchase order, please email us at training@bestpractical.com. Be sure to include:

  • If you want to attend both days or a single day
  • Full names and email addresses of attendees

Please also contact us at training@bestpractical.com for discounted pricing if you are from an academic institution or if you'd like to send more than 3 people.

Share this post:

Security vulnerability in Perl

This is a notification of a security vulnerability, not in RT, but inperl itself. That vulnerability, CVE-2013-1667, affects all production versions of perl from 5.8.2 to 5.16.x.

From perl5-porters:

In order to prevent an algorithmic complexity attack against its
hashing mechanism, perl will sometimes recalculate keys and
redistribute the contents of a hash.  This mechanism has made perl
robust against attacks that have been demonstrated against other
systems.
Research by Yves Orton has recently uncovered a flaw in the
rehashing code which can result in pathological behavior.  This flaw
could be exploited to carry out a denial of service attack against
code that uses arbitrary user input as hash keys.

Vendors, including RedHat, Debian, and Ubuntu, were informed of this problem two weeks ago. Debian has pushed updated packages, and others are expected to do so soon. We encourage you to take these updates as soon as they are available.

We are aware that taking updated versions of some vendor perl packages (particularly with older releases of RedHat) may downgrade some modules that RT requires to run, causing breakages when RT is restarted. This is particularly known to be an issue with Scalar::Util, Sys::Syslog, and File::Temp.

For this reason, we suggest re-running rt-test-dependencies after you upgrade perl, to ensure that this has not occured. You can do this via running /opt/rt4/bin/rt-test-dependencies, and passing it one of --with-mysql, --with-pg, or --with-oracle, as well as --with-fastcgi or --with-modperl2 as suits your current deployment. If unmet dependencies are found, you should immediately upgrade them; this can be done by re-running rt-test-dependencies with the additional --install option.

The vendor upgrades of perl may not be sufficient if you are running a locally-compiled version of perl. You can determine if this is the case by examining the first line of /opt/rt4/bin/rt (or /opt/rt3/bin/rt). If that line contains:

#!/usr/bin/perl

...then you are running the vendor-supplied version of perl, and need take no further steps. Otherwise, you will need to upgrade your locally installed perl, or re-install it after applying security patches. Perl 5.16.3 and 5.14.4 have now been released, and we strongly we recommend upgrading to those.

If you need help resolving this issue, please contact us at sales@bestpractical.com for more information.

Share this post:

RT Training in Amsterdam — March 20th & 21st, 2013

Best Practical Solutions provides unparalleled instruction in how to get the most out of RT.

Our first training session of 2013 will be held in Amsterdam on March 20th and 21st. As we like to keep class sizes relatively intimate, register soon or we may not be able to guarantee you a seat.

If you can't make it to this training session, feel free to drop us a line to suggest locations for the future.

This training will introduce you to the new features in RT4 as part of a comprehensive overview of RT. Whether you're an old hand at RT or a recent convert, you'll have a good understanding of all of RT's features and functionality by the end of the session.

The first day starts off with a tour of RT's web interface and continues with a detailed exploration and explanation of RT's functionality, aimed at non-programmer RT administrators. We'll walk through setting up a common helpdesk configuration, from rights management, constructing workflows and notifications, and the basics of Lifecycles.

The second day of training picks up with server-side RT administration and dives into what you need to safely customize and extend RT. We'll cover upgrading and deploying RT, database tuning, advanced Lifecycle configurations, writing tools with RT's API, building an extension, and demonstrate how to extensibly alter the web UI and internal functions.

It goes without saying that you'll get the most out of training if you attend both days of the course, but we've designed the material so that you can step out after the first day with a dramatically improved understanding of how to use RT or show up on the second day and get quickly up to speed on how to make RT do your bidding.

Pricing and Payment

The cost of the class includes training materials, a continental breakfast and an afternoon snack. Please note that lunch will not be provided.

Single Day - USD 995
Both Days - USD 1495 (25% savings)

Please contact us at training@bestpractical.com for discounted pricing if you are from an academic institution or if you'd like to send more than 3 people.

If you'd like to pay with Visa, MasterCard or Discover, please visit Best Practical's online store. Unfortunately we are unable to accept American Express or PayPal.

If you'd prefer to pay with a purchase order, please email us at training@bestpractical.com. Be sure to include:

  • If you want to attend both days or a single day
  • Full names and email addresses of attendees

Share this post:

RT 3.8.16 Released

I'm happy to announce that RT 3.8.16, the latest maintenance release, is now available.

Recent support for partitioned GnuPG emails introduced a deadlock situation for large QP/Base64 emails with GnuPG enabled. In addition, this release resolves a number of issues running the test suite on newer versions of perl.

Share this post:

RT::Extension::Announce Released

We recently released RT::Extension::Announce which gives you an easy way to insert announcements on your RT homepage so all users can see the message. You may want to display a banner during maintenance or maybe an unscheduled outage to make sure the people fielding customer tickets know that something is going on.

The messages are set and managed in a dedicated queue, created when you install the module. This allows you to manage who can post announcements using permissions on the queue. You can also show messages only to select groups if you don't need to notify everyone.

More details are available in the RT::Extension::Announce documentation. Bugs or comments welcome at bug-RT-Extension-Announce@rt.cpan.org, pull requests via github.

Share this post:

New documentation for RT

As we mentioned in September, we've been working on documentation and we've got some updates for you from our latest release.

Lifecycles

Lifecycles are a major new feature in RT 4 and the core documentation has been available in RT_Config.pm. We've added more documentation that walks through an example lifecycle customization to give you an idea how you might take advantage of this powerful feature.

Styling RT

If you've poked around the Configuration tab, you've probably found the RT Theme Editor. If not, it's described in the new RT Styling doc. We also offer some guidelines on adding custom CSS and even developing your own RT theme. If you create one, we'd love to hear about it!

RT Approvals

Setting up approvals in RT is described briefly in RT Essentials. Approvals are now explained more fully, with an example. We also improved the documentation for the CreateTickets action which is key to setting up the automatic creation of approval tickets.

Articles

Articles, formerly the RTFM extension and now part of core RT, now has documentation explaining setup, configuration, and usage.

RT Backups

We often get questions about what you need to back up to make sure you can retore your RT instance, so we've published our general backup guidelines.

Loading RT Objects

If you've installed RT or an RT extension that creates a template or scrip, you've run the make initdb or make upgrade-database commands. These commands process files that contain various RT objects and create them in your RT database. The syntax of these initialdata files is now documented which should make it much easier for extension authors to include RT objects with their extensions.

General Documentation Cleanup

We've continued to clean up our POD and improve our documents, most notable adding images and screenshots which you can see in our Lifecycles and styling docs.

We hope you find these new documents useful. We'll continue to improve and expand on our documentation so you can get the most out of all the features of RT. If you find incorrect information or want to suggest improvements, you can file bug reports at rt-bugs@bestpractical.com or send us a pull request on github.

Share this post:

RT 4.0.10 Released

I'm happy to announce that RT 4.0.10 is now available.

This release contains several bugfixes and a fix for a regression introduced in 4.0.9. If you have a Queue configured so that users have SeeQueue and CreateTicket but not ShowTicket (they can create tickets, but won't be able to see them after creation) then any Custom Fields assigned to that Queue and filled in during creation would be lost during submission.

A complete changelog is available.

Share this post:

RT Users Survey

We were wondering what configurations of RT our users are running, what you're doing with RT, and what you'd like to do, so we thought we should just ask: take the RT Users Survey.

The survey has some questions geared toward the administrators who maintain RT or power users who are responsible for its care and feeding locally. There are also questions about using RT and new features you'd like to see. We're interested in a range of responses so please feel free to forward to anyone else who maintains or is an active user of RT.

Thanks!

Share this post:

RT 4.0.9 Released

I'm happy to announce that RT 4.0.9 is now available.

This release contains a number of bugfixes since the 4.0.8 release. It also contains the first set of embargoed security tests fixed by patches released on 2012-05-22. These are the tests for vulnerabilities fixed in RT 4.0.6 and RT 3.8.12.

This release also requires a newer HTML::RewriteAttributes. You will be prompted to upgrade when upgrading RT or when manually running 'make test-dependencies'.

If you have set a custom @JSFiles in RT_SiteConfig.pm, you will need to amend this to include the new jquery.cookie.js file added to RT_Config.pm. See UPGRADING-4.0 for more details.

A complete changelog is available.

Share this post:

Security vulnerabilities in RT

We have determined a number of security vulnerabilities which affectboth RT 3.8.x and RT 4.0.x. We are releasing RT versions 3.8.15 and 4.0.8, and RTFM version 2.4.5, to resolve these vulnerabilities, as well as patches which apply atop all released versions of 3.8 and 4.0.

The vulnerabilities addressed by 3.8.15, 4.0.8, and the patches include the following:

All versions of RT are vulnerable to an email header injection attack. Users with ModifySelf or AdminUser can cause RT to add arbitrary headers or content to outgoing mail. Depending on the scrips that are configured, this may be be leveraged for information leakage or phishing. We have been assigned CVE-2012-4730 for this vulnerability; we would like to thank Scott MacVicar for bringing this matter to our attention.

RT 4.0.0 and above and RTFM 2.0.0 and above contain a vulnerability due to lack of proper rights checking, allowing any privileged user to create Articles in any class. We have been assigned CVE-2012-4731 for this vulnerability.

All versions of RT with cross-site-request forgery (CSRF) protection (RT 3.8.12 and above, RT 4.0.6 and above, and any instances running the security patches released 2012-05-22) contain a vulnerability which incorrectly allows though CSRF requests which toggle ticket bookmarks. We have been assigned CVE-2012-4732 for this vulnerability; we would like to thank Matthew Astley for bringing this to our attention.

Additionally, all versions of RT are vulnerable to a confused deputy attack on the user. While not strictly a CSRF attack, users who are not logged in who are tricked into following a malicious link may, after supplying their credentials, be subject to an attack which leverages their credentials to modify arbitrary state. While users who were logged in would have observed the CSRF protection page, users who were not logged in receive no such warning due to the intervening login process. RT has been extended to notify users of pending actions during the login process. We have been assigned CVE-2012-4734 for this vulnerability; we would like to thank Matthew Astley for bringing this to our attention.

RT 3.8.0 and above are susceptible to a number of vulnerabilities concerning improper signing or encryption of messages using GnuPG; if GnuPG is not enabled, none of the following affect you. We have been assigned CVE-2012-4735 for the following related vulnerabilities:

  • When using GnuPG, RT now clarifies the concepts of signing for integrity and signing for authentication, which are separate (and exclusive) concepts. Previously, enabling the "Sign by default" queue configuration began signing automatically-generated messages with the queue's key, in addition to defaulting emails sent from the web UI to being signed. This provides integrity, but causes emails signed with that key to no longer possess authenticity; no individual email is guaranteed to have come from an actor designated to act for that key, in the case of automatically-generated emails.

    RT has now changed the "Sign by default" checkbox to merely provide a default in the web UI when composing messages; it no longer affects automatically-generated outgoing messages. Thus the "Sign by default" option helps to provide authenticity. A separate queue configuration option, "Sign all auto-generated mail" (defaulting to off) now controls the signing of automatically- generated emails, which (when used in combination with the previous option) helps provide integrity of all outgoing messages.

    Users who had previously checked "Sign by default" and who wish to maintain the previous effect of integrity but not authenticity will need to enable the new option as well.

    We would like to thank Matthijs Melissen (University of Luxembourg) for bringing this matter to our attention.

  • RT 3.8.0 and above contain a vulnerability which allows incoming emails to force all triggered outgoing mail to be signed and/or encrypted.

  • RT 3.8.0 and above contain a vulnerability which allows incoming emails to incorrectly appear in the UI to have been encrypted when they had not been. This vulnerability only applies to encryption, not signing.

  • RT 3.8.0 and above contain a vulnerability which allows any user who is capable of sending signed email in the UI to do so using any secret key stored in RT's keyring.

Additionally, RT 3.8.0 and above contain a vulnerability which allows a user to pass arbitrary arguments to the command-line GnuPG client, which could be leveraged to create arbitrary files on disk with the permissions of the webserver. This vulnerability only applies if GnuPG is enabled, and does not allow for execution of programs other than the command-line GnuPG client. We have been assigned CVE-2012-4884 for this vulnerability.

If you are running 3.8.x and RTFM, you will need to install RTFM 2.4.5 to resolve CVE-2012-4731. Patches for all releases of 3.8.x and 4.0.x are available for download; The README within it contains instructions for applying the patches. Otherwise, we recommend upgrading to RT 4.0.8, which resolves the above vulnerabilities.

If you are using RT::Authen::ExternalAuth, you also need to upgrade it to version 0.12 for compatibility with the security fixes in RT 4.0.8, 3.8.15, and the patches.

Share this post: