<enebo[m]>
byteit101: also merge your other PR with master soon so it removes your other PRs code from the diff
sagax has quit [Ping timeout: 246 seconds]
<enebo[m]>
kares: sorry for asking again this morning but does 0.14.0 have the same issues that 0.14.1pre have? This guy is specifically saying if they have the same security issues then he cannot use 9.3.9.0 due to some error: https://github.com/jruby/jruby/issues/7398
<enebo[m]>
I am really confused by the report because it links 0.14.0 and 1.14.1rc (which was not released). I can see you changed how you were reading input in that PR that is linked
<enebo[m]>
So I think this is ONLY in the unreleased version but I am not sure :)
<enebo[m]>
I don't get why a security site like this will not just link to the specific code
<kares[m]>
It's a problem with the Sonatype tool he/she is using and he already stated that ... just consider there's no 0.14.1 for now it has no value on top of 0.14.0 ATM other than trying out a bug fix for a totally different issue ... and failing to actually fix it.
<enebo[m]>
so this is crystal clear to me...that report is literally only about the PR of unreleased code
<enebo[m]>
or not ever used code
<kares[m]>
that PR was very internal I am not sure how the tool figured out security fixes from it ...
<kares[m]>
yeah parts of that PR are already reverted on master (which will end up as 0.14.1)
<enebo[m]>
ok so I will just reply saying the code it reported on is not in 9.3.9.0 and will not be in any other release
<kares[m]>
sorry I am still on mobile and have a new laptop... once I am all set I will do a 0.14.1 there's actually 2 (unrelated to security) bug fixes on master - maybe that will also help getting rid of these comments 😃
<kares[m]>
enebo[m]: Makes sense, thanks
<headius>
Good morning
<enebo[m]>
kares: thanks for the confirmation
razetime has quit [Ping timeout: 256 seconds]
razetime has joined #jruby
<headius>
enebo: all load specs pass now
razetime has quit [Ping timeout: 260 seconds]
razetime has joined #jruby
razetime has quit [Ping timeout: 268 seconds]
razetime has joined #jruby
<headius>
cleared up a few more load/require tags
<enebo[m]>
headius: fantastic
<headius>
heh
<byteit101[m]>
did a mergout on #7393 (pty.spawn). Definitely want some opinions on the off-by-default change in Ruby.java that I've been using to test Process.spawn
<headius>
I was able to implement Fiber#blocking? because without scheduler it's just a flag
<byteit101[m]>
I would like some testing on other machines with it on though
<headius>
enebo: I also implemented Fiber#backtrace? and checked that all Fiber features from 3.0 are there now (other than those related to scheduler)
<enebo[m]>
yeah cool. I just added PR for Date::Error replacing ArgumentError
<enebo[m]>
cloning selenium to examine that kwargs issue
<enebo[m]>
I am hoping it shows up in unit tests based on what it is
<headius>
yeah
<headius>
looking into the last couple items I thought we might need
<enebo[m]>
but I also know mkdir_fu shows a kwarg error involving super, interpolation, and ruby2_keyword_hash
<headius>
the class variable thing doesn't seem important, just a new error for cases where cvar overtakes one from elsewhere in hierarchy
<enebo[m]>
So it could just be a duplicate of that
<enebo[m]>
yeah I didn't think it was important enough to even look into it
<enebo[m]>
I believe errors in most cases are secondary to non-error cases
<enebo[m]>
The Date::Error work is about errors but I fixed it because Date::Error does not exist so any reference to it would blow up
<enebo[m]>
There are literally hundreds of openssl errors in MRI test-extras
<enebo[m]>
We obviously will not be addressing those but it underscores the need to look for something new
<enebo[m]>
I mean not addressing for next week
<headius>
yeah
<headius>
rough situation there
<enebo[m]>
selenium is gigabytes of repo
<enebo[m]>
all language bindings are subdirectories
<headius>
wow
<headius>
enebo: gonna do some releasing to get deps updated... mostly jnr stuff for loongarch and recent fixes
<enebo[m]>
So this fixed that individual test so I expect that to be green but I don't really get what load of nil represents here. It was clearly here long before your PR.
<byteit101[m]>
Oh that's werid. Thanks for the fix
<byteit101[m]>
I'm not sure what nil represents
<enebo[m]>
byteit101: I noticed another problem: jruby -rpty -e 1
<enebo[m]>
It is possible my dev env has wrong version of something perhaps?
<enebo[m]>
I know your next version changes this
<enebo[m]>
err version=pr
<byteit101[m]>
is that with or without my PR?
<enebo[m]>
That is HEAD after merging the first PR
<enebo[m]>
LoadError: Could not open library 'libutil' : libutil: cannot open shared object file: No such file or directory.
<byteit101[m]>
what's the error?
<enebo[m]>
ffi_lib at /home/enebo/work/jruby/lib/ruby/gems/shared/gems/ffi-1.15.5-java/lib/ffi/library.rb:145
<enebo[m]>
lol...i will give you one nibble at a time: NAME THAT TUNE!
<byteit101[m]>
weird
<enebo[m]>
I happened to notice this because I did a test:jruby because of my date changes and 2 of these pty tests worked but I had not pulled yet (and windows does not run them so we will not see this on ci)
<byteit101[m]>
building master, please hold
<byteit101[m]>
(works fine on my branch locally though)
<enebo[m]>
where should libutil.so be located?
<enebo[m]>
I am on fedora core
<byteit101[m]>
/lib/x86_64-linux-gnu/libutil-2.31.so on debian based
<enebo[m]>
This is for openpty?
<byteit101[m]>
/lib64/libutil-2.28.so
<byteit101[m]>
yup
<byteit101[m]>
^ CentOS, so fedora is similar probbly
<byteit101[m]>
man openpty says -lutil
<enebo[m]>
I have a /lib64/libutil.so.1
<byteit101[m]>
good
<byteit101[m]>
I have that symlinking to the versioned fiile
<enebo[m]>
I presume there is a libutil.so somewhere with a hard or soft link
<enebo[m]>
looks like at least two linuxy systems have this problem
<byteit101[m]>
could be an issue with ffi lookup
<byteit101[m]>
the nil library is the current process, apparently
<enebo[m]>
ah ok fun
<enebo[m]>
yeah so /lib64/libutil.so.1 is part of glibc-devel and I reinstalled it and it has no libutil.so placed
<enebo[m]>
which defies my expectations
<enebo[m]>
I always assumed there is a .so pointing at the latest stable version
<enebo[m]>
That issue above also implied some ubuntu project also has this issue. I am going to switch back to fixing hopefuly last kwargs issue
<enebo[m]>
The summary is I have no libutil.so at all so I don't know how we figure out what to even load
<headius>
I have that error too
<byteit101[m]>
ldconfig difference, actually. ld.so.cache contains a pointer from libutil.so to libutil.so.1 on ubutnu, despite not having an actual symlink
<enebo[m]>
There is a single reference to libutil.so.1
<enebo[m]>
So I do not remember how we know how to actually use ld.co.cache to look anything up. I know it will use it for dynamic linking but nothing beyond that
<byteit101[m]>
dlopen uses the cache
<enebo[m]>
ldconfig -p | grep libutil
<enebo[m]>
libutil.so.1 (libc6,x86-64, OS ABI: Linux 3.2.0) => /lib64/libutil.so.1
<byteit101[m]>
so this is a fundamental distro difference. dlopen("libutil.so") in C works on ubuntu, but fails on fedora
<enebo[m]>
yeah so I was hoping I would see some entry here from .so -> so.1
<enebo[m]>
so one some linux systems .so.1 is a thing you ask for by name and .so does not exist
<enebo[m]>
ok so you do have a .so.1 entry as well
<enebo[m]>
Maybe .so.1 instead of .so is universal but this is not how I remember things...with that said I have not really did anything with this since the 90s
<byteit101[m]>
oh hmm, wait, those link to the nonexistent file
<enebo[m]>
unless I am debugging stuff like this
<enebo[m]>
yay
<enebo[m]>
nice cache
<byteit101[m]>
hu, hI only have 32 bit libutil.so
<enebo[m]>
32 bit?
<enebo[m]>
What are you using?
<enebo[m]>
you on a pentium 5
<enebo[m]>
ffi is not querying ldconfig though is it?
<byteit101[m]>
Oh nvm, I have all of them, was looking in the wrong folder
<enebo[m]>
FFI.map_library_name(n)
<enebo[m]>
right?
<byteit101[m]>
no, it's dlopen querying config
<byteit101[m]>
I mentioned that one screenful ago
<byteit101[m]>
doesn't do what it says in the comments
<headius>
Like all the libc let get linked to the same ABI number
<enebo[m]>
I didn't think LSB was still a thing
<enebo[m]>
fwiw for what we are doing here I doubt it matters which version we link to
<enebo[m]>
The ABI of what we are calling probably has never changed
<enebo[m]>
byteit101: but yeah that snippet works on my machine
<byteit101[m]>
alright, good. I'll fix subspawn then, as that is where I moved that one line of code to
<enebo[m]>
but how does this work in C?
<enebo[m]>
I mean I see lots of results of C programs specifically showing "libinput.so.1" -> somelocation which sort of implies they know to link against libinput.so.1. Linux Standard Base does impl .so.1 means something so I wonder if this will just work everywhere
<enebo[m]>
We know it will work on debian and FC and presumably from that comment ubuntu too
<enebo[m]>
Still how is this specified if you want to use it from C? I would think it would be -linput but how does that become input.so.1
<enebo[m]>
(note: I am betting just using "libinput.so.1" will just happen to work everywhere but something about it feels like we don't understand something)
<byteit101[m]>
-linput is ld, and ld needs the dev package to know
<byteit101[m]>
this is dlopen, and you just need to know I think
<enebo[m]>
but ld can do this translation if loading shared vs static
<enebo[m]>
I guess it is in C code
<enebo[m]>
Or can it?
<enebo[m]>
ok well it sounds like we have something which will work in every env we can test
<enebo[m]>
looks like JIT is off-by-one on line number?
<enebo[m]>
HEH also interp so all off by one
<byteit101[m]>
if you want to re-open 4672 so we can close it with the pty/subspawn PR I'm fine either way
<enebo[m]>
byteit101: just open a new one. we will just land it
<headius>
Oh weird ok
<headius>
Yeah I ran the specs for blocking fiber but there's no specs for backtrace and I just deleted those excludes without trying them
<headius>
I'll take a peek and see if the test should be adjusted or if there's something to be improved in the line number we return
<enebo[m]>
It could be a mistake in AST too. It is only off by one so I am hoping it is just a +1 sort of error
<headius>
Yeah we are pretty good about matching line numbers elsewhere so it's probably not using the right line for the start of the fiber block or something like that
<enebo[m]>
So selenium works ok for me but I am not using any API which explicitly is moving the cursor around so I maybe am not hitting the right code
<headius>
Zero based lines from the parser mean I constantly forget to add one
<headius>
Hmm
<enebo[m]>
If I fix this other kwargs bug and it is not fixed I might do Brian's idea for undefined which records where it was created and probably force an IR dump
<headius>
The guy's report did seem to be a pretty recent hash
<headius>
Yeah that'd be a good idea
<headius>
Other than this what else do you think we need to do before release
<headius>
I have it on my list to get the m1 CI builds working
<enebo[m]>
the issue from the backtrace is it is processing a pointer move and it is process "@actions" and that is a list which seems to contain an undefined value
<headius>
Right so some keyword processing somewhere is not treating the undefined as a null value
<enebo[m]>
so however that is being made is likely calling kwargs with I am betting super and saving undefined as a value which then ends up in that life
<enebo[m]>
lidt
<enebo[m]>
well fu on this
<enebo[m]>
Somehow my dev dir has the wrong version of Rake for file_utils_ext.rb but it will version as the right version