<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]