- Koha-devel - lists.koha-community.org

Optimisation and DBI::ping
by Robin Sheat 16 Oct '13

16 Oct '13

I've been doing a bit of profiling, focussing on opac-search, as it's terribly slow at times. See: http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11051 for what I've looked at so far. There's one thing I'd like some comments on. http://debian.koha-community.org/~robin/opac-search-cached/nytprof/usr-shar… All the pings take 1.36 seconds, which is a huge amount. It's not helped that Context::dbh is called 1423 times, I'm working on that too (many things that are called inside a tight loop, rather than grabbing all the data you might need in one go and putting it into a hash or something.) Is there a situation where the ping is likely to be required? It'd be easy to strip it out, but are there likely to be bad effects that can't be worked around? For context, I'm profiling this on a system with a remote database so that latency shows up a bit more than it would in a typical dev environment. As that's what many production systems are using, this is not atypical. The DBI docs: http://search.cpan.org/~timb/DBI-1.623/DBI.pm#ping say "Few applications would have direct use for this method. See the specialized Apache::DBI module for one example usage" so it might be reasonable to just pull it out. Any thoughts? Also have a look at the two other patches: one illustrating that caching actually slows things down some times, and the other just changing a query repeated once per branch, to just run once. -- Robin Sheat Catalyst IT Ltd. ✆ +64 4 803 2204 GPG: 5FA7 4B49 1E4D CAA4 4C38 8505 77F5 B724 F871 3BDF

2 2

First alpha of Koha 3.14 released
by Galen Charlton 15 Oct '13

15 Oct '13

Hi, I have tagged and cut the first alpha of Koha 3.14. The tarball can be retrieved from: http://download.koha-community.org/koha-3.14.00-alpha1.tar.gz The following files can be used to check the integrity of the tarball: http://download.koha-community.org/koha-3.14.00-alpha1.tar.gz.sig http://download.koha-community.org/koha-3.14.00-alpha1.tar.gz.MD5 http://download.koha-community.org/koha-3.14.00-alpha1.tar.gz.MD5.asc The script-generated release notes can be read at: http://git.koha-community.org/gitweb/?p=koha.git;a=blob_plain;f=misc/releas… This first alpha should be considered a preliminary smoke testing version, as I have some more large merges to get through this week. I expect to cut a second alpha during KohaCon's hackfest, with a beta to follow shortly thereafter as the condition of master warrants. Regards, Galen -- Galen Charlton Manager of Implementation Equinox Software, Inc. / The Open Source Experts email: gmc(a)esilibrary.com direct: +1 770-709-5581 cell: +1 404-984-4366 skype: gmcharlt web: http://www.esilibrary.com/ Supporting Koha and Evergreen: http://koha-community.org & http://evergreen-ils.org

1 0

Call for news for the October newsletter (especially re KohaCon13!)
by Daniel Grobani 15 Oct '13

15 Oct '13

Dear Koha kommunitarians, I'm harvesting news for this month's newsletter. Please send me by the 27th anything you think your fellow community members might like to know about. And all you lucky #kohacon13 attendees, here's your chance to share your experience with the community in more than 140-character chunks! "News" can be as short as a sentence or as long as a paper. I especially encourage you to send me a line or two for the gossip/society column about what you're currently working on. And if you know of a go-live not announced on the list, please be sure to let me know about it. Thanks, Daniel Grobani

1 0

vm for koha
by Samuel Desseaux 14 Oct '13

14 Oct '13

Hi, I'm preparing vm for koha, as i've said a few weeks ago. I've 2 vm *one, in french, for unimarc users *the other, in english, for marc21 users the size is nearly 1 Go. Is it ok for upload it to one of the koha servers ? Best regards Samuel

2 1

find old bugs to sign off
by Mathieu Saby 13 Oct '13

13 Oct '13

Hi The bot on bugzilla is really a great great idea :-) But now, we can't find really old bugs to sign off, because if the bot can sign off, the date of "last change" of the bug is updated. So for ex, this patch that I submitted in april 2013 is marked "modified 2013-09-24" http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10138 and the "10 oldest bugs to sign off" on Koha dashboard are not the oldest at all. http://dashboard.koha-community.org/ Do you think it would be possible to keep the advantage of having bot running on BZ and to restore the ability to see the oldest bugs waiting for sign off (maybe there is a way to find the date when the "Need sign off" status was given to a bug?) ? By the way, is someone in community, or within some vendor staff, dedicated to the signing off of oldest bugs? M. Saby -- Mathieu Saby Service d'Informatique Documentaire Service Commun de Documentation Université Rennes 2 Téléphone : 02 99 14 12 65 Courriel : mathieu.saby(a)univ-rennes2.fr

1 0

Re: [Koha-devel] Crashes on new Opac Recent Searches cookie in older Koha versions
by Paul 12 Oct '13

12 Oct '13

At 12:54 PM 10/12/2013 +1300, Chris Cormack wrote: >On 12 October 2013 11:16, Paul <paul.a(a)aandc.org> wrote: > > At 12:26 PM 10/11/2013 -0700, Galen Charlton wrote: > > > > "Name based" v. "port based", "Nasty side effects" and "negative data" > raise > > flags with me. I've just looked up bug 10657 which either blind-sides me > > with science or baffles me with bull. "Storable" and references to " > >I totally would not have gone there with the inference that Galen was >talking bull, but hey if that's how you want to go, each to their own. Please... I was only saying that *I* was confused (blind-sided or baffled) by the Subject: of the email "Crashes..." in the context of Bug 10657. The Perl references to "crashing" were (I believed, perhaps incorrectly) taken care of when I disabled EnableOpacSearchHistory. The phrases that I quoted (maybe out of context?) did not reassure me. I still haven't had time to fully sandbox test the changes <http://git.koha-community.org/gitweb/?p=koha.git;a=commitdiff;h=eeedee8c987…> to C4/Auth.pm, opac/opac-search-history.pl and opac/opac-search.pl for use within our stable production 3.8.5 -- nor to consider a full system upgrade from 3.8.5. As you well know, I'm a believer in system stability over a two year period, à la LTS, with only security upgrades. In 2014, we'll look into whatever the latest Koha release might be. In the meanwhile, I believed (again perhaps incorrectly) that by disabling some functionality (OPAC search history) we had the well-publicized security concern under control. Until I saw "crashing" in the context of Bug 10657 and the mention by Marcel de Rooy of two commits not referencing bug numbers .... I was asking for clarification -- and certainly had no intention whatsoever of questioning Galen's integrity. If Galen read it that way, I apologize unreservedly to him. Without wanting to excuse myself, please remember that I am generally much more comfortable writing in French rather than in English. Regards - Paul > > > > checked for JSON-correctness and is ignored" are > > meaningless without context. > > > > If there really is a security aspect would someone please explain it? > > >Or the implication that he was lying. > >Of course there was a security aspect, and that's why we did security >releases for 3.12.x, 3.10.x and 3.8.x. >If you read the release notes > http://koha-community.org/security-release-july-2013/ > >And you snipped some lines out of context, and complain for them being >out of context. > >Here is the whole thing, for context. > >"When EnableOpacSearchHistory system preference is enabled, Koha >stores recent search history for anonymous OPAC sessions in a cookie >called KohaOpacRecentSearches. In particular, it used to use the >Storable Perl module to serialize the array of hashrefs representing >the recent searches. > >However, the documentation for Storable strongly recommends [1] that >data to be deserialized *not* come from untrusted sources -- and >cookies cannot be considered trustworthy, as most web browsers (to say >nothing of curl) allow the user to modify them. There is a >theoretical possibility that a modification to the >KohaOpacRecentSearches cookie could result in the execution of >unauthorized code with the privileges of the Apache backend process. > >The 29 July 2013 security update resolves the security issuing by >replacing use of the Storable module with the JSON, which doesn't by >default serialize blessed references and does not attempt to >deserialize and execute coderefs. The payload of the cookie is >checked for JSON-correctness and is ignored if it doesn't contain a >valid (double-URI-encoded) JSON object. In particularly, any old >Storable-based cookies are silently ignored. > >[1] http://perldoc.perl.org/Storable.html#SECURITY-WARNING " > >If you read the link that is provided there it says > >"Do not accept Storable documents from untrusted sources! >Some features of Storable can lead to security vulnerabilities if you >accept Storable documents from untrusted sources. Most obviously, the >optional (off by default) CODE reference serialization feature allows >transfer of code to the deserializing process. Furthermore, any >serialized object will cause Storable to helpfully load the module >corresponding to the class of the object in the deserializing module. >For manipulated module names, this can load almost arbitrary code. >Finally, the deserialized object's destructors will be invoked when >the objects get destroyed in the deserializing process. Maliciously >crafted Storable documents may put such objects in the value of a hash >key that is overridden by another key/value pair in the same hash, >thus causing immediate destructor execution. >In a future version of Storable, we intend to provide options to >disable loading modules for classes and to disable deserializing >objects altogether. Nonetheless, Storable deserializing documents from >untrusted sources is expected to have other, yet undiscovered, >security concerns such as allowing an attacker to cause the >deserializer to crash hard. >Therefore, let me repeat: Do not accept Storable documents from >untrusted sources! >If your application requires accepting data from untrusted sources, >you are best off with a less powerful and more-likely safe >serialization format and implementation. If your data is sufficently >simple, JSON is a good choice and offers maximum interoperability." > >So we were accepting Storable documents from untrusted sources (the >entire internet) and this bug stops that happening. > >I respectfully request you think about the way you phrase your >questions in the future, so they sound like questions not insults. > >Chris --- Maritime heritage and history, preservation and conservation, research and education through the written word and the arts. <http://NavalMarineArchive.com> and <http://UltraMarine.ca>

1 0

Re: [Koha-devel] Crashes on new Opac Recent Searches cookie in older Koha versions
by Paul 12 Oct '13

12 Oct '13

At 12:26 PM 10/11/2013 -0700, Galen Charlton wrote: >On Thu, Oct 10, 2013 at 3:17 AM, Marcel de Rooy ><<mailto:M.de.Rooy@rijksmuseum.nl>M.de.Rooy(a)rijksmuseum.nl> wrote: >I have been looking for these patches on Bugzilla, but I cannot find them. [snip] >The patches lack a bug number because of a chicken-and-egg problem, as the >bug couldn't be posted before the patches and the release announcement were. >These patches have a nasty side-effect. If you use an older Koha version >and also current master on the same system for testing, the old Koha >version will stumble over this (shared) cookie: [snip] >An alternative configuration which may better suit your needs is to use >name-based virtual hosts rather than port-based ones, which will perforce >ensure that the two versions don't share cookies. [snip] >Considering that the security release was made at the end of July, was >targeted at supported *and* unsupported versions, and was heavily >publicized, there is already a fair amount of negative data "Name based" v. "port based", "Nasty side effects" and "negative data" raise flags with me. I've just looked up bug 10657 which either blind-sides me with science or baffles me with bull. "Storable" and references to "checked for JSON-correctness and is ignored" are meaningless without context. If there really is a security aspect would someone please explain it? OFF-LIST if need be. Many thanks - Paul

2 1

Crashes on new Opac Recent Searches cookie in older Koha versions
by Marcel de Rooy 11 Oct '13

11 Oct '13

Hi, Recently two commits were added that move the search history cookie to a new format. commit 961617765ef25bde32cb050ad016f3b063661ef8 (no bug number, from Galen) commit 488a3d6fed57b4e0d773157ee4a6ab7e4775e7a4 (no bug number, from Galen) I have been looking for these patches on Bugzilla, but I cannot find them. Perhaps they are there, but I may have used the wrong search terms. These patches have a nasty side-effect. If you use an older Koha version and also current master on the same system for testing, the old Koha version will stumble over this (shared) cookie: Storable binary image v45.123 more recent than I am (v2.8) at /usr/lib64/perl5/Storable.pm line 416, at /usr/share/koha/maintclone/C4/Auth.pm line 293. So to overcome this problem, you must delete the KohaOpacRecentSearches cookie AND set preference EnableOpacSearchHistory to off in the old system. Deleting the search cookie every time, as updated by the master clone, is not really an option :) Since I cannot find the bug where this development was documented, I do not know if this side-effect was discussed, tested etc. But for changes like this, a question like: Can this change affect older Koha versions somehow? would be fine to address at the least.. Thanks, Marcel

4 4

OAuth2 Authentication of users
by Nicholas van Rheede van Oudtshoorn 11 Oct '13

11 Oct '13

Hello list! Wondering if there is anyone interested in giving me some feedback on the OAuth2 login system that I've written for Google OAuth. The login system is live and fully operational here at Perth Bible College ( library.pbc.wa.edu.au) - not that any of you will be able to test that, since your emails aren't registered to our system! :-) I would love someone with a bit more Perl-fu than me to let me know if there's anything glaringly stupid that I shouldn't have done / could do better. This is all the result of about 2 1/2 days of my fiddling! All the patches etc. are in bug 10988 ( http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10988 ) God bless, Nicholas van Oudtshoorn Perth Bible College

2 2

Kohacon 2014 in Córdoba, Argentina
by Mirko 09 Oct '13

09 Oct '13

Hi everybody, Kohacon 2014 will take place in Córdoba, Argentina! Congratulations! We have a clear vote of roughly 3:1. There are some duplicate votes on both sides which I will consider software or server errors :P and I will have a look at the unfinished votes later. I had one person saying they could not finish the vote, later telling me that it worked eventually. I cannot present final numbers at this point but the result is clear. I'd like to thank both Córdoba and Ibadan very much for offering to be hosts for our conference! -- Mirko

5 4