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

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

Koha General IRC Meeting 9 October 2013 at 10:00 UTC
by Owen Leonard 09 Oct '13

09 Oct '13

The next Koha General IRC Meeting is taking place 9 October 2013 at 10:00 UTC http://www.timeanddate.com/worldclock/fixedtime.html?msg=Koha+IRC+General+M… The agenda is here: http://wiki.koha-community.org/wiki/General_IRC_meeting,_9_October_2013 I hope to see you there, Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org

2 1

Copyright headers in new Koha files
by Robin Sheat 08 Oct '13

08 Oct '13

Hi, just a bit of a poke as I've noticed this in a number of places when I go looking to copy-paste an example from somewhere else: a lot of newly created files don't have a copyright header. As well as just being a good thing to do, it's necessary should Koha go into something like Debian. And while you're thinking about copyright headers, think about code documentation. Some of it has none at all. I'll let someone else figure out how to identify that though :) This is just looking in the Koha:: namespace, as that's mostly new stuff. If these files were created/edited by you, you should go paste a header in. $ for f in `ack -L 'Copyright'` ; do echo "$f:" ; git blame --porcelain $f | grep -E '^author ' | sort | uniq | sed -e 's/^author / /' ; done SearchEngine.pm: Jonathan Druart QueryParser/Driver/PQF/query_plan/node/atom.pm: Jared Camins-Esakov QueryParser/Driver/PQF/query_plan/facet.pm: Jared Camins-Esakov QueryParser/Driver/PQF/query_plan/node.pm: Jared Camins-Esakov QueryParser/Driver/PQF/query_plan/modifier.pm: Jared Camins-Esakov QueryParser/Driver/PQF/query_plan/filter.pm: Jared Camins-Esakov QueryParser/Driver/PQF/query_plan.pm: Jared Camins-Esakov QueryParser/Driver/PQF/Util.pm: Jared Camins-Esakov QueryParser/Driver/PQF.pm: Jared Camins-Esakov SearchEngine/ConfigRole.pm: Jonathan Druart SearchEngine/Index.pm: Jonathan Druart SearchEngine/Search.pm: Jonathan Druart SearchEngine/Zebra.pm: Jonathan Druart SearchEngine/QueryBuilder.pm: Jonathan Druart SearchEngine/Solr.pm: Jonathan Druart SearchEngine/SearchRole.pm: Jonathan Druart SearchEngine/IndexRole.pm: Jonathan Druart SearchEngine/FacetsBuilderRole.pm: Jonathan Druart SearchEngine/QueryBuilderRole.pm: Jonathan Druart SearchEngine/FacetsBuilder.pm: Jonathan Druart SearchEngine/Solr/Index.pm: Colin Campbell Jared Camins-Esakov Jonathan Druart SearchEngine/Solr/Search.pm: Jonathan Druart Mason James SearchEngine/Solr/QueryBuilder.pm: Jonathan Druart SearchEngine/Solr/FacetsBuilder.pm: Jonathan Druart SearchEngine/Solr/Config.pm: Jonathan Druart SearchEngine/Config.pm: Jonathan Druart SearchEngine/Zebra/Search.pm: Jonathan Druart SearchEngine/Zebra/QueryBuilder.pm: Jonathan Druart -- Robin Sheat Catalyst IT Ltd. ✆ +64 4 803 2204 GPG: 5FA7 4B49 1E4D CAA4 4C38 8505 77F5 B724 F871 3BDF

2 2

Zebra : left truncation and left+right truncation with ICU
by Mathieu Saby 08 Oct '13

08 Oct '13

Hello Since dec. 2012, the new version of Zebra (2.0.53) has fix the support of @attr 5=2, @attr 5=3 for ICU records. http://www.indexdata.com/zebra/doc/NEWS This could be a good news for people using ICU, for example French libraries. When Koha is installed, I don't know if a specific version of Zebra is installed with it, or if it is the last available version of Zebra. Could you tell me how it works? If it is not the last available version, it could be interesting to install 2.0.53 version, so we could support @attr 5=2, @attr 5=3. But maybe some changes must also be made to Koha's code for taking advantage of this bugfix? Regards, M. Saby Rennes 2 University -- 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

2 1