_whitelogger has joined #jruby
Freaky has joined #jruby
bastelfreak has joined #jruby
JasonLunn[m] has quit [Ping timeout: 260 seconds]
mrnoname1000[m] has quit [Ping timeout: 260 seconds]
mrnoname1000[m] has joined #jruby
JasonLunn[m] has joined #jruby
genpaku has quit [Ping timeout: 246 seconds]
genpaku has joined #jruby
ahorek[m] has quit [Quit: You have been kicked for being idle]
lopex[m] has quit [*.net *.split]
puritylake[m] has quit [*.net *.split]
puritylake[m] has joined #jruby
lopex[m] has joined #jruby
nilsding has quit [Ping timeout: 252 seconds]
byteit101[m] has quit [Ping timeout: 252 seconds]
enebo[m] has quit [Ping timeout: 252 seconds]
kares[m] has quit [Ping timeout: 248 seconds]
andrea[m]1234 has quit [Ping timeout: 248 seconds]
jimtng[m] has quit [Ping timeout: 248 seconds]
mrnoname1000[m] has quit [Ping timeout: 255 seconds]
headius has quit [Ping timeout: 265 seconds]
JasonLunn[m] has quit [Ping timeout: 268 seconds]
lopex[m] has quit [Ping timeout: 252 seconds]
puritylake[m] has quit [Ping timeout: 252 seconds]
mrnoname1000[m] has joined #jruby
JasonLunn[m] has joined #jruby
kares[m] has joined #jruby
jimtng[m] has joined #jruby
headius has joined #jruby
mrnoname1000[m] has quit [Quit: Bridge terminating on SIGTERM]
JasonLunn[m] has quit [Quit: Bridge terminating on SIGTERM]
kares[m] has quit [Quit: Bridge terminating on SIGTERM]
jimtng[m] has quit [Quit: Bridge terminating on SIGTERM]
headius has quit [Client Quit]
byteit101[m] has joined #jruby
enebo[m] has joined #jruby
andrea[m] has joined #jruby
kares[m] has joined #jruby
mrnoname1000[m] has joined #jruby
puritylake[m] has joined #jruby
JasonLunn[m] has joined #jruby
jimtng[m] has joined #jruby
nilsding has joined #jruby
lopex[m] has joined #jruby
headius has joined #jruby
JasonRogers[m] has joined #jruby
subbu has joined #jruby
subbu has quit [Quit: Leaving]
<headius> G'day
dangerousdave has joined #jruby
dangerousdave has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<enebo[m]> git show e6d8bd3c4ba
<enebo[m]> I believe no native extensions will work with old populators?
<enebo[m]> This surprises me that rails does not use any extensions which we do not compile for release
<headius> That looks like a bad build or mixing two JRuby versions
<headius> That particular populator should run at boot
<enebo[m]> So not precompiled into asciidoc?
<headius> No
<headius> It is booting kernel level module methods at startup
<enebo[m]> two people in it seem to be unrelated so I wonder what is up there
dangerousdave has joined #jruby
<headius> Yeah assuming there isn't a bad build out there, we should never get past boot if this method was not working
<headius> So I would lean towards a version conflict in the ASCII doctor plug-in
<enebo[m]> someone else pointed out there is a CVE in a method in the BC we shipped but I don't kow if we use it
<enebo[m]> kares: are you on vacation now?
<headius> I saw that email. We'll need to address that in jruby-openssl and get a release out
<enebo[m]> I know traditionally bc has not been good on being drop-in on point releases but since we can gem install jruby-openssl then I guess that makes that less critical
<enebo[m]> Or I should say it does not require an immediate security release of jruby itself
<headius> Yeah I don't think so
<headius> commented on the populator issue
<headius> I guess I don't know exactly how asciidoctor boots up j Ruby in the Maven plug-in so it is possible that it is calling our populators directly but it would be extremely weird and certainly out of bounds for a third-party library
<enebo[m]> I went to their page on maven and it is not enough to use it but mentions it is just a way of using asciidoctorj declaratively
<headius> I would guess this is a generic error coming from the code the plugin ships for booting JRuby before running asciidoctor
<headius> Ah yes I guess I mean asciidoctorj specifically when I say the plugin... Something in the plugin or libraries it ships would seem to be at fault here
<enebo[m]> but there seems to be a maven plugin which I hope is using the same jars as asciidotorj which is its own downloaded thing
<enebo[m]> AsciidoctorInvoker.class
<enebo[m]> unrelated
<headius> It would help if we could get a full stack trace
<enebo[m]> yeah and the last version set on main asciidoctorj is 9.3.4.0
dangerousdave has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<kares[m]> not yet, which cve?
<kares[m]> can take a look this week if it's a concern, a bc upgrade would need more work ...
<enebo[m]> kares: CVE-2018-5382 (BDSA-2018-1190).
<enebo[m]> Next point release past what we are using I guess fixes it.
<enebo[m]> kares: I sent email to you if you are not on security@jruby.org
<enebo[m]> I guess the long and short is if we can update the gem we do not need a full release which is simpler (other than BC maybe breaking something)
<kares[m]> first time I hear of BC's BKS key-store format ... we do not use it anywhere explicitly and I am not sure if it would work in any place where we might accept a .jks or .p12
<kares[m]> will audit the code tomorrow but seems like a very low risk
<kares[m]> that does not mean we should not upgrade BC but last time I tried I run into several issues and hadn't had the time since
<enebo[m]> kares: yeah I wondered about that. So I guess even if we say it is not used people will just keep telling us we are using insecure bc
<enebo[m]> Having just said that if we do not use it then we can just deal with it for later and not immediately/quickly
<headius> Yeah it didn't sound familiar to me either
dangerousdave has joined #jruby
dangerousdave has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
enebo[m] has quit [*.net *.split]
byteit101[m] has quit [*.net *.split]
andrea[m] has quit [*.net *.split]
fidothe has quit [*.net *.split]
headius has quit [*.net *.split]
nilsding has quit [*.net *.split]
lopex[m] has quit [*.net *.split]
mrnoname1000[m] has quit [*.net *.split]
kares[m] has quit [*.net *.split]
puritylake[m] has quit [*.net *.split]
JasonLunn[m] has quit [*.net *.split]
jimtng[m] has quit [*.net *.split]
dangerousdave has joined #jruby
enebo[m] has joined #jruby
kares[m] has joined #jruby
jimtng[m] has joined #jruby
nilsding has joined #jruby
andrea[m] has joined #jruby
headius has joined #jruby
lopex[m] has joined #jruby
puritylake[m] has joined #jruby
mrnoname1000[m] has joined #jruby
fidothe has joined #jruby
byteit101[m] has joined #jruby
JasonLunn[m] has joined #jruby
dangerousdave has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<headius> enebo: so I need to make a move on these docker images. Should I switch them all over to Temurin or just JDK 17 for now?
<enebo[m]> Temurin
<enebo[m]> It seems like it will be a single process for all and it will track all latest point/security fixes
<enebo[m]> As this is just for basic testing purposes I feel like any openjdk-variant works. We are not recommending these for production deploys
dangerousdave has joined #jruby
dangerousdave has quit [Client Quit]
dangerousdave has joined #jruby
<headius> I'm fine with that. I will repush my docker PR basing everything on Temurin
subbu has joined #jruby
sagax has joined #jruby
subbu has quit [Quit: Leaving]
dangerousdave has quit [Ping timeout: 272 seconds]