You can read the full text of the newsletter by visiting the following Evergreen wiki page.

To submit your own entries for the June newsletter, you can email Amy Terlaga at terlaga@biblio.org.

Evergreen 2.2 rc1 was just released today, 15 May 2012. This is the
release candidate. The Evergreen community hopes that Evergreen 2.2.0
will follow in just about two weeks, depending as always on feedback from
those who contribute their feedback after testing.

This release includes various bug fixes, please see the full list of
changes.

The 2.2 series includes many new features over the 2.1 series, including
the Template Toolkit OPAC (TPAC) and too many others to count.

Please report any new bugs on Launchpad.

I would like to particularly thank Thomas Berezansky, Ben Shum, Jason
Stephenson and Dan Scott for assisting in innumerable ways with the
mechanics of publishing this release candidate. I am surely neglecting a
couple of other folks whose help was invaluable, but at least they have
their karma.

Thanks everyone!

NOTE: At this time Evergreen 2.2 beta2 requires OpenSRF 2.1.0 [RC1]

Feedback and bug reporting will be much appreciated, this is one way you can help the community to weed out any remaning issues. Please report any new bugs or feedback to Launchpad.

Community Test Server Information
Evergreen Indiana has updated their bleeding edge testing server to this latest release for folks who want a quick preview.

Server Address: testing.evergreen.lib.in.us
JS OPAC: http://testing.evergreen.lib.in.us/opac/en-US/skin/default/xml/index.xml
TTPAC: http://testing.evergreen.lib.in.us/eg/opac/home
Staff Clients: http://testing.evergreen.lib.in.us/updates/manualupdate.html

Staff Client Credentials are as follows:
Login: admin
Password: open-ils

If you’re a student looking for a GSoC project to apply to, why choose Evergreen?  There are many reasons, both technical and community.  Evergreen qua software is a resource discovery and sharing system for libraries.  It can be used to run a library’s catalog, including checking out and checking in books and other materials, managing library patrons’ requests for materials, and helping the library acquire new stuff.  But it’s not just a specialized inventory tool; Evergreen is designed to handle very large groups of libraries that share both their materials and metadata about those items, while at the same time giving library patrons a way to find the books they want, even if sometimes a patron may not have a clear idea of what they want until they find it in the catalog.

Evergreen is a large, multi-layer application.  Are you a budding PostgresSQL DBA and developer?  There are lots of things you could do to enhance Evergreen.  Is your personal motto TMTOWTDI?  Ditto.  Are you a JavaScript guru?  Ditto.  Are you a C programmer who likes making fast network protocols even faster but couldn’t care less about the middle layer?  Ditto.  Are you focused on making interfaces more usable?  Ditto.  Do you like to break things, then figure out how to fix them?  Ditto.

But Evergreen is about more than just the code.  Our community is very active, and it’s not just made up of developers — both librarians who run Evergreen systems and patrons who use them are also to be found on the IRC channel (#evergreen on FreeNode) and mailing lists.  Some of the librarians are also coders, and some of the coders are also librarians.  If you ask a question about some odd thing that Evergreen does, you’ll find out not just how, but why.

So let’s say you’re ready to apply to be a GSoC student for the Evergreen project.  You’ve first got a bit of reading ahead of you:

• Register an account at the GSoC 2012 home page, then read carefully, particularly the timeline and FAQ.
• All done?  Great.  Please read the FAQ again.  If you have questions about the mechanics of applying, please feel free to email the GSoC org admins for the Evergreen project (Galen Charlton and Dan Scott) at <gsoc at evergreen-ils.org>, but please respect our time by checking the FAQ first.
• Next, check out our ideas page, which has suggestions for some projects as well as our expectations of students during the application and coding processes.
• Next, please read our (very brief) getting started with Evergreen development, our (longer) procedures for contributing, and our page about how we use Git.

“That’s a lot of reading!”, you might say… and you’d be right.  On the other hand, Evergreen is used by libraries, after all.

Ready to move on to the next step?  Get to know us a bit: join the general and development mailing lists and the IRC channel, hang out, listen, and ask good questions.  While you’re doing that, also keep in mind one of our application requirements:

As part of their application for the Google Summer of Code, we expect any student applicants to submit a patch or point to a branch that addresses some problem or adds some small enhancement. Bite-size bugs and new unit tests are good candidates to tackle. To help you get started, the community has put together a quick-start introduction and virtual image.

Please take that requirement seriously — Evergreen is not a trivial project; if you start trying to put a patch together an hour before the application deadline… you’re almost certainly too late to submit a good application.

So after you’ve read a bit, talked with us a bit, and patched Evergreen a bit… go ahead and fill out the GSoC application form and hit submit.

We look forward to working with you!

NOTE: At this time Evergreen 2.2 alpha3 requires OpenSRF 2.1.0

As usual testing, feedback and bug reporting will be much appreciated and a great way to contribute to the community. Please report any new bugs to Launchpad.

Community Test Server Information
For folks who want a quick look at go through the system Evergreen Indiana (Mike Peters) has updated their bleeding edge testing server to this latest release.

Server Address: testing.evergreen.lib.in.us
JS OPAC: http://testing.evergreen.lib.in.us/opac/en-US/skin/default/xml/index.xml
TTPAC: http://testing.evergreen.lib.in.us/eg/opac/home
Staff Clients: http://testing.evergreen.lib.in.us/updates/manualupdate.html

Staff Client Credentials are as follows:
Login: admin
Password: open-ils

Long story short, we’ve been able to figure out that Firefox 10 is reacting to particular CSS3 selector syntax combinations. A solid clue is if you check the JavaScript error console, you might see a warning like:

Warning: An unbalanced tree was written using document.write() causing data from the network to be reparsed.

The warning also links to Optimizing your pages for speculative parsing from the Mozilla project, which sort of helps; at least it is clear that the Firefox project is trading fault-tolerance for speed. One thing that is known to make it angry is attribute values without quotes; for example:

• query='datafield[tag=245]' /* breaks in Firefox 10 */
• query='datafield[tag="245"]' /* works in Firefox 10 */

We have also determined that CSS3 selector syntax that uses hierarchies is also broken, at least in some cases. For example:

• query='datafield[tag="245"] subfield[code="a"]' /* breaks in Firefox 10 */

The current recommended workaround is to wrap another dojo.query() function and
select the second element of the CSS2 selector syntax that way; for example:


<td type='opac/slot-data' query='datafield[tag="245"]'>
<script type='opac/slot-format'>< ![CDATA[
dojo.query('subfield[code="a"]', item).forEach(function(item) {
/* code you would have previously dumped directly in the script tag */
});
]]></script>
</td>


This isn't perfect, by any means, but it should get you on the road to getting Firefox 10 working better than it might be right now. If you want to see what we're doing at Conifer, you can follow along with our skins branch. (I'm trying not to put too much profanity in the commit messages).

Many thanks to Dan Wells for figuring out the CSS3 selector quoting; this Firefox 10 incompatibility absolutely blindsided us all and it's always nice to have a calm voice of reason sorting things out

It is advised that installations running a 1.6 version of Evergreen upgrade to the 2.0 or 2.1 series. To get the latest release and view upgrade instructions please visit http://evergreen-ils.org/downloads.php

Evergreen 2.1.1 represents the first major bug fix release of the 2.1 series.  You can view the full changelog here.

Evergreen 2.2-alpha1 is the first cut of the next 2.2 series.  Come be among the first to help test new features and functionality.  This release includes many new features, including the Template Toolkit OPAC (or Tpac, for short).  As always, please report any new bugs to Launchpad.

Unfortunately, we discovered a problem with the brute force fix that could lead to incorrect authentication failures. The problem was most evident in multi-brick environments, but could occur in any environment with more than one open-ils.auth child processing authentication requests. Consequently, we have released updated versions of the security fix releases, along with an updated version of the 2.1.0 release; the only difference in these tarballs is an updated version of oils_auth.c. The names of the releases are as follows and can be downloaded from the Evergreen downloads page as usual:

• 2.1.0a
• 2.0.10a
• 1.6.1.9a

Sites that have not yet upgraded to the announced security release are advised to upgrade to the “a” version of the release. Sites that have upgraded to the announced security release are advised to simply replace the oils_auth.so shared library, as described in the comment to this post by Dan Scott, using the “a” version of the release. The staff clients provided for the security release will continue to work with the fixed “a” version of the release.

Original security release announcement

Today, the Evergreen development team released Evergreen 2.0.10 and 1.6.1.9 – available from the downloads page -to address several security vulnerabilities and a handful of bug fixes. This post discusses the security vulnerabilities. If you are running Evergreen in production today, we encourage you to upgrade your Evergreen system to 1.6.1.9 or 2.0.10 as soon as possible.

Summary of issues fixed in 2.0.10 and 1.6.1.9

These releases include some protection against brute force guessing of weak passwords, such as four digit pins.

A running count of incorrect login attempts for a given user is maintained. After ten incorrect attempts, all attempts to login as that user will fail until the counter resets. By default, the counter resets after 90 seconds. Both the counter and the number of incorrect passwords are configurable. This change requires no client-side changes.

This release also includes a change which prevents the re-use of an authentication seed to obtain more than one authentication token. This change required a single client-side change where the staff client was inadvertently re-using a seed legitimately.

Additional issues fixed in 2.0.10

On the patron visible front there is a change to the OPAC to require that the user’s current password be provided before changes to username or email address can be made. This prevents someone who gains access to another user’s account, say due to a public or otherwise shared computer, from changing the email address and requesting a password reset. The username change requiring the user’s password helps keep someone from being “locked out” of their account because someone changed their username without the user knowing.

To continue on the password related fixes there is the removal of the password from the login screen after it is no longer needed. This prevents malicious code injected into the staff client from obtaining the password by pulling it out of the password entry box in plain text. As this code is contained 100% within the local staff client a client update is required.

Technical details: fixes in 2.0.10 and 1.6.1.9

The most significant vulnerability that has been addressed was the ability to brute force passwords. The authentication functions, available to the world via HTTP/HTTPS, have been given protection against repeated attempts to guess passwords. After a configurable number of failed login attempts each within a configurable time span from the previous failed attempt the system will treat all attempts as failures, even if they are otherwise valid and correct. The default is 10 attempts with 90 seconds between attempts. The system will unlock after the time between attempts has expired. This can be installed server-side without any client side changes.

Related to brute forcing of passwords is password replay attempts. If you can grab the auth.complete call within the auth seed’s validity period you can re-send the auth.complete data and get a new authtoken, without needing to know the seed or password. To protect against this the auth seeds are rendered invalid after a single use (successful or not). This requires a single client side change to cover the case where the client thinks it has a registered workstation and the server disagrees. In that case the client was, in effect, performing a replay attack as part of normal operations.