On Thursday, June 17th, we realized that the open-ils.pcrud service, which provides permission-protected access to Evergreen data in the 1.6 release series, was subject to a security vulnerability. The vulnerability allows a user to access objects outside of the permissions they have been granted by supplying fleshing arguments to the open-ils.pcrud search service.

By Thursday evening, a patch for the vulnerability had been committed to Evergreen trunk, and by Friday evening that patch had been backported to the 1.6.0 branch. The Evergreen 1.6.0.6 security release was uploaded on Tuesday June 22, and it took until late Friday June 26 to write up the upgrade instructions, release notes, and update the downloads page for the http://evergreen-ils.org Web site.

Today, we worked out how to apply just the security fix to a running system, so that Evergreen libraries can close the vulnerability without having to apply the full release upgrade. The procedure is as follows:

1. Download the fixed file: http://svn.open-ils.org/trac/ILS/export/16749/branches/rel_1_6_0/Open-ILS/src/c-apps/oils_cstore.c
2. Copy oils_cstore.c over Open-ILS/src/c-apps/oils_cstore.c in the source directory you used to install your Evergreen system
3. Run ‘make’ to compile the updated libraries
4. Install the chrpath tool (“aptitude install chrpath”)
5. Run “chrpath -d Open-ILS/src/c-apps/.libs/oils_pcrud.so” to enable the library to link to the appropriate location
6. Copy Open-ILS/src/c-apps/.libs/oils_pcrud.so.* to /openils/lib/.
7. Restart the Evergreen C services by running ‘osrf_ctl.sh -a restart_c’

If you are running Evergreen 1.6, we recommend that you apply this security fix as soon as possible, then upgrade to the latest release (1.6.0.6) when you have an opportunity. Evergreen sites running releases prior to 1.6 are not affected by this vulnerability.

Some of you may know that Lamar Veatch and I are working on an article on the history of Evergreen so we are busy with that work—and will possibly be posting bits and pieces here. I suspect that we will also assemble web-friendly materials for an online history somewhere but that in time.

Dr. Veatch and I were talking about previous posts on the PINES circulation traffic on the day after Memorial Day and here are those impressive numbers showing the load on PINES, updated through this year’s figures.

These numbers are yet another demonstration of the increasing demand on PINES libraries—as if we needed one—and that Evergreen can handle a great deal of traffic.

The increase in the figures from 2009 to 2010 is extraordinary. The busiest day of PINES has a 20% increase in total circulations over last year’s and the busiest hour of the busiest day (11AM-12PM) shows a 30% increase.

Maximum circulations by date and interval

Thanks to Mike Rylander and Don McMorris for these numbers.

When everyone digs out a bit, we will check the per minute figure for 2007. I think most of us have suspected that number is in error. Mike has a theory about how it was miscalculated.

The checkins are reported for 2010 for the first time and that number adds a dimension to this set of statistics that was missing before. As evocative as the circs figures are they do not capture all that was going on. We will include these data next time.

Previous posts in this thread: 2007; 2008, and 2009 was posted on open-ils-general on May 27, 2009 at 10:45:12.

Bob Molyneux

The two of us have seen aspects of the evolution of the Evergreen software ecosystem that was at once surprising and then obvious once it started to arise: the evolving superconsortium in the Evergreen community. This notion first occurred to us independently in early 2009 and, curiously, we each invented the same word to describe it: the Evergreen Superconsortium. Events since then, particularly one just before the Evergreen International Conference in Grand Rapids, have served to confirm our observations.

What is the Superconsortium? It is varied elements of Evergreen community working in concert to develop capabilities within the software and within the community. A library that is a member of a consortium may give up a bit of freedom of action but in return enjoy increased services for its users by cooperating and sharing resources with other consortium members. In the Evergreen Superconsortium, different consortia are cooperating on developing capabilities for Evergreen. It is another arrow in the Evergreen quiver.

The Evergreen Superconsortium

In the first case of superconsortial cooperative development, two systems joined in paying for development of capabilities that were given to the community through the GNU General Public License (GPL). This case was shepherded by Equinox.

Given the changes in the state of Evergreen—for instance, there are more groups using it now—superconsortial cooperative development recently started via independent action of several consortia (Bibliomation, King County, SITKA, and PINES) that are working together to develop a Kids’ Catalog for Evergreen and contracting with FGI, a Seattle based firm. This was a signal event in the history of Evergreen.

Even though these different consortia are doing different things and in different places, they are working towards common goals and the Kids’ Catalog—and Evergreen—will be stronger for it.

We can, then, expect more software development as Evergreen’s capabilities increase through this method as well as more traditional methods. Just last week, Amy Terlaga sent out an email about two enhancements Bibliomation is seeking to have developed and asked if others in the community wanted to help. The trail has been blazed.

Where we are

The Superconsortium arises out of two necessary but not sufficient conditions: open source development and a Consortial Library System. The two separately each create tools to increase the capabilities of libraries through the software they use. Of course, we in the open source communities believe that open source development will provide robust software with a rapid development cycle. What joined the two factors to create the Superconsortium are the strength of the community’s actors and their vision of a new way of doing things. Superconsortial cooperation will lead to even more rapid and better software development and information exchange (data? techniques and practices?) than we have seen so far.

Quo Vadis Evergreen Superconsortium?

It is hard to peer into the future and see what is next—certainly more development with the newer consortia and as members of the community get to know each other better.

There are also possibilities for Superconsortial purchases, for example. These consortia have to move items around from library to library. If they used RFID tags, they could maintain the control over their items that UPS and FedEx can: these companies know where everything is. Can libraries do worse? It would seem to be an easy argument to make in these times that this is a matter of fiduciary responsibility. However, RFID tags are expensive.

At ALA last year, one of us asked a vendor how much it would cost to buy 10 million RFID tags? Well, he said, we would have to bid it but I would guess they would be around 17 cents a piece. This year, the number would be lower. Perhaps a Superconsortium of Evergreen consortia could consider such pooled purchases thus making it resemble the purchasing consortia that are so common in libraries. Of course, we do not have an entity to manage such purchases. And 10 million would not be near enough.

Bob Molyneux and Mike Rylander