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

Possible OPAC security pb
by Fridolyn SOMERS 15 Jul '13

15 Jul '13

Hie, I've just opened http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10590. I've set it to critical because I think it is a security problem existing at OPAC : In opac-topissues the parameter limit is directly added at the end of the SQL query, without testing its value. A user can edit this parameter to add SQL code to query : for example : limit=10;DROP+TABLE+borrowers;. Please have a look and test. Best regards, -- Fridolyn SOMERS Biblibre - Pôle support fridolyn.somers(a)biblibre.com

3 3

July 15th: it's String Freeze
by Tomas Cohen Arazi 15 Jul '13

15 Jul '13

Hi everyone, We are a week out from new releases of the 3.8.x, 3.10.x and 3.12.x stable branches. If you know of some QA-ed patch that deserves to be applied soon to the stable branches just let us know about it in the next 12 hours. Tomorrow morning (UTC-3 time) we are extracting the new strings to let translators have fun. Thanks The Release Maintenance Team (chall, bgkriegel and tcohen)

1 0

Call for news for the July newsletter
by Daniel Grobani 12 Jul '13

12 Jul '13

Dear Koha kommunitarians, I'm harvesting news for this month's newsletter. Please send me by the 20th anything you think your fellow community members might like to know about. "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

FW: QA: Language material in install/mysql/data
by Marcel de Rooy 11 Jul '13

11 Jul '13

Just an update on this development: Bug 10509 now contains the i18n concept (with thanks to Galen). This patch adds some code to Installer.pm to support use of the sql i18n function while installing various languages. Bug 10520 changes the English folder (so no global folder for now). It inserts i18n calls in all .sql files for translatable columns. (i18n will do nothing for English itself.) The next step is changing the other languages: These .sql files will (mostly) be converted to a i18n definition that just contains the translation of string expressions. Running a language install now comes down to defining the right translation definition and then running the corresponding English script. When we reach this goal, we will have removed a lot of redundancy from the installer/data/mysql folder. Adding a notice or marc tag will be a lot easier (just insert in English, with automatic propagation to other languages). Generating translations via PO will be within reach. Both reports are ready for sign-off. Before starting work on the other language folders, I hope to see some progress on 10509 / 10520. The test plan for 10509 includes some tests that may illustrate the concept more clearly. Thanks!

1 0

UNIMARC_sync_date_created_with_marc_biblio.pl
by Samuel Desseaux 10 Jul '13

10 Jul '13

Hi, I've noticed a problem with my biblio records. Biblio.datecreated and biblio.timestamp are well fullfilled in the database but are not displayed in the biblio record. I've executed this but with no results (in koha <https://github.com/colinsc/koha>/ misc <https://github.com/colinsc/koha/tree/master/misc>/ maintenance <https://github.com/colinsc/koha/tree/master/misc/maintenance>/) perl *UNIMARC_sync_date_created_with_marc_biblio.pl. Has someone an idea? Best regards, Samuel *

2 1

Re: [Koha-devel] RFC: Plugins QA
by Paul 10 Jul '13

10 Jul '13

At 07:17 AM 6/1/2013 -0700, BWS Johnson wrote: >Salvete! > >Tarballs, packages, gits (including vendors), stables, latest, bugs and >patches, wikis (various), tools, reports, live-DVDs, mailing lists, chat, >maybe more, and now plug-ins? Could we please look at what the >"open source" world is doing? Apache, SendMail, Perl, PostFix, >FireFox, Debian, Ubuntu, OpenOffice, LibreOffice ... are fairly stable >with an established security update capability. Even Java and MySQL are >simplifying. > > > I'm all for giving our developers the flexibility to deliver their > code in whatever form they have time to wrap it in. I might _like_ them > to do things my way, but I'm not paying them, and I never have. Agreed -- 100%. My concern is with the "final product", not the means of getting there. > What do you consider instable or insecure in particular? This thread started questioning the need for QA for plugins, *potentially* insecure. The instability issue is part perception/communication, part superb enthusiasm on the community/development side. But the fact remains that on 14 September 2012, we went live with Koha 3.8.4 which was the "cat's whiskers" just eight months ago. 3.8 is now "old stable", 3.10 is "stable" and 3.12 "development" is advertized (Wiki) equally prominently. And the Wiki continues: "If you're unsure what you want, go for the stable version. If you want to be a bit more conservative, go for the most recent old-stables release. Note that both of these are still very much a work in progress: they won't work perfectly just yet." There is, for a newcomer reading the Wiki, no "working perfectly" LTS (long term stable) release. My *opinion* is that we need (cf Ubuntu) a five year cycle -- 2 years "stable+security", 2 years continuing support, 1 year buffer zone -- this could be seen as maturity in the open-source world. > Many of those projects are quite large, so in my light, afford their > respective projects the ability to do things that we as a smaller project > might not be able to manage. I truly believe that Koha is no longer a "smaller project", but you make a valid point. > Many thanks to Robin and anyone else that helped with the packages. I > had whinged for ages that I'd love to just have an apt-get command. Agreed 100% -- although I have never used the packages. > >I had a "rather important" librarian from Quebec drop in, out >of the blue, yesterday to talk about Koha. Her group (37 libraries) had >previously been burned by a trial commercial implementation of Koha (no >need to quote names), so they're using Opals, but "liked the >idea" of Koha. First question: "stability?" > I am stymied by this. Completely, utterly flabbergasted. First, > whatever trash LibLime were selling wasn't Koha. I was somewhat careful not to quote names ;=} -- you could be right in your assumption, but at my age "my memory fails me ..." >Second, OPALS? As in >http://www.mediaflex.net/showcase.jsp?record_id=52 Yup. "OPALS, an open source ILS for school libraries and districts developed and supported by Media Flex earned top rankings in Company Satisfaction, Product Support, and Company Loyalty." See <http://www.librarytechnology.org/perceptions2012.pl> > One of the questions I posed to my students was "Is OPALS truly open > source if you have to beg for the code and a demo?" In terms of feature > comparison and breadth of adoption, it's not even close. It's well known > I've a soft spot in the granite thing that's meant to be my heart when it > comes to Koha, but I freely admit when I think we get beat. That is most > certainly not the case with Koha, and I wish them the best of luck > getting a consortium up and running in a multilingual capacity with that heap. I respect your opinion (but see Marshall Breeding's survey above.) If I knew more about Opals, I might well agree. > >I know that a number of you will ... whatever ... Paul's a pain in the >neck, doesn't understand, does his own thing, but the bottom line is that ><http://opac.navalmarinearchive.com/> >is fully functional and is intrinsically Koha. It's (reasonably) secure >(without https) and meets the needs of our users and librarians. It runs >itself with minimal ( < 1 hour/week statistically ) intervention by IT >personnel. > > So what's the problem? I'm truly sorry, but I just don't understand > why you're ranting here. Getting Koha recognized as a major player. I'm convinced. I'm keen on persuading other institutions. I'll do my utmost. I just see the lack of a solid LTS release as a difficulty. This thread subject concerns "plugins QA", and my first para mentions [other open-source as] "fairly stable with an established security update capability"; looking at e.g. Firefox plugins, Mozilla says (FAQs) "Unless clearly marked otherwise, add-ons available from this gallery have been checked and approved by Mozilla's team of editors and are safe to install. We recommend that you only install approved add-ons." Mea culpa if I 'pirated' this thread to *stability* rather than *QA*, but they are closely intertwined. > >There are very few institutions that have "happiness" in the >form of unlimited budgets and unlimited IT departments. I'm personally >intrigued by the creativity of the Koha community, so try and follow >what's happening -- which is magnificent -- but doubt that your average >library has the same passion. > > I think most of the discussions we have are important, and I really > love having the longer term steering and strategic types of conversations. I hope (and genuinely believe) that we're not the only two participants here interested in "steering and strategic types of conversations" and also hope that my thoughts on stability (QA, maturity, reputation) might strike chords with others. It's not criticism, perhaps more my dream of the next "small step" for library systems. In my 50+ years of code development, I can honestly say that end-user credibility is very closely related to stability, and that within "stable" the differentiation between security and enhancement must be crystal clear (and separately optional from an upgrade pov.) "It works as promised" is a huge compliment. The old saying "if it doesn't work, use a bigger hammer; if that fails, rtfm" is dubious management. Thanks for your thoughts and best regards, Paul >It's been a long time since I had to interact with proprietary vendors, >and I don't relish the thought of ever being charged with that again. I >think that a lot of the development done at least gives a nod to small >libraries. More often than no, folks bend over backwards for small >libraries. I get quite prickly if I sense that things *aren't* moving that >way. This is a big tent system, there's plenty of room for everyone's >individual take. :) > > >Cheers, >Brooke >_______________________________________________ >Koha-devel mailing list >Koha-devel(a)lists.koha-community.org >http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel >website : http://www.koha-community.org/ >git : http://git.koha-community.org/ >bugs : http://bugs.koha-community.org/ --- Maritime heritage and history, preservation and conservation, research and education through the written word and the arts. <http://NavalMarineArchive.com> and <http://UltraMarine.ca>

8 12

libgd-gd2-perl and ibgd2-noxpm-dev in wheezy
by Zeno Tajoli 08 Jul '13

08 Jul '13

Hi to all, I'm tring a git install of 3.12.x on Debian wheezy amd64. I find that the libraries libgd-gd2-perl and libgd2-noxpm-dev don't work well together. If I want to install libgd2-noxpm-dev, I need to remove libgd-gd2-perl. In fact I don't know if we want GD2 with or without XPM (X pixmap) and fontconfig support. Bye Zeno Tajoli

3 2

Fwd: Koha Docker image
by John Fink 07 Jul '13

07 Jul '13

Hi Koha-devel folks, Sent this to the Koha general list, but was advised that it's probably more of interested to devel. Also, I omitted the index page -- has instructions amongst other stuff. https://index.docker.io/u/jbfink/koha/ jf ---------- Forwarded message ---------- From: John Fink <john.fink(a)gmail.com> Date: Fri, Jul 5, 2013 at 4:29 PM Subject: Koha Docker image To: koha(a)lists.katipo.co.nz Hey folks, Spent some time today whipping up a Docker (http://docker.io) image for Koha for a talk I'm going to be giving about Docker later this year. If anybody on-list would like to see how it stands up, you can pull it from Docker's index with docker pull jbfink/koha . Note that I am by no means a Koha expert and this is my first time messing with Koha since... oh... 2002 or so, so there may be things with my Koha install which are broken or boneheaded in some way. jf

2 2

Test suite in t/db_dependent/lib/KohaTest
by Marcel de Rooy 04 Jul '13

04 Jul '13

Hi, My question about the files in the mentioned folder is: Is anyone using these test units at all? Could we delete them? Note that Jenkins appears not to run t/db_dependent/database_dependent.pl but only the *.t files. The script database_dependent.pl only refers to lib/KohaTest.pm and all unit tests in lib/KohaTest. commit 80568463eac45ede97268c02ee7d59028cb3ff9b introduced t/database_dependent.pl (2008) commit eff21765f9784e09905042dd7080cbef099306d9 moved it to t/db_dependent/ Note also that it needs two additional cpan modules: Test::Class and Test::Class::Load Currently, we are often updating files in this directory. We are finding them with grep etc. and we update them. But if no one is using them, we could better remove them and have less maintenance issues. Before opening a report with a "large delete" patch, just asking around here. Please respond if you know that they are in use! Thanks, Marcel

4 4

Bugzilla: Reply on comment
by Marcel de Rooy 03 Jul '13

03 Jul '13

Hi all, I recently (last update?) and regularly have trouble with Reply on Bugzilla. It does sometimes no longer paste the comment in the text box. Anyone else having this too? Or found a way to resolve it? Thanks, Marcel

3 2