2011-08-11T00:43:35 *** dbwells has joined #evergreen 2011-08-11T00:50:50 *** dbwells has quit IRC 2011-08-11T01:07:16 *** pmplett has quit IRC 2011-08-11T01:58:35 *** dbwells has joined #evergreen 2011-08-11T02:29:44 *** dbwells has quit IRC 2011-08-11T03:29:43 *** charltgm_ has quit IRC 2011-08-11T03:38:40 *** dbwells has joined #evergreen 2011-08-11T03:49:40 *** dbwells has quit IRC 2011-08-11T04:58:21 *** dbwells has joined #evergreen 2011-08-11T05:55:08 *** dbwells has quit IRC 2011-08-11T07:03:56 *** dbwells has joined #evergreen 2011-08-11T07:13:01 *** dbwells has quit IRC 2011-08-11T07:14:30 @later tell phasefx Force-pushed a minor change to new_print_method. Forgot that openDialog has different default assumptions than open, specifically in regards to "can be minimized" for this case. Changed it to include "minimizable" in the feature set. 2011-08-11T07:14:30 tsbere: The operation succeeded. 2011-08-11T07:28:59 *** collum has joined #evergreen 2011-08-11T08:20:49 *** dbwells has joined #evergreen 2011-08-11T08:35:49 *** dbwells has quit IRC 2011-08-11T08:42:29 *** Dyrcona has joined #evergreen 2011-08-11T08:58:48 *** tspindler has joined #evergreen 2011-08-11T09:15:15 *** kmlussier has joined #evergreen 2011-08-11T09:16:54 * phasefx wonders when List Actions and Print stopped working in Check In on master 2011-08-11T09:17:08 List Actions and Print? 2011-08-11T09:17:38 menu and button at the bottom of the interface.. seems unrelated to your changes, but I was trying to test printing in different interfaces 2011-08-11T09:18:23 hmm 2011-08-11T09:21:12 the widgets work, so a little farther down the stack. g.checkin.list.dump_csv_to_printer() not working 2011-08-11T09:25:20 wrap_in_full_retrieve not firing 2011-08-11T09:36:51 *** jenny has joined #evergreen 2011-08-11T09:36:56 *** dbs has joined #evergreen 2011-08-11T09:37:53 Any suggestions for this error related to A/T it seems? http://paste.lisp.org/display/123963 2011-08-11T09:38:34 It's only happening sporadically 2011-08-11T09:38:44 So I'm not sure what it means yet. 2011-08-11T09:39:52 You've run into LP816627 and a permissions check is failing and CStoreEditor just assumes it always succeeds. 2011-08-11T09:40:21 * Dyrcona has seen that quite a bit when hammering on his development machine. 2011-08-11T09:41:44 Aha 2011-08-11T09:42:50 Funny thing is, it doesn't fail because you don't have the permission, it fails for some other, unexpected reason and returns an undefined value. 2011-08-11T09:43:48 *** dbwells has joined #evergreen 2011-08-11T09:44:54 I could be off a bit. I checked CStoreEditor in master and line 507 is near a permission check that sometimes fails. It could be one of the other lookups failing in the same way. 2011-08-11T09:45:20 If you want to try a master install, my lp816627 branch has fixes for CStoreEditor and AppUtils so far. 2011-08-11T09:47:15 I'll try it sometime. Have to setup new testing environments, maybe one of them should be a master install of Evergreen. 2011-08-11T09:49:35 Yes, everyone should have at least one master install of Evergreen. :) 2011-08-11T09:49:47 * Dyrcona has 4 at his disposal. 2011-08-11T10:08:09 * Dyrcona just looked at CStoreEditor in rel_2_0. 2011-08-11T10:12:56 *** dbwells has quit IRC 2011-08-11T10:21:28 * csharp is slowly building a master install of Evergreen in a VM 2011-08-11T10:21:43 alongside 1.6, 2.0, and 2.1 ;-) 2011-08-11T10:22:53 * tsbere keeps a 2.1/master enabled VM, but doesn't bother with pre-perl move stuff ;) 2011-08-11T10:24:32 assuming all goes well with the GSoC project & we have an available server, we should be able to set up automatic nightly builds of master / 2.1 / whatever VMs 2011-08-11T10:30:19 *** fortin has joined #evergreen 2011-08-11T10:33:00 *** DeanB has joined #evergreen 2011-08-11T10:33:36 *** DeanB has left #evergreen 2011-08-11T10:39:04 *** akilsdonk has joined #evergreen 2011-08-11T10:57:46 *** mrpeters-isl has quit IRC 2011-08-11T11:10:55 *** mrpeters-isl has joined #evergreen 2011-08-11T11:13:00 *** mrpeters-isl has quit IRC 2011-08-11T11:13:08 *** mrpeters-isl has joined #evergreen 2011-08-11T11:22:04 *** dbwells has joined #evergreen 2011-08-11T11:32:27 guys, looking at "really_delete_user" in Actor.pm -- trying to determine if the home_ou check is on the user you're deleting or if it's the user performing the delete? 2011-08-11T11:32:54 "really_delete_user" sounds scary. 2011-08-11T11:33:01 basically, i want to make sure there is a check in place to make sure the deletor (sp?) home_ou is equal to the home_ou of the patron being deleted 2011-08-11T11:33:24 bshum: it's Delete User from 2.0 staff client 2011-08-11T11:33:27 under "Other" 2011-08-11T11:33:31 Also scary. 2011-08-11T11:33:49 yep, that's why we want to make sure a person we give this permission to can only delete users at their library branch 2011-08-11T11:35:36 but if i'm reading the code correctly, it uses the "has_perm" function on the DELETE_USER permission @ home_ou of the patron being deleted 2011-08-11T11:36:10 which i think should prevent a staff member with a home_ou library "1" from deleting a patron with home_ou "2" 2011-08-11T11:39:58 mrpeters-isl: it should be using the patron home_ou as the "context org", and if the working locations for the staff + the permission and permission depth intersect that context org, then the action is allowed 2011-08-11T11:44:35 mrpeters-isl: AKA, "if you have permission to delete people at the patron's home ou, you can, even if that isn't where you are sitting right now" 2011-08-11T11:47:13 ok, so the key would just be to give everyone that permission at a depth that restricts them to their local system 2011-08-11T11:47:47 to their working locations 2011-08-11T11:48:10 yeah, work_ou = home_ou for us 2011-08-11T12:05:34 *** dbwells has quit IRC 2011-08-11T12:40:17 *** tspindler has quit IRC 2011-08-11T13:12:54 *** dbwells has joined #evergreen 2011-08-11T13:14:37 *** natschil has joined #evergreen 2011-08-11T13:17:55 *** fortin_ has joined #evergreen 2011-08-11T13:20:04 *** dbwells has quit IRC 2011-08-11T13:27:16 *** youdonotexist has joined #evergreen 2011-08-11T13:27:26 *** fortin has quit IRC 2011-08-11T13:27:29 *** natschil has quit IRC 2011-08-11T13:27:29 *** kmlussier has quit IRC 2011-08-11T13:27:40 *** kmlussier has joined #evergreen 2011-08-11T13:32:11 dbs: you running fedora 15? 2011-08-11T13:32:25 csharp: aye 2011-08-11T13:32:45 do you have to reinstall the virtualbox-ose kernel modules after each kernel upgrade? 2011-08-11T13:33:20 I've seen this happen twice - once on my laptop, once on my desktop 2011-08-11T13:33:40 csharp: That used to happen on my Ubuntu laptop too. Ended up having to change some symbolic links or something... 2011-08-11T13:34:11 I never had it happen with Ubuntu (except when I built from source one time) 2011-08-11T13:34:23 csharp: yep, I always do 2011-08-11T13:34:32 mind you, I'm still building vbox from source 2011-08-11T13:34:36 dbs: okay - it's not just me then ;-) 2011-08-11T13:34:38 ah - okay 2011-08-11T13:34:49 * csharp uses the rpmfusion package 2011-08-11T13:35:02 dkms is supposed to be savvy about kernel modules, but the fusion package may not be 2011-08-11T13:39:08 * csharp goes off to read more about akmods 2011-08-11T13:42:06 *** jenny has quit IRC 2011-08-11T13:51:25 *** jenny has joined #evergreen 2011-08-11T13:54:02 * csharp did not have dkms installed :-/ 2011-08-11T13:56:01 *** Kuys has joined #evergreen 2011-08-11T14:05:40 * tsbere just sent an email off to the practically dead security list 2011-08-11T14:06:15 tsbere++ # now I have something look at there other than spam 2011-08-11T14:06:59 gmcharlt: I am more concerned with the security implications of what I emailed 2011-08-11T14:07:00 <_< 2011-08-11T14:11:24 tsbere++ 2011-08-11T14:17:00 * Dyrcona still hasn't seen the email, but knows what it speaks about. 2011-08-11T14:20:06 tsbere: that is awesome 2011-08-11T14:21:59 I see there being several things to be done to properly "fix" that. Will elaborate more in a reply to the original email. Wanted to get the base problem out first. 2011-08-11T14:23:49 I actually don't think it's that dire, since anyone with local access to a machine can do any infinite number of things to breach security, especially one already authenticated. This is just easier than your typical keylogger. Am I off-base? 2011-08-11T14:24:21 * phasefx can discuss on list 2011-08-11T14:28:20 *** dbwells has joined #evergreen 2011-08-11T14:30:15 bshum: I've approved your subscription to open-ils-general 2011-08-11T14:30:23 er, open-ils-security, that is 2011-08-11T14:30:43 gmcharlt: Oh, thanks, I was curious to see how that went. 2011-08-11T14:33:10 *** dbwells has quit IRC 2011-08-11T14:34:31 *** fortin_ has quit IRC 2011-08-11T14:35:40 I thought open-ils-security subscription policy was core devs + chief bug wrangler? 2011-08-11T14:35:51 dbs: I was on it long before I was a core dev 2011-08-11T14:36:03 It started as "can you see security bugs on launchpad" 2011-08-11T14:36:04 tsbere: because you had posts about security problems, IIRC 2011-08-11T14:36:35 as well as suggestions for fixing some of them 2011-08-11T14:37:52 If it's largely about curiosity, then why have a closed list at all? 2011-08-11T14:39:34 dbs: IIRC, archives are meant to be made open after six months or so anyway 2011-08-11T14:39:49 really? I don't recall that at all 2011-08-11T14:39:59 i thought it was a year, but i do recall that 2011-08-11T14:40:03 general idea 2011-08-11T14:41:15 i beleive all of the major players in the community should be able to see security implications that could potentially impact their instances 2011-08-11T14:41:19 If that's the policy, I'd be happy to rescind my enrollment (since I don't fit either of those categories presently). That said I would petition the group asking that as a sys admin, I requested access because I felt responsible to know whether there were issues that might be dangerous for our site. 2011-08-11T14:42:10 i can understand not approving anyone who requests but for large consortia like Evergreen Indiana, Bibliomation, etc. I beleive we should be able to see any potential security issues so we can take measures to avoid having them impact us. 2011-08-11T14:42:25 archive policy was proposed here - http://libmail.georgialibraries.org/pipermail/open-ils-dev/2010-December/006663.html 2011-08-11T14:42:33 and met with no objections 2011-08-11T14:42:40 I suggest we dispense with the security mailing list then. I don't see the point 2011-08-11T14:42:41 senator is correct that the embargo is one year 2011-08-11T14:43:25 (I have no problem with the embargo - but broadly sharing details immediately makes little sense to me) 2011-08-11T14:44:47 so security issues should just be hidden from sys admins? i don't agree with that. The point of a list is to allow the devs to discuss the vulnerability. This should be transparent to organizations who are pumping, thousands (millions, even?) into the community. 2011-08-11T14:45:24 while i trust that the developers act quickly on such a situation, i don't think it'd be unreasonable to have some transparency so action can be taken in the time before a fix is released. 2011-08-11T14:46:01 the point of a closed security list is to limit awareness of a vulnerability until the devs can resolve the vulnerability, protecting the organizations who are pumping $$$ into the project 2011-08-11T14:46:08 * phasefx isn't privy to Windows security issues, and those affect more folks 2011-08-11T14:46:30 so we should just flap in the wind with a hole wide open instead of being able to take preventive action? 2011-08-11T14:47:07 i agree with closing the list to any joe schmoe who wants to sign up. i don't agree with rejecting someone like bshum from knowing there is a vulnerability so we can protect our organizations. 2011-08-11T14:47:12 * gmcharlt views letting known and trusted sysadmins join as an accountability mechanism 2011-08-11T14:47:35 i agree with you, 100% on limiting awareness, dbs 2011-08-11T14:48:04 just offering a point, not an opinion :) 2011-08-11T14:48:34 There are however at least a few known sysadmins, as gmcharlt points out, who aren't comitters. We're certainly not going to be exploiting a vulnerability in each others systems. 2011-08-11T14:49:59 It sounds like it's pretty quiet anyways, which is excellent. I just know there are some systems without a third-party support arm that may never know there is a problem, nor get it patched. 2011-08-11T14:51:36 mrpeters-isl: we have in the past made very public statements via the blog + mailing lists about security releases for exactly that reason - once a patch is available 2011-08-11T14:51:47 Doesn't releasing a patch expose the exploit just the same as discussion on the list amongst a trusted group? What if the patch is released and a system doesn't have the capability to patch themselves? Aren't they then vulnerable to the same exploit now that it is known? 2011-08-11T14:52:01 *** pmplett has joined #evergreen 2011-08-11T14:52:28 mrpeters-isl: well, ultimately it *is* their local admin's responsibility to keep up 2011-08-11T14:52:37 there's no perfect solution to security however you handle it 2011-08-11T14:52:48 yes, that's the whole point of having a closed security list; discuss the problem, work out a patch for the problem, then publicize the hell out of the problem & fix as soon as a proven fix is available 2011-08-11T14:52:50 though I think we're at the point where joining one of the formal security announcement processes would be a good idea 2011-08-11T14:53:23 I agree. I just think being looped in on the discussion would help those groups "keep up". 2011-08-11T14:53:40 dbs: it's also something that non-dev sysadmins could help with 2011-08-11T14:54:41 if I've jumped the gun and there's a consensus, I'm willing to unsubscribe bshum, but I do think there's a role for people like him 2011-08-11T14:55:08 * tsbere feels that bshum and mrpeters-isl would be fine being on the list 2011-08-11T14:55:16 gmcharlt: possibly. I obviously err on the side of being closed in this case, but I can see arguments for involving testers once testing is a possibility 2011-08-11T14:56:39 I don't care if I'm on the list or not as long as I can rest assured that we can depend on our tech support to protect us before a fix becomes available publicly. 2011-08-11T14:57:30 before? 2011-08-11T14:58:08 dbs: the committers know there is a hole but we're not notified. so, we're unprotected. 2011-08-11T14:58:34 if we don't know the exploit we can't take measuers to protect ourselves. If we do, we can work with our support vendor to take preventive measures before a patch is out. 2011-08-11T14:58:54 So: those orgs who pay (either via a support company with security team members, or by employing security team members) are supposed to get guaranteed access to security fixes before other libraries? 2011-08-11T14:59:41 dbs: Isn't that how most software companies end up working? :( 2011-08-11T15:00:05 For some definition of "working" perhaps... 2011-08-11T15:00:59 er, I'm pretty sure we *all* benefit if fixes to security issues are worked on collecitvely and released universally 2011-08-11T15:01:23 obviously some issues may get a temporary fix, then a permanent fix, but in that case, both fixes should be publicly released as soon as they're proven 2011-08-11T15:02:41 who is asking for a "guranteed" fix dan? 2011-08-11T15:03:31 While we're still discussing this, perhaps I should unsubscribe anyways until there's more consensus on things... I didn't mean to mess with the way things were going before. 2011-08-11T15:03:32 I'm asking to be in the know about a potential exploit that could cost me my job. 2011-08-11T15:03:46 bshum: this discussion needed to happen, don't feel bad 2011-08-11T15:05:01 mrpeters-isl: you said "as long as I can rest assured that we can depend on our tech support to protect us before a fix becomes available publicly" - sounds like a guarantee to me 2011-08-11T15:06:20 then yes, someone PAYING for technical support certainly should expect that the party being paid to provide said support keep them protected if the same folks are the ones fighting to keep the library from knowing about potential exploits. 2011-08-11T15:06:38 you can't have it both ways. we can't be left in the dark. we're not all so lucky as to have a comitter on staff. 2011-08-11T15:07:48 mrpeters-isl: But pushing an issue that is not currently known to have been exploited into the public eye *before* a solution is found is usually a bad idea. 2011-08-11T15:08:34 i disagree firmly that i'm "the public eye" 2011-08-11T15:09:11 frankly, i'm a bit offended if i'm not respected enough to be looped in on something that could cost my state significant embarassment 2011-08-11T15:09:58 * tsbere still holds that he has no issue with mrpeters-isl being on the list, as he mentioned earlier 2011-08-11T15:10:31 it sounds like there is still some objection to allowing anyone other than the core comitters so this discussion needs to happen, sooner or later. 2011-08-11T15:11:44 *** fortin has joined #evergreen 2011-08-11T15:11:50 I can understand that you would be offended. But my bias is towards limiting exposure of security vulnerabilities until there are known fixes. 2011-08-11T15:12:05 I'm left in an awful tough position when its "my responsibility" to stay up to date with security patches for my organization, yet some feel I shouldn't be privy to such exploits. So, how can I stay up to date? If i know there is an exploit perhaps I can devise a temporary solution to protect myself. 2011-08-11T15:12:28 You're talking about security patches when there are no patches to apply. 2011-08-11T15:12:57 But there are other protections that could be deployed! 2011-08-11T15:13:32 I can't take preventive measures if I'm left in the dark. 2011-08-11T15:13:40 If there are ways of mitigating a vulnerability, then the security team would communicate those, don't you think? 2011-08-11T15:14:09 no, i'd say judging from the position you have that no, we would have no idea about it 2011-08-11T15:15:28 Then you're mistaken. I said "the point of a closed security list is to limit awareness of a vulnerability until the devs can resolve the vulnerability" 2011-08-11T15:15:58 mrpeters-isl: then you're judging incorrectly, IMO. when there's a fix it's released. it may be configuration ("turn of X") or code ("upgrade to Y"), but /that's/ when it's safe to take outside the sec list 2011-08-11T15:16:19 I don't think there is anythnig left to say on my part. I think we agree on why a closed list is good. I don't think we will be able to agree on who should know about potential situations. I've made Indiana's position known. I suspect it will be handled at a different level at a later date. 2011-08-11T15:17:08 eeevil: it's just that time between exposure of the hole, and a solution. We're vulnerable for that time when perhaps we don't have to be. 2011-08-11T15:17:11 *** dbwells has joined #evergreen 2011-08-11T15:17:58 If we can say, for example, restrict something at the firewall to prevent an outside intrusion while we wait for a software level fix then why keep trusted individuals in the dark about it? 2011-08-11T15:17:59 mrpeters-isl: if there's no way to mitigate the issue then there's no "perhaps we don't have to be" 2011-08-11T15:19:25 I would trust that sort of solution to be presented to the community, if such solutions were possible. If the security list is to talk over issues that have no immediate resolution (of any kind), that's fine too. 2011-08-11T15:24:46 In the meantime, I'll just unsubscribe myself till there's a new official standpoint of where sys admins like myself stand as far as this particular list. 2011-08-11T15:26:20 *** dbwells has quit IRC 2011-08-11T15:42:12 *** dbwells has joined #evergreen 2011-08-11T15:54:48 *** jenny1 has joined #evergreen 2011-08-11T15:57:22 *** jenny has quit IRC 2011-08-11T15:59:23 *** jenny has joined #evergreen 2011-08-11T16:01:10 *** jenny1 has quit IRC 2011-08-11T16:20:35 *** collum has quit IRC 2011-08-11T16:29:36 *** dbwells has quit IRC 2011-08-11T16:34:02 *** dbwells has joined #evergreen 2011-08-11T16:51:57 *** natschil has joined #evergreen 2011-08-11T17:01:42 *** kmlussier has quit IRC 2011-08-11T17:02:43 *** akilsdonk has quit IRC 2011-08-11T17:07:05 *** dbs has quit IRC 2011-08-11T17:13:40 *** fortin has quit IRC 2011-08-11T17:18:03 *** dbwells has quit IRC 2011-08-11T17:28:02 *** dbwells has joined #evergreen 2011-08-11T17:28:51 *** Dyrcona has quit IRC 2011-08-11T17:38:51 *** dbwells has quit IRC 2011-08-11T17:44:59 *** dbwells has joined #evergreen 2011-08-11T17:50:30 *** dbwells has quit IRC 2011-08-11T17:52:56 *** dbwells has joined #evergreen 2011-08-11T17:57:20 *** jenny has left #evergreen 2011-08-11T17:59:17 *** natschil has quit IRC 2011-08-11T18:05:06 *** granitize has joined #evergreen 2011-08-11T18:56:05 *** AaronZ-PLS has joined #evergreen 2011-08-11T18:59:03 *** AaronZ-PLS has quit IRC 2011-08-11T19:15:51 *** youdonotexist has quit IRC 2011-08-11T19:25:27 *** dbwells has quit IRC 2011-08-11T19:54:58 *** granitize has quit IRC 2011-08-11T20:12:33 *** edoceo has quit IRC 2011-08-11T20:32:59 *** dbwells has joined #evergreen 2011-08-11T21:03:38 *** dbwells has quit IRC 2011-08-11T22:11:47 *** dbwells has joined #evergreen 2011-08-11T22:12:43 oof. long day. hi, #evergreen! 2011-08-11T23:14:13 *** pmplett_ has joined #evergreen 2011-08-11T23:15:36 *** pmplett has quit IRC 2011-08-11T23:16:21 *** pmplett_ is now known as pmplett 2011-08-11T23:28:54 *** dbwells has quit IRC