Time
S
Nick
Message
07:31 juancorr joined #dataverse
08:09 jri joined #dataverse
11:15 poikilotherm joined #dataverse
15:06 juancorr joined #dataverse
15:10 drew-jhu joined #dataverse
15:12 pdurbin
poikilotherm: you might be interested in this: https://www.e-science-tage.de
15:18 poikilotherm
AFAIK my colleage will be there :-)
15:18 poikilotherm
+u
15:20 pdurbin
cool, sounds like people from https://heidata.uni-heidelberg.de will be there
15:20 poikilotherm
IIRC the run it ;-)
15:20 poikilotherm
+y
15:20 pdurbin
ah
15:21 poikilotherm
Yeah, the URZ is the computing centre of Uni Heidelberg, to which the people from heidata belong, too
15:22 poikilotherm
Ok, to be precise: the conference is run by a collaboration from KIT, uni Konstanz and uni Heidelberg
15:22 poikilotherm
hmm... I think run should be replaced with hosted, right?
15:23 poikilotherm
Yeah. That vocab thing again.
15:25 pdurbin
either run or hosted is fine
15:25 poikilotherm
Thx :-)
17:49 drew-jhu joined #dataverse
18:57 drew-jhu
i recently noticed that our JVM options, including doi password (and rserve password, if we used it) get logged to server.log on glassfish startup. i see how one might adjust log levels in general (http://guides.dataverse.org/en/latest/developers/debugging.html?highlight=logging) , but the logger responsible (javax.enterprise.launcher) does not appear to be one of those found in the logging.properties file or returned by the list-log-levels comman
18:59 pdurbin
Yeah, that's not great. Maybe we should move them to the database.
19:00 drew-jhu
that would be an effective long-term solution
19:04 drew-jhu
interestingly, the log entry in question is the only one i have encountered that is in what the glassfish docs refer to as Oracle Diagnostics Logging (ODL) format. All the others are Uniform Log Formatter (ULF) format. This would suggest these entries are coming from somewhere else, code-wise.
19:07 pdurbin
I'm pretty sure this is out of the box Glassfish behavior to print the JVM options on startup. To test, one could download the glassfish zip file, run `asadmin start-domain`, and look at the logs. I don't know how to prevent it. Someone in #glassfish might know.
19:10 drew-jhu
ok. thx, Phil
19:12 pdurbin
I just did that test. It's the "JVM invocation command line" it looks like.
19:14 drew-jhu
y. that's the one
19:14 pdurbin
Here's that line in the Glassfish code: https://github.com/eclipse-ee4j/glassfish/blob/glassfish-main-aggregator-5.1.0-RC1/nucleus/admin/launcher/src/main/java/com/sun/enterprise/admin/launcher/GFLauncherLogger.java#L159
19:16 pdurbin
drew-jhu: do you feel like opening an issue on their GitHub?
19:17 pdurbin
You could certainly start by opening an issue in the Dataverse issue tracker.
19:19 drew-jhu
if i were confident i have done sufficient due dilligence. so far, a couple hours investigation, websearching, etc hasn't turned up a solution, but i am admittedly new to glassfish. wanted to make sure the answer wasn't obvious or easily findable by folks with more experience in this area
19:21 drew-jhu
i'll try the DV issue tracker first. perhaps a member of our community who doesn't happen to be at hand at the mo might have insight
19:23 pdurbin
Sure, sounds good.
19:40 pdurbin
thanks for opening https://github.com/IQSS/dataverse/issues/5412
19:41 pdurbin
I asked over at https://javabot.evanchooly.com/logs/%23glassfish/2018-12-19
19:43 pdurbin
I also dinked around with setting an smtp password (asadmin create-javamail-resource) but this isn't saved as a JVM option. It goes in <mail-resource>.
19:45 isullivan joined #dataverse
19:45 isullivan joined #dataverse
19:46 drew-jhu
(thumbsup)
19:46 pdurbin
In both cases, the passwords are in plain text in domain.xml.
19:48 isullivan1 joined #dataverse
19:50 drew-jhu
y. that isn't ideal. i'm more worried about the logs, though, as we are starting to look into exporting and centralizing them
19:53 pdurbin
Ok, and it sounds like you'd be happy with moving those passwords from JVM options to database settings.
19:57 drew-jhu
that would be a step in the right direction. better if they were encrypted in the db (TBH, I haven't looked into whether or not we are encrypting any of the DV data in the DB so far)
20:01 pdurbin
yeah, one step at a time I guess
20:01 drew-jhu
certainly
20:04 pdurbin
Also, I got your email about #269823. Can you please create a vague issue? And a pull request? I'm not sure what to tell you about the scanning report. You can email it to me if you want.
20:07 drew-jhu
sure. happen to have a public key?
20:10 pdurbin
I had one in the 90s. We use Accellion but I think that's only for sending files, not receiving: https://security.harvard.edu/pages/secure-file-transfer-confidential-information
20:11 pdurbin
You can get my GitHub public key at https://github.com/pdurbin.keys . Does that help?
20:12 pdurbin
I would probably just upload the report to that ticket anyway so you could just reply on the thread and attach it.
20:17 drew-jhu
ok then. apparently, someone did release a tool for encrypting stuff using github keys (https://github.com/kjvalencik/ghshare) , which means one could also do it manually. my pgp-fu is admittedly weak. since i'm both paranoid & lazy i usually use keybase.io for such things
20:18 pdurbin
Ah, keybase. Sure. But like I said I would just throw the report in the ticket anyway. Also, I just double checked that we're fine with a vague issue and pull request.
20:18 drew-jhu
:thumbsup:
20:19 pdurbin
I was sort of wondering what the status was so thanks for following up.
20:21 pameyer joined #dataverse
20:22 pameyer
drew-jhu: as far as I know, nothing in the db gets encrypted
20:22 drew-jhu
np. we are migrating our DOIs tomorrow, after our recent upgrade, so i have some cleanup and prep and cleanup to take care of. I should be able the get the PR to you by the end of the week, though
20:22 drew-jhu
good to know, @pameyer. thx
20:23 pdurbin
pameyer: no, we encrypt builtin user passwords with Bcrypt.
20:23 pameyer
pdurbin: good point. I'd had the settings table on the brain
20:24 pdurbin
yeah, nothing in the settings table is encrypted
20:24 pdurbin
drew-jhu: no rush but thank you
20:25 drew-jhu
HTH
20:26 pdurbin
Huh. The first release of Eclipse Glassfish happend 40 minutes ago: https://github.com/eclipse-ee4j/glassfish/releases/tag/5.1.0-RELEASE
20:26 pameyer
interesting timing
20:35 pameyer
drew-jhu: not sure if makes a difference to you or not, but default dataverse/glassfish behavior has 8080 open from off-host
20:43 drew-jhu
pameyer: as a security consideration, you mean?
20:54 drew-jhu83 joined #dataverse
20:54 pameyer
right
20:55 drew-jhu83 left #dataverse
20:56 drew-jhu28 joined #dataverse
20:57 drew-jhu28
pameyer: secured. thx for reminder.
20:58 pameyer
drew-jhu28: no problem
21:03 drew-jhu28
for a minute there, i thought you were trying to tell me something. had to go make sure my fly wasn't down :)
21:04 pameyer
nah - just that it surprised me the first time I did an off-host port-scan, and saw glassfish responding to the world ;)
21:06 drew-jhu28
indeed. i inherited a pretty thorough (if a little outdated) ansible playbook along with my Dataverse, so fortunately most of those surprises were already taken care of by the time i took responsibility
21:09 pdurbin
drew-jhu28: I just got a reply in #glassfish
21:10 pdurbin
"i dont think there's a straightforward supported way to do it... it'd probably mean hacking some code"
21:11 drew-jhu28
pdurbin: ok. thanks for checking on that for me
21:11 pdurbin
drew-jhu28: check this out: https://payara.gitbooks.io/payara-server/content/documentation/payara-server/password-aliases/
21:14 drew-jhu28
oh, rt. i did come across a ref to password aliases previously, but at the time, didn't have a need for them. that might be a good solution too
21:16 drew-jhu28
can't link to it directly, but the glassfish reference manual (under https://javaee.github.io/glassfish/documentation4) documents their use too
21:18 pdurbin
Ok, thanks. You don't need any changes in the Dataverse code to play with these do you?
21:18 drew-jhu28
guess it would then be a question of whether the DV code that makes use of them was able to decrypt?
21:18 pameyer
this is the first I've heard of password aliases; but if it eliminates the need to remind folks to scrub gf logs before adding to github
21:22 drew-jhu28
code like this: https://github.com/IQSS/dataverse/blob/57b3b7e279802b5cc78921051e7431ea6a272be7/src/main/java/edu/harvard/iq/dataverse/DOIDataCiteRegisterService.java#L45
21:23 pdurbin
Sure. System.getProperty is "go look up this JVM option"
21:24 pdurbin
But maybe the idea is that the JVM option has an alias rathter than a hard coded password?
21:27 drew-jhu28
idk. that payara doc & the gf docs give me the idea that you need to retreive the vaule using something like '${ALIAS=aliasname}'
21:28 pdurbin
No, I think "${ALIAS=aliasname}" is what's in the domain.xml.
21:30 drew-jhu28
ok. cool. if there's already enough abstraction in place for it to JustWork(tm), that'd be great
21:31 pdurbin
fingers crossed
21:32 drew-jhu28
i'll play around with this after i get my DOIs sorted. thx for the suggestion
21:33 pdurbin
sure, thank the guy in #glassfish, I'd never heard of these :)
21:34 pdurbin
I'm seeing an example of "<password>${ALIAS=mysql-db-password}</password>" for web.xml rather than domain.xml at https://docs.payara.fish/documentation/payara-server/server-configuration/var-substitution/usage-of-variables.html but I hope it's the same idea.
21:35 pdurbin
"You should change your resource passwords to aliased ones. Use the asadmin create-password-alias cmd to change clear-text passwords in domain.xml to ${ALIAS=xxxx} entries." https://blog.eisele.net/2011/05/securing-your-glassfish-hardening-guide.html
21:37 drew-jhu28
looks like there are a number of good recommendations in there. good find
21:39 drew-jhu28
i'm audi. thx for the help!
21:39 pdurbin
sure!
21:39 drew-jhu28 left #dataverse
