| Time |
Nick |
Message |
| 07:52 |
|
redavis joined #evergreen |
| 08:12 |
|
ianskelskey joined #evergreen |
| 08:37 |
|
dguarrac joined #evergreen |
| 08:46 |
|
mmorgan joined #evergreen |
| 08:50 |
|
mantis joined #evergreen |
| 08:56 |
dguarrac |
release_team++ |
| 09:02 |
|
mantis left #evergreen |
| 09:04 |
|
mantis joined #evergreen |
| 09:09 |
|
Dyrcona joined #evergreen |
| 09:23 |
mantis |
for the pingest.pl file, do you need to declare the database info on line 192 before running? |
| 09:29 |
Dyrcona |
It accepts command line options. You can change the defaults locally if you like. |
| 09:29 |
mantis |
Dyrcona++ |
| 09:29 |
Dyrcona |
Same as psql for the most part, with long options: -U/--user -d/--database, etc. |
| 09:31 |
Dyrcona |
It uses the Perl DBI module, so it will also use a ~/.pgpass file if it exists. |
| 09:32 |
Dyrcona |
I usually rely on .pgpass to avoid putting the password on the cli or in the environment. |
| 09:33 |
Dyrcona |
berick: Do you know if the rust Pg module uses the default env variables and .pgpass, yet? [I suppose I could check the github page to see if those features have been added.] |
| 09:36 |
Dyrcona |
For completeness in the logs, pingest.pl also checks the PG environment variables: PGHOST, PGDATABASE, PGUSER, etc. So, you can set those in .bash_profile or .bashrc if you mostly use 1 database all the time. |
| 09:49 |
berick |
Dyrcona: the EG rust code (db.rs) will check the standard ENV vars |
| 09:49 |
berick |
looks like pgpass is pending on the rust-postgres mod, but there's also the postgres_secrets mod, which I haven't tried yet |
| 09:50 |
Dyrcona |
berick++ I had not heard of postgres_secrets. |
| 09:51 |
Dyrcona |
Perhaps I'll experiment with Rust again in the coming weeks. |
| 09:52 |
berick |
that reminds me I keep meaning to send a "any interest in rust working group" email to the dev list |
| 09:53 |
mantis |
kicking off our pingest; we'll see how long it takes :-X |
| 09:57 |
Dyrcona |
mantis: You can experiment with the --batch option sizes. In my test enviroment, I find going with 1000 runs pretty fast. |
| 09:57 |
mantis |
I have a batch of 10000 for now |
| 09:57 |
Bmagic |
mantis: if you use the linux command "time" you can let the computer tell you how long it takes. You would execute pingest.pl like you would normally, but put the word "time" in front. Like "time pingest.pl --switches....." |
| 10:07 |
mantis |
do you use a particular "max-child" flag? |
| 10:11 |
JBoyer |
If memory serves that's how many active simultaneous processes will be running, so the best value depends on your hardware. On a test system you could use the number of processors in the system to go as fast as possible, but should use a lower count for prod, depending on the use it sees. |
| 10:11 |
Dyrcona |
No, I usually go with 8, but it depends on how many cores your db server and/or utility machine have, assuming that they're separate. |
| 10:11 |
JBoyer |
(meaning the number of cpus on your database, not necessarily the machine running it.) |
| 10:15 |
Dyrcona |
Also, if you don't skip the browse ingest, there will be 1 child process doing the browse ingest on all of the records because the browse ingest can't be done in parallel. You eventually run into a deadlock(?) when two processes try to update the same record. (Mark Twain seems to be a common one for us.) |
| 10:22 |
csharp_ |
berick: I'm I rust n00b but interested |
| 10:22 |
berick |
csharp_: cool |
| 10:23 |
csharp_ |
I would like our scripts to start using https://www.postgresql.org/docs/current/libpq-pgservice.html by default, but I am but one person |
| 10:24 |
csharp_ |
I don't like seeing passwords on the command line :-/ |
| 10:33 |
Bmagic |
Speaking of security: it has come to my attention that Evergreen delivers the staff/patron password to the server raw (not hashed). Anyone know why Evergreen sends the credentials like that? I understand that it's encrypted via SSL. |
| 10:34 |
berick |
Bmagic: because it's encrypted via SSL |
| 10:34 |
Bmagic |
:) |
| 10:35 |
csharp_ |
the hashing happens at the PG level, right? |
| 10:35 |
Bmagic |
It gets MD5'ed on the server-side anyways. I wonder if we could MD5 it on the client first then send it? |
| 10:35 |
csharp_ |
sounds like a solid bug report to me |
| 10:35 |
berick |
not saying it couldn't be improved, but the md5 approach we were using was not particularly secure |
| 10:36 |
berick |
that's how we used to do it :) |
| 10:36 |
berick |
it complicates the client side for minimal benefit |
| 10:37 |
Bmagic |
on the server it's: md5(salt) || md5(password), assuming the password that is passed in is the raw password and hasn't already been md5'ed |
| 10:38 |
berick |
Bmagic: an api which accepts the md5 variant still exists |
| 10:38 |
berick |
if we want to make it more secure, though, i suspect there are far better options |
| 10:39 |
berick |
Bmagic: what's the concern exactly? |
| 10:40 |
Bmagic |
Best practices (I thought) were to do something to the password on the client-side first so that (even though SSL is wrapping the conversation) it's not the real password on the wire |
| 10:41 |
berick |
gotcha, k, just making sure there's not an active exploit |
| 10:43 |
Dyrcona |
MD5 has collisions. SHA512 is where it's at. "Two turntables and a microphone..." |
| 10:44 |
Dyrcona |
IF someone can get your plain text password from your TLS encrypted stream, you got what's called a man-in-the-middle and you got big problems. |
| 10:45 |
Bmagic |
that's right |
| 10:45 |
|
Llewellyn joined #evergreen |
| 10:47 |
Dyrcona |
Do we actually send it plain text though? I thought it get MD5'd before it got to the server? I guess that's only after it arrives, huh. |
| 10:47 |
Llewellyn |
I did a test on it yesterday, I added a logger statement to Actor.pm and was able to capture incoming passwords. |
| 10:47 |
berick |
it's plain text via the API, salted+hashed in the db |
| 10:47 |
Bmagic |
I'll let Llewellyn take that one |
| 10:47 |
Dyrcona |
Llewellyn++ |
| 10:48 |
berick |
some history https://bugs.launchpad.net/evergreen/+bug/1710949 |
| 10:48 |
pinesol |
Launchpad bug 1710949 in Evergreen "A one-call login API would be swell" [Wishlist,Fix released] |
| 10:49 |
Dyrcona |
Didn't we used to do something like CHAP somewhere? |
| 10:49 |
Dyrcona |
Maybe we only talked about it at a hackfest or something? |
| 10:51 |
Dyrcona |
The top answer say on Stack Exchange (fwiw) says, "It is standard practice to send "plaintext" passwords over HTTPS." |
| 10:51 |
Bmagic |
ha! |
| 10:51 |
Dyrcona |
I Engrish good. |
| 10:52 |
Dyrcona |
More from the answer: "Encrypting the password before sending it in HTTPS doesn't accomplish much: if the attacker got their hands on the encrypted password they could simply use it as if it were the actual password[.]" |
| 10:52 |
Bmagic |
ah! That makes sense! What a great point |
| 10:53 |
Bmagic |
The issue is: if the user's password is good for their account for other vendors |
| 10:54 |
|
sandbergja joined #evergreen |
| 10:54 |
Bmagic |
JS doesn't have md5 available to it without bringing in an external package? (probably) |
| 10:54 |
Dyrcona |
Well, there's a mechanism where users *could* have different passwords for different vendors.... It's there and would need a little fleshing out, maybe. It might *just work* |
| 10:55 |
Dyrcona |
MD5 is relatively easy to implement. |
| 10:56 |
Dyrcona |
I think we should implement OAuth2 (whatever version is coolest). |
| 10:56 |
csharp_ |
somewhat related, I saw that EFF/LetsEncrypt is now supporting 6 day SSL certificates to help prevent MITM things: https://letsencrypt.org/2025/02/20/first-short-lived-cert-issued/ |
| 10:57 |
Dyrcona |
That seems a bit drastic. |
| 10:57 |
csharp_ |
we were actually kind of alarmed that things may have gotten that bad :-) |
| 10:57 |
Bmagic |
Quantum computers + AI = disaster for encryption |
| 10:58 |
Dyrcona |
Related to Let's Encrypt and certs: I'm thinking of just shutting off my personal/business web server and not replacing it with a site hosted elsewhere. |
| 10:58 |
Llewellyn |
MD5 hash the raw password client side, send that to the server, add the salt, then bcrypt that. Man in the middle knows the MD5 hash but wouldn't know the salt? |
| 10:58 |
Dyrcona |
Bmagic: I'll believe it when I see it. |
| 10:58 |
sleary |
bug 2043040 |
| 10:58 |
pinesol |
Launchpad bug 2043040 in Evergreen "wishlist: Single Sign on for Evergreen Staff Client" [Wishlist,Confirmed] https://launchpad.net/bugs/2043040 |
| 10:58 |
Dyrcona |
Llewellyn: That accomplishes nothing. MITM just sends MD5 hashed password and he's in. |
| 10:59 |
Dyrcona |
If you got a MITM, you got bigger problems. |
| 10:59 |
Bmagic |
Llewellyn: correct, but* the man in the middle can just use the MD5 version of the password (just like the client software did) and they'd login no problem |
| 10:59 |
Llewellyn |
hmmm |
| 10:59 |
sleary |
^^ SSO branch with a PR ready for people to test. |
| 10:59 |
Bmagic |
sleary++ |
| 11:01 |
Bmagic |
Llewellyn: in other words: the benefit is nill, with the exception being: if the patron uses the same password in other places, the attacker would be able to access their account in the other places now that they had the raw password. Whereas, the md5 version wouldn't work in other places |
| 11:01 |
Llewellyn |
better than nothing imo |
| 11:01 |
redavis |
sleary++ |
| 11:07 |
* Dyrcona |
hears the Kabuki music starting... |
| 11:21 |
Dyrcona |
SSO for the staff client is nice. What I was referring to earlier was Bmagic's comment about the Evergreen password being used by vendors. I'd like to see us implement an OAuth endpoint or whatever for Evergreen, so you can sign in to 3rd party products using your library account like you would use your Google account. |
| 11:21 |
Bmagic |
piece of cake |
| 11:22 |
Dyrcona |
I don't think I've made a Lp bug for that, either. Just something I've thought about from time to time. |
| 11:22 |
Bmagic |
Making Evergreen the IDP, sounds cool! |
| 11:23 |
Bmagic |
Correct me, but that would mean that X vendor would need to have a little programming on their side to support our OAuth2? |
| 11:24 |
Dyrcona |
Yes, but it's "standard" and hopefully they might already do it. |
| 11:25 |
Dyrcona |
I'm thinking it could replace SIP2.... |
| 11:25 |
Bmagic |
each website I've interacted with that supports 3rd party auth, always presents me with a couple of pre-made selections. Example, Zoom's authentication portal offers Google Auth. In this context, we'd want Zoom to have a button for "Evergreen"? |
| 11:26 |
Dyrcona |
ha! The AI Overview from Google says we already have it. |
| 11:26 |
Llewellyn |
Google's AI is alwaaaays wrong |
| 11:26 |
Bmagic |
I think you might be seeing a different product called Evergreen |
| 11:26 |
Dyrcona |
Not Zoom. I'm thinking Overdrive things like that. |
| 11:26 |
Bmagic |
I've been tricked by that before |
| 11:27 |
Dyrcona |
Well, I know it is wrong in this case. |
| 11:27 |
Dyrcona |
Hence, the "ha!" |
| 11:28 |
Dyrcona |
Seeing as the AI Overview's link for one of the ILS goes to a 404 on github.... |
| 11:31 |
Dyrcona |
I don't think that ILS, LibiT, exists. |
| 11:31 |
Dyrcona |
LibriT |
| 11:32 |
|
jihpringle joined #evergreen |
| 11:32 |
Dyrcona |
BTW, I don't think A.I. means artificial intelligence. It's more like Algorithmic Imitation in practice. I'm also not so sure that natural intelligence is a thing either. |
| 11:33 |
Bmagic |
I agree, but you have to agree that it's freaky |
| 11:34 |
|
Christineb joined #evergreen |
| 11:37 |
* Bmagic |
waves at Christineb |
| 11:55 |
sleary |
release_team++ |
| 11:56 |
redavis |
And website post is up. Whewy boy |
| 11:56 |
redavis |
https://evergreen-ils.org/ |
| 11:57 |
Dyrcona |
redavis++ |
| 11:57 |
Dyrcona |
release_team++ |
| 11:57 |
redavis |
release_team++ |
| 11:57 |
redavis |
evegreen_community++ |
| 11:58 |
* Christineb |
waves at Bmagic |
| 11:58 |
Christineb |
:D |
| 12:00 |
sleary |
\o/ |
| 12:01 |
berick |
\m/ |
| 12:03 |
Dyrcona |
Wow! Never thought of what to do with a no trespass order before. How would you prevent a patron from picking a specific library for holds pickup? |
| 12:03 |
redavis |
(ain't even a post without a broken link/typo |
| 12:04 |
redavis |
Might have to create a new profile type for them. Lot of work though. |
| 12:05 |
Dyrcona |
This might be bug-worthy on Lp. |
| 12:06 |
Dyrcona |
I can imagine something like work_ous but for patrons, but the logic might get complicated. |
| 12:07 |
redavis |
Dyrcona++ |
| 12:07 |
dguarrac |
Dyrcona: Would a STAFF_CHR penalty applied just at that org unit work? |
| 12:07 |
dguarrac |
I don't actually know how the H in the CHR works. |
| 12:08 |
Dyrcona |
dguarrac: Yeah, that probably will work. |
| 12:08 |
Dyrcona |
I can test it. |
| 12:08 |
* Dyrcona |
overlooks penalties sometimes. |
| 12:09 |
Dyrcona |
dguarrac++ That works. |
| 12:09 |
dguarrac |
woohoo! |
| 12:09 |
redavis |
dguarrac++ |
| 12:35 |
|
jihpringle joined #evergreen |
| 12:37 |
csharp_ |
willing to trespass, unwilling to ban, hmm? |
| 12:38 |
Dyrcona |
Amounts to the same thing as far as the one library is concerned. Guess they don't want to block them from using other libraries, or we misinterpreted the request. |
| 12:38 |
csharp_ |
ah |
| 12:39 |
Dyrcona |
No idea what happened. |
| 12:39 |
csharp_ |
yeah, when it gets to that point it's usually a complicated story requiring paragraphs of explanation |
| 12:40 |
csharp_ |
we had an ex-staff-member situation here recently that sounds similar |
| 12:40 |
csharp_ |
(ex-library, not ex-GPLS) |
| 12:41 |
Dyrcona |
Yeah, there have been incidents with library staff in the past here. |
| 12:41 |
csharp_ |
close your eyes, think of England, and click the banned checkbox |
| 12:41 |
Dyrcona |
:) |
| 12:42 |
* csharp_ |
is rewatching The Guns of Navarone and has that David Niven line in his head |
| 12:56 |
|
jihpringle17 joined #evergreen |
| 13:02 |
|
collum joined #evergreen |
| 13:04 |
|
terranm joined #evergreen |
| 13:05 |
terranm |
If any seasoned developers are available for new devs today at 3pm eastern, I'd love some guidance on this bug - https://bugs.launchpad.net/evergreen/+bug/2107209 |
| 13:05 |
pinesol |
Launchpad bug 2107209 in Evergreen "Author links break in several places when MARC 100 subfields are present" [High,New] |
| 13:59 |
|
terranm joined #evergreen |
| 14:21 |
pinesol |
News from commits: LP2106780 Adjust karma.conf.js for concurrency, logging, timeouts <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=fd5bdc1da02a345394a31c0946ed7336671d1b40> |
| 14:21 |
pinesol |
News from commits: LP2106780 IDL service, Item attr unit test fixes <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=b39e987eded3dce5921059d2c910fcdb1930d480> |
| 14:21 |
pinesol |
News from commits: LP2106780 Unit test updates for 3.15 <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=be56cbc0adc5e6ed799d0eecbafc0906fd23ab8a> |
| 14:54 |
|
collum joined #evergreen |
| 14:58 |
terranm |
NVM I just figured it out, and it requires the change of a single character, lol |
| 15:02 |
csharp_ |
terranm++ |
| 15:06 |
Bmagic |
has anyone created an AT that fires an email when a patron renews something? |
| 15:11 |
Bmagic |
I'm assuming that a non-passive trigger is fired by the perl code when there is an active event definition pertaining to the circulation as it's getting renewed/created? |
| 15:13 |
Bmagic |
found sub make_trigger_events ... $U->create_events_for_hook('renewal', $self->circ, $self->circ_lib) if $self->is_renewal; |
| 15:13 |
Bmagic |
seems legit |
| 15:23 |
|
jihpringle joined #evergreen |
| 15:36 |
|
mantis left #evergreen |
| 15:47 |
Dyrcona |
Bmagic: Yes, just create an event for the renewal hook and it should work. |
| 15:49 |
Bmagic |
cool, seems logical. I've not done it before, so I thought I would see what others had to say |
| 15:50 |
Dyrcona |
I think active events have to have a filter, so you may have to add for circ in /openils/conf/action_trigger_filters.json. |
| 15:50 |
Bmagic |
in this case, it's passive=false |
| 15:51 |
Dyrcona |
Right. That makes it an active event. |
| 15:51 |
Bmagic |
lol, ok, right |
| 15:51 |
Bmagic |
there isn't a cron job for it in this case |
| 15:51 |
Bmagic |
(right?) |
| 15:51 |
Dyrcona |
Shouldn't need one. It will be created when an item is renewed. |
| 15:51 |
Bmagic |
or, does the perl code just create the row in action_trigger.event with the assumption that a cron job will sweep it up next time? |
| 15:53 |
Dyrcona |
OK. Looks like you only need a filter to batch create active events. |
| 15:53 |
Dyrcona |
The event should get created and set to pending, then you should have a --run-pending action_trigger_runner.pl going every so often with no granularity. |
| 15:55 |
Dyrcona |
You can go all the way and create, then run the event, but that would require modification of O::A::Circ::Circulate.pm. |
| 15:55 |
Bmagic |
right on, it makes sense |
| 15:56 |
Dyrcona |
If this is for a notification, you'll want to group on the circ.usr field. |
| 15:56 |
Bmagic |
yep |
| 16:06 |
|
jihpringle59 joined #evergreen |
| 16:15 |
|
Llewellyn joined #evergreen |
| 16:21 |
jeff |
oh hey, between 3.10 and 3.13 date1 stopped being a thing in metabib.record_attr_flat. took a little while to notice. |
| 16:21 |
* jeff |
digs |
| 16:50 |
|
redavis joined #evergreen |
| 17:07 |
mmorgan |
jeff: Could this be related to bug 2073561? I have to run but wanted throw it out there. |
| 17:07 |
pinesol |
Launchpad bug 2073561 in Evergreen 3.14 "Incorrect content in the config.coded_value_map after applying the upgrade script from 3.12.3 to 3.13.0" [High,Fix released] https://launchpad.net/bugs/2073561 |
| 17:08 |
|
mmorgan left #evergreen |
| 17:46 |
|
sandbergja joined #evergreen |
| 17:46 |
|
jihpringle joined #evergreen |
