Evergreen ILS Website

IRC log for #evergreen, 2013-12-09

| Channels | #evergreen index | Today | | Search | Google Search | Plain-Text | summary | Join Webchat

All times shown according to the server's local time.

Time Nick Message
02:26 berick_ joined #evergreen
07:14 jboyer-isl joined #evergreen
07:42 rjackson-isl joined #evergreen
07:48 collum joined #evergreen
08:05 mrpeters joined #evergreen
08:22 _bott_1 joined #evergreen
08:36 kmlussier joined #evergreen
08:36 kbeswick joined #evergreen
08:40 csharp @quote random
08:40 pinesol_green csharp: Quote #66: "<csharp> EVERYBODY KEEP SAYIN' FUNNY STUFF!" (added by gmcharlt at 02:29 PM, August 13, 2013)
08:43 Shae joined #evergreen
08:43 misilot joined #evergreen
08:46 misilot left #evergreen
08:47 akilsdonk joined #evergreen
08:54 timf joined #evergreen
09:08 mmorgan joined #evergreen
09:13 Dyrcona joined #evergreen
09:29 Dyrcona joined #evergreen
09:32 jeff joined #evergreen
09:39 ericar joined #evergreen
09:54 pinesol_green [evergreen|Elliot Voris] Documentation typo in Authorities chapter subheading - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=b6833de>
10:00 yboston joined #evergreen
10:01 jasonb-iph joined #evergreen
10:02 BigRig joined #evergreen
10:04 phasefx2 joined #evergreen
10:05 tater joined #evergreen
10:05 senator joined #evergreen
10:07 ningalls joined #evergreen
10:07 eeevil joined #evergreen
10:07 gdunbar joined #evergreen
10:07 jcamins joined #evergreen
10:08 rangi joined #evergreen
10:08 rangi joined #evergreen
10:18 Dyrcona 3rd_party_vendors--
10:18 bshum Agreed.
10:18 Dyrcona sip2--
10:20 berick Dyrcona: what specifically do you dislike about the proposal?
10:20 jeff ?
10:20 * jeff looks for context
10:20 berick apart from sip is dumb
10:21 berick https://bugs.launchpad.net/evergreen/+bug/1259196
10:21 bshum jeff:  bug 1259196
10:21 pinesol_green Launchpad bug 1259196 in Evergreen "SIP support workstation option at login" (affected: 1, heat: 6) [Wishlist,New]
10:21 Dyrcona It would mean  a proliferation of sip2 accounts in the database and in oils_sip.xml.
10:21 berick ah, gotcha
10:21 Dyrcona If library X has 5 selfchecks, that means 5 sip2 accounts.
10:21 bshum That makes me queasy.
10:22 Dyrcona Like I said in the bug, I can't think of any other way to do what you propose.
10:22 berick right
10:22 Dyrcona As if 3M would implement an extension field for storing a workstation identifier.
10:22 berick even if we offer an extension, getting..
10:22 berick exactly
10:24 Dyrcona As long as the field is ignored if not present, i.e. doesn't throw an error, I'm OK with it.
10:26 Dyrcona I added those remarks to the bug, so its all in one place.
10:26 tsbere I wouldn't object to something like "workstation by what IP you connected from" in the config file, except for the fact that it would be useless for MVLC.
10:28 eeevil Dyrcona: there's a good reason to /require/ separate logins for each device, though ... password lockout :)
10:28 jeff we use one sip account per sip client.
10:29 jeff also, there is a SIP field that is designed for this purpose, but last i looked (last week) there was at least one challenge with using it that way in current SIPServer
10:30 jeff while we're at it, i'm still interested in the sip config file having the ILS credentials, but also having a hashed/salted password that the SIP client uses, which is distinct -- so that the sip client does not contain ILS credentials. :-)
10:30 jeff that might be unpopular, or popular. i dunno.
10:30 Dyrcona eeevil: It's not me that really has the problem with it. I think a number of my members would get mad at having multiple logins.
10:31 jeff i'm not sure how we'd have survived without one user per sip client.
10:31 * jeff looks at the bug
10:31 Dyrcona jeff: It depends on your needs, I guess.
10:32 Dyrcona Although, I'm not fond of the management overhead added by having multiple self check logins for 36 member libraries.
10:33 eeevil jeff: an optional client-side-only authen layer (triggered by the presence of an attr containing a 41 char string (sha1 hash)) seems reasonably simple, actually
10:33 * Dyrcona is not a fan of passwords, either. Can we all just use client certificates already?
10:34 jeff eeevil: i was thinking more along the lines of "if clientpassword attribute is present, check the incoming password from the SIP client against that (hashed + salted) value, and use the value of the password attribute to auth to the ILS"
10:35 eeevil jeff: right, exactly
10:35 jeff that way, no changes required at upgrade unless and until you want to take advantage of the new option.
10:36 jeff and you could use it for some users but not others, either due to policy/desire or due to staged rollout of the new credentials to clients.
10:37 Dyrcona Why hash and salt something that is sent in the clear anyway?
10:38 Dyrcona The '80s called. They want telnet and ftp back.
10:38 dbs tunnels, tunnels everywhere
10:39 jeff tunnelling sip over ssl or ssh is highly recommended by 100% of jeffs making this statement.
10:42 Dyrcona We tunnel over ssh. I am curious what you think you gain by hashing and salting passwords in oils_sip.xml.
10:43 Dyrcona If someone has access to the server and can read that file, and intends to do something malicious, you've got bigger problems.
10:43 jeff but to answer your question about "why hash+salt", "because the sip server doesn't need to cleartext sip client password -- just the cleartext ILS password"
10:43 jeff Dyrcona: is /etc/shadow world readable on your systems? are the passwords within hashed and salted?
10:44 jeff (and of course oils_sip.xml is not /etc/shadow, and /etc/shadow does not contain any cleartext credentials to auth to another system...") -- i didn't claim it was a perfect example. :-)
10:44 Dyrcona jeff: That's different. How many users on your Evergreen system? /etc/shadow is a generic solution to a generic problem. If you run Evergreen on a truly multi-user GNU/Liinux system, then your performance likely sucks.
10:46 jeff but the basic idea is there -- if someone unauthorized can read /etc/shadow, you have big problems. still not a bad idea to have the contents hashed and salted.
10:47 Dyrcona Right, but if an unauthorized person can read oils_sip.xml, they can read opensrf.xml and opensrf_core.xml and you've got bigger problems than them getting a client's sip credentials.
10:47 Dyrcona Better to secure your server.
10:47 Dyrcona Better to come up with an alternative to SIP that is encrypted.
10:49 jeff given some event that results in the disclosure of your SIP config file, having the client passwords hashed ahd salted can help (say, you might not need to change a dozen sip client passwords until your next maintenance window)
10:49 jeff but mostly, back to my original: "because the sip server doesn't need the cleartext sip client password"
10:50 Dyrcona I don't find either argument compelling enough, and I have slipped a few passwords by accident in the past and had to change them.
10:50 * csharp reads scrollback...
10:52 csharp we have many many SIP logins since we started suggesting/sorta-requiring one login per device
10:52 csharp it is a lot of overhead
10:52 * csharp is actually considering setting up some sort of conf.d type approach with a dir per library
10:53 Dyrcona csharp++ # conf.d would actually be useful to help manage a lot of credentials.
10:54 jeff with support for a new client SIP password distinct from the ILS password, the ILS password would only be used by SIPServer and the ILS -- which opens the possibility of having an automated establishment of those credentials, or even a script to rotate them. :-)
10:56 gsams joined #evergreen
10:56 dbs SIP clients should use two-factor authentication. "Go get your phone, client!"
10:56 Dyrcona Oh. Right. You're expecting blue-haired grannies to manage passwords, now.....
10:56 Dyrcona dbs++
10:56 jeff Dyrcona: who is?
10:56 Dyrcona You are.
10:56 jeff Dyrcona: sorry, i must have been unclear.
10:57 Dyrcona Two factor authentication: Based on something you can forget and something you can lose.
10:58 * csharp agrees in theory with Dyrcona's keys approach
10:58 Dyrcona My point is if you're trying to improve the security of SIP, then encrypt the connections everywhere by default.
10:58 Dyrcona Rather than salt and hash client credentials, why not just remove them?
10:58 jeff Dyrcona: i'm suggesting that we recommend one optional thing (one user per SIP client) and support one optional feature (the ability for the sip client password to be distinct from the ILS password). not sure where this is expecting anyone that isn't currently in the business of managing passwords to manage them new.
10:59 Dyrcona I'm not arguing with the one user per SIP client.
10:59 jeff cool.
10:59 akilsdonk_ joined #evergreen
10:59 jeff not sure where i'm being unclear.
10:59 Dyrcona I don't use that configuration, but I see why you'd want it.
10:59 jeff perhaps code and docs in a new wishlist ticket or two would be the best way to express myself.
11:00 Dyrcona I get what you're saying now, but I still don't see what salt+hash really gains you in an Evergreen environment.
11:01 Dyrcona You've separated sip credentials from database login. That gets you something. Someone can't use a sip account to login otherwise.
11:01 * csharp sees a security/CYA advantage to salt+hash, if not a technical one
11:01 Dyrcona Sure, but see my remark above about exposure of the /openils/conf directory.
11:02 jeff i see it as practicing good security hygiene.
11:02 Dyrcona I see it as washing one armpit and not washing the other.
11:02 Dyrcona You don't do security piecemeal. That's why most security actually sucks.
11:03 jeff i am not advocating a piecemeal approach.
11:03 jeff i am advocating that the approach be able to interoperate with existing SIP clients.
11:04 Dyrcona The existing SIP clients and the SIP protocol are the problem.
11:04 Dyrcona Not how your store credentials on a server.
11:06 csharp I'm interested in SSL/SSH approaches to SIP clients,  but my stomach starts to hurt when I think about implementation in PINES
11:06 jeff Dyrcona, csharp: who performs the SIP client configuration in the field in your respective environments?
11:06 csharp jeff: each library handles that individual
11:06 csharp ly
11:06 jeff csharp, Dyrcona: how (if at all) is SIP traffic secured on the wire in your environments?
11:07 Dyrcona ditto. we give them a CD or a download so they can set up a ssh tunnel with putty.
11:07 csharp we're currently using telnet
11:07 csharp so *none*
11:07 jeff non-public network, ssh or ssl from a gateway host, ssh or ssl from the SIP client itself?
11:08 Dyrcona our outside vendors come in clear text over the wire, but the unencrypted sip port (ie. not using the tunnel) is blocked by default in our firewall with specific IPs allowed access.
11:08 jeff Dyrcona: you give them what they need to create an ssh tunnel -- do they run this on the sip client, or on a staff workstation, or something else?
11:09 Dyrcona jeff: Like I said we give them what they need. We'll even set it up. We have them run it on another workstation or server in the library depending on their setup.
11:09 jeff feel free to answer in msg or not at all, but what external SIP clients (SIP clients not running on a device located at one of your libraries) do you have?
11:09 Dyrcona jeff: I think you'd better spend your time developing a replacement for SIP and NCIP while you're at it.
11:11 Dyrcona jeff: The usual suspects. :)
11:25 jeff Dyrcona++
11:25 jeff csharp++
11:39 bshum tsbere++ # fix for bug 1259231
11:39 pinesol_green Launchpad bug 1259231 in Evergreen "No email address message stuck in staff client" (affected: 1, heat: 6) [Medium,Confirmed] https://launchpad.net/bugs/1259231
11:44 mmorgan I'm looking for a way to send email notification to a group of patrons (read students) that have anything checked out. Anyone doing this?
11:44 pinesol_green [evergreen|Thomas Berezansky] Always show Email Address label to staff - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=5668f8d>
11:44 bshum mmorgan: I've often wished for an "on-demand" email notifier for situations like that.
11:45 bshum As is, I think some folks are managing by using reports and mail merge or such
11:45 jeff mmorgan: we use the same service we use for our email newsletters, fed by an on-demand report -- it's infrequent enough that it's very manual at present.
11:45 mmorgan I'll happily open a launchpad bug, but didn't want to if I'm missing something obvious.
11:46 jeff i am working currently to sync patron email addresses automatically, including some basic information about account type / residency qualifications, but not currently anything as frequently-changing as "has something checked out right now"
11:46 jeff mmorgan: what's your use case?
11:47 mmorgan Our academics want to send statements at the end of each term to their students who still have things checked out before they leave for the semester.
11:47 bshum Ours is something like an end of semester notification.  The year is ending soon, please return your books.
11:47 bshum Same as mmorgan's scenario apparently :)
11:47 tsbere mmorgan: Beyond the having things checked out aspect I came up with ways to send emails via Evergreen....but I am not sure I want to document them even in IRC.
11:48 mmorgan Once they leave  after finals chances that the outstanding items go down dramatically.
11:48 mmorgan insert " come back" in there somewhere :)
11:51 mmorgan was looking for some way to do it with a trigger, but don't see one.
11:54 gdunbar joined #evergreen
11:56 jcamins joined #evergreen
11:57 kmlussier I haven't gotten around to scheduling a dev meeting yet, but I was wondering if there is any inclination to skip a December dev meeting. Given that it's a busy time of year and all that good stuff.
11:58 fparks joined #evergreen
11:58 sseng joined #evergreen
11:58 ktomita joined #evergreen
11:58 smyers_ joined #evergreen
12:01 bshum I would be +1 to waiting for January for the next dev meeting.
12:01 bshum I was also going to suggest that since we held off on the point releases last month, that maybe we can put them to January for those too.
12:02 bshum To give us some more time to find bugs, fix them, and merge them
12:02 bshum (or something like that)
12:05 akilsdonk joined #evergreen
12:10 akilsdonk joined #evergreen
12:12 sseng joined #evergreen
12:22 * Dyrcona agrees with bshum.
12:23 bshum Conversely, I see this as an opportunity to hold our first bug day.  December 25 work for everyone?  :P
12:26 jeff :P
12:28 cs5120288_ joined #evergreen
12:32 Dyrcona jeff: tsbere is having a phone conversation right now that would be more difficult to resolve if sip client passwords were salted and hashed in oils_sip.xml.
12:32 jeff oh? howso?
12:33 Dyrcona One of our sites has entered an incorrect password in their client. He can tell them what the password should be by looking at oils_sip.xml.
12:33 tsbere In this case it is more of a "if we properly sanitized the LOGS to remove passwords" >_>
12:34 Dyrcona We could (and actually do) store a lit of passwords elsewhere, but that also defeats the purpose of hashing them.
12:35 Dyrcona s/lit/list/
12:35 jeff i appreciate the example. :-)
12:36 Dyrcona From his last comment, it sounds like he only used the logs. I guess they were setting up a new client and he could see prior successful logins.
12:37 Dyrcona bshum: I've got plan on the 25th. What about the 1st of January?
12:38 bshum Dyrcona: New year's resolution, fix all the bugs
12:38 bshum I like it.
12:38 tsbere I used our non-config file list of passwords + logs that showed the wrong password. <_<
12:38 Dyrcona bshum: Good luck with that. :)
12:39 Dyrcona tsbere: That's good. Undermine your boss' argument in public. :p
12:42 jeff SIPServer needs a service-impacting restart to re-read its config at present, right?
12:43 Dyrcona jeff: yes, it does.
12:43 jeff that would be another something I'd like to see change. teach it to re-read at least credentials on HUP or similar.
12:44 Dyrcona jeff: that would be good, like an apache reload.
12:45 Dyrcona jeff: You also reminded me that I'd like to make the --localhost argument to osrf_control unnecessary. I think I'll work on that this this afternoon.
12:46 jeff is your idea to default to localhost if localhost is present in the config and the hostname is not/
12:46 jeff ?
12:46 Dyrcona basically.
12:49 jeff with potentially 255 characters in a terminal password field, why not have sip passwords like: eatery gruntling oilseed puzzleheaded kraken? :-)
12:49 jeff another option could be 254 random characters copied and pasted.
12:50 jeff of course, different software will have different max limits. i'm sure few of them have encountered such passwords before.
12:50 Dyrcona Passwords are great for letting people in, but lousy at keep people out.
12:51 bshum @dunno add No, you're a puzzleheaded kraken!
12:51 pinesol_green bshum: The operation succeeded.  Dunno #25 added.
12:51 jcamins jeff: oh no! That was the password I was using for my SIP terminals! Now I'm going to have to change all the passwords!
12:52 Dyrcona They also don't authenticate a damned thing.
12:52 jeff jcamins: oh no! "That was the password I was using for my SIP terminals! Now I'm going to have to change all the passwords!" was the passphrase to my ssh key!
12:56 Dyrcona There's only one password that everyone needs: swordfish. Even Harpo Marx knows that one!
12:57 jeff Dyrcona: i don't think that we're going to be able to effect a significant change in the current status quo that most/all SIP clients treat auth as either "none required" or "store this username and password either in the clear or in an otherwise reversible fashion". i'm willing to make some improvements within those constraints.
12:57 jeff Dyrcona: now if you're interested in mocking up some staff interfaces that use certificates or smartcards in the browser...
13:03 Dyrcona Well, I just got my replacement keyboard from System76, so I think I'll install it.
13:03 Dyrcona BBL!
13:04 tsbere jeff: What we need to do is get rid of the SIP clients. Because SIP sucks. ;)
13:04 * tsbere goes to grab his lunch now
13:07 smyers__ joined #evergreen
13:10 csharp SIP_PASSWORD=`shuf -n4 /usr/share/dict/words | tr -d '\n'`
13:25 Dyrcona joined #evergreen
13:26 Dyrcona Nice. I like my "new" keyboard.
13:35 jeff good!
13:36 Dyrcona I wonder if Clevo will use this keyboard on their other models or if it is exclusive to System76.
13:37 Dyrcona Anyway, back to Evergreen.
13:58 smyers__ can someone point me to the documentation of online payment setup?
14:00 * bshum idly wonders if KCLS ever documented that
14:00 bshum Since they were the ones who helped have that develop
14:00 smyers__ I can tell you they didn't
14:02 kmlussier smyers__: There may be information on that in the archives for the general list.
14:02 jeff smyers__: did you have any specific questions?
14:03 csharp smyers__: Lisa Hill was the one who gave me the overview a couple of years back, if that helps
14:04 smyers__ jeff: yes as soon as the call hits  Business::OnlinePayment it dies
14:05 smyers__ jeff: I think it has something to do with the values in my $argshash->{"processor"} but I am failing at tracing that back to where that is setup
14:06 csharp ah - well that's beyond what Lisa and I discussed :-)
14:07 smyers__ csharp: thanks anyway
14:08 gdunbar smyers__: If you're using paypal or authorize.net you can do just about everything in the staff client... unless I'm misunderstanding
14:08 gdunbar of course you have to have an active account with one of them to test, too
14:19 ktomita_ joined #evergreen
14:25 stevenyvr2 joined #evergreen
14:27 smyers__ bshum: can I ask which versin of of Busniess OnlinePayment you have?
14:27 smyers__ perl -MBusiness::OnlinePayment -e 'print"$Business::OnlinePayment::VERSION\n"'
14:30 csharp smyers__: current version on Ubuntu 12.04 is 3.02
14:30 smyers__ thanks csharp same version here
14:43 smyers__ just to get the fixed logged in case any one else hits something simular Business::OnlinePayment uses backends from Business::OnlinePayment::PayPal in stock evergreen but evergreen can support more like PayflowPro which needs  Business::OnlinePayment::PayflowPro
14:46 sseng joined #evergreen
14:55 Dyrcona Nothing is ever as simple as it should be.
15:00 hbrennan joined #evergreen
15:14 mmorgan If a hold policy says a particular circ modifier not holdable, is there any way to override this and get an item with that circ modifier to capture a hold?
15:23 tsbere mmorgan: Depends, are you talking from a hold policy POV, or a one-off deal?
15:23 mmorgan tsbere: One-off deal. There are always exceptions to any rule...
15:24 tsbere mmorgan: For one-off "I want to place a hold on this regardless of rules" I would look into the "Force" hold functionality
15:25 tsbere Take note that "regardless of rules" in this case means all rules. The holdable flags on the copy and location will be ignored and hold policies won't even be checked.
15:25 akilsdonk joined #evergreen
15:27 mrpeters left #evergreen
15:28 mmorgan So how does one force a hold?
15:31 ktomita joined #evergreen
15:31 tsbere mmorgan: It is a hold type, a copy level variant. You don't place them from the OPAC, but you can from item status.
15:35 mmorgan "Request Item" must be it. Thought that was a bookings function so overlooked it. Thanks tsbere, I'll look into that.
15:36 tsbere mmorgan: It does require permission at the item's circ lib to make the request, just so you know.
15:36 mmorgan okay, thanks!
15:52 mrpeters joined #evergreen
15:57 sseng for the self checkout interface, is it possible to pass in via the url the username and password of the staff login (so that, say, a staff wouldn't need to login to authorize the SCKO interface?)
16:00 eeevil sseng: not without development. and, of course, you can imagine our reluctance to expose a staff-level user/pw combo through something that is relatively easy to retrieve, such as a bookmarked URL
16:00 sseng eeevil: got it, thanks!
16:20 akilsdonk joined #evergreen
16:53 RBecker joined #evergreen
17:09 mmorgan left #evergreen
17:38 Bmagic joined #evergreen
17:39 Bmagic I am new to opensrf for EG 2.4. Should I use open-ils.circ.money.payment to make a payment with my perl script? or is there a better method?
17:55 dac joined #evergreen
18:03 kbeswick joined #evergreen
19:04 rsinger_ joined #evergreen
19:05 rsinger_ left #evergreen
19:13 stevenyvr2 left #evergreen
19:38 fparks_ joined #evergreen
19:44 eby_ joined #evergreen
19:52 kmlussier joined #evergreen
21:08 Callender_ joined #evergreen
21:16 kmlussier joined #evergreen
21:17 edoceo joined #evergreen
21:32 jeff joined #evergreen
21:34 sseng joined #evergreen
22:02 artunit joined #evergreen
23:25 jeff_ joined #evergreen
23:36 jeff__ joined #evergreen
23:51 jeff__ joined #evergreen

| Channels | #evergreen index | Today | | Search | Google Search | Plain-Text | summary | Join Webchat