frobs has quit [Read error: Connection reset by peer]
dabradley has joined #jruby
benlovell has joined #jruby
subbu has quit [Ping timeout: 272 seconds]
dumdedum has quit [Remote host closed the connection]
<electrical>
headius: no issues found so far with jruby9k
dumdedum has joined #jruby
subbu has joined #jruby
skade has quit [Quit: Computer has gone to sleep.]
drbobbeaty has joined #jruby
noop has quit [Ping timeout: 256 seconds]
subbu has quit [Ping timeout: 244 seconds]
dumdedum has quit [Quit: foo]
benlovell has quit [Ping timeout: 252 seconds]
josh-k_ has quit [Remote host closed the connection]
benlovell has joined #jruby
josh-k has joined #jruby
josh-k has quit [Ping timeout: 244 seconds]
benlovell has quit [Ping timeout: 264 seconds]
mister_solo has quit [Ping timeout: 252 seconds]
benlovell has joined #jruby
skade has joined #jruby
mister_solo has joined #jruby
benlovell has quit [Ping timeout: 240 seconds]
nerdy has quit [Quit: Computer has gone to sleep.]
nirvdrum has joined #jruby
JohnBat26 has joined #jruby
brettporter has quit [Remote host closed the connection]
claudiuinberlin has joined #jruby
bbrowning_away is now known as bbrowning
yfeldblu_ has quit [Remote host closed the connection]
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] mkristian pushed 1 new commit to jruby-1_7: http://git.io/gtEBlQ
<JRubyGithub>
jruby/jruby-1_7 76a514e Christian Meier: expand path before adding it to the $CLASSPATH variable...
JRubyGithub has left #jruby [#jruby]
deobalds has quit [Quit: Computer has gone to sleep.]
kwando has joined #jruby
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] chrisseaton pushed 1 new commit to truffle-head: http://git.io/B6b36Q
<JRubyGithub>
jruby/truffle-head e5247d3 Chris Seaton: [Truffle] Store object_id as a dynamic object field so it doesn't take up any space unless it's set.
JRubyGithub has left #jruby [#jruby]
tcrawley-away is now known as tcrawley
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] mkristian created FileResource.inputStream (+1 new commit): http://git.io/bTPysw
<JRubyGithub>
jruby/FileResource.inputStream 18da34f Christian Meier: refactor FileResource.inputStream to be easier to use...
JRubyGithub has left #jruby [#jruby]
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] mkristian closed issue #2216: $CLASSPATH << 'some/relative/path' does not obey the Dir.pwd http://git.io/GJIatg
<JRubyGithub>
[jruby] mkristian opened pull request #2271: refactor FileResource.inputStream to be easier to use (jruby-1_7...FileResource.inputStream) http://git.io/Z4zLng
<headius>
I'm working on another PR to give ruby-build the final filename, but need to work with other jrubyists to decide what that filename should be :-)
<headius>
that's great it's working well! there have been literally hundreds of fixes and enhancements since then
<headius>
hopefully we'll get ruby-build sorted out today
<electrical>
jruby-9.0.0.0-dev is now in rbenv. most likely need to replace it
<electrical>
oh no. it automatically translates it back
<electrical>
yay :-)
<headius>
yeah, I changed the version number before RubyConf, and then another change made it into 9.0.0.0-SNAPSHOT to align better with typical Java apps
<headius>
yeah that doesn't look like the right trace
<headius>
hmm
Aethenelle_ has joined #jruby
<electrical>
only prints out $!.to_s
<electrical>
may need to print out something else?
<headius>
try passing -d
<headius>
to JRuby
<headius>
JRUBY_OPTS or command line
<electrical>
okay
Aethenelle has quit [Ping timeout: 264 seconds]
Aethenelle_ is now known as Aethenelle
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] mkristian force-pushed redefine-uri-classloader-meaning from ee8966d to 99ff77d: http://git.io/cwP5fQ
<JRubyGithub>
jruby/redefine-uri-classloader-meaning 99ff77d Christian Meier: add testcase for the case where jruby.home is inside a jar but not on the context-classloader
<JRubyGithub>
jruby/redefine-uri-classloader-meaning b672b80 Christian Meier: redefine uri:classloader: meaning to be the parent classloader of runtime.getJRubyClassLoader...
<rtyler>
headius: would you and enebo object to a "1.7.x" label in GH issues? that way I can start going through and tagging everything that's been reported against that branch?
<mkristian>
dfr|work, ping
<dfr|work>
mkristian, pong
noop has joined #jruby
<mkristian>
dfr|work, could have a look at https://github.com/jruby/jruby/pull/2271 - would be great to this or similar for jruby-1.7.17 so we can use it for the next jruby-openssl release
phrinx_ has quit [Remote host closed the connection]
<JRubyGithub>
[jruby] electrical opened issue #2272: [Jruby-9k] Java::JavaLang::StackOverflowError when running bundle install http://git.io/9weCjg
JRubyGithub has left #jruby [#jruby]
mister_solo has quit [Ping timeout: 252 seconds]
yfeldblum has quit [Ping timeout: 264 seconds]
<rtyler>
I don't want to add to te problem :P
mitchellhenke has quit [Quit: Computer has gone to sleep.]
mitchellhenke has joined #jruby
<headius>
rtyler: no, it would be really, really nice to know the 1.7 bugs
<headius>
I would expect most are 1.7, but that will change really fast after 9k is out
<nirvdrum>
A lot are probably both.
<headius>
I wish GH issues had a "reported against milestone" field
<enebo>
rtyler: yeah excellent 1.7 vs 2.2+ would be the two cleaving lines
<headius>
nirvdrum: I figure all 1.7 issues are 9k issues until proven otherwise
<nirvdrum>
Easy enough.
<enebo>
headius: true but once we know it is 2.2 specific it would be nice to mark it that way and I think you did make a label for that already
<enebo>
we just don’t have a 17 product-like label
deobalds has joined #jruby
<uberjar>
does anyone know how to enable the Java Security Manager from the command line with JRuby?
<headius>
yeah we have a 2.0-2.2 label
<headius>
rtyler: go for it
<uberjar>
is it as simple as this? JRUBY_OPTS=-Xjava.security.manager=true
<headius>
enebo, rtyler: make the label "JRuby 1.7.x"?
<headius>
I will probably change the Ruby compat labels to indicate they're compat levels
kelcecil has joined #jruby
<enebo>
headius: maybe even 17 since it means nothing
<enebo>
in the ruby semantic sense
<nirvdrum>
headius: I haven't gotten a chance to look at it yet, but I didn't want it to be forgotten -- potentially backporting that thread/queue fix to 1.7.
<headius>
github really needs to add user-defined tags
<headius>
I want them all over the place
<headius>
nirvdrum: oh yes
<headius>
I'm doing 1.7 today and that sounds like something I can do before lunch, so I'll take it
<enebo>
headius: rtyler: I saw 17 since it is our codeword! no seriously the labels right now are horizontally displayed on webpage so smaller is better
<enebo>
saw==wtf was I saying
<enebo>
think perhaps?
<enebo>
smaller label names display better on issues page
<headius>
jruby-1.7
<Aethenelle>
rtyler: can you also tag the FFI bugs too? IIRC, there's a bunch in there but aren't tagged.
<enebo>
ok I guess I don’t care. jruby-1.7 may be more clear to a new person
<headius>
I thought of that because it's similar to the branch
<enebo>
yeah it makes sense. I only argued for 17 since it is 2 chars
<headius>
let's do jruby-1.7 and debate it again in a year
<nirvdrum>
When you just close them all out? :-P
<headius>
nirvdrum: EOL!
<headius>
rtyler: if you have minions to help confirm bugs, there's shit going back ten years we'd like to ditch :-)
triple_b has joined #jruby
<rtyler>
label made
<headius>
I do hate closing old bugs but maybe we should say anything with no activity since 2012 gets closed
<Aethenelle>
rtyler: also any of the FFI bugs will be both 1.7 and 2.2+ currently
<headius>
that would include everything in our old JIRA
<rtyler>
mkristian: please use the 'JRuby 1.7.x' label for 1.7 bugs you're working in
<rtyler>
I'll go through and triage more things tonight
<headius>
"only" 500 or so open issues there
<rtyler>
heh
<Aethenelle>
JIRA-4683 confirmed
<headius>
hahah
<Aethenelle>
I'll poke through more later
<Aethenelle>
confirmed still valid that is...
<rtyler>
JIRA, old schooooool
<headius>
I started with lowest number and saw a dozen that are no longer valid
<headius>
it's going to be 90% dreck
<rtyler>
HOORAY DRECK!
<Aethenelle>
4082 can be closed
<lopex>
141!
<headius>
now I have to remember my codehaus login
benlovell has joined #jruby
<Aethenelle>
3996 valid
<Aethenelle>
... i should actually work...
<Aethenelle>
headius: why not just move the valid ones to GH?
<headius>
I have done that for some
<headius>
it just adds old bugs as new ones
<headius>
use best judgment if you want to move some over
Hobogrammer has joined #jruby
<headius>
we don't actively mine jira for work anymore
<uberjar>
Hi. I can't seem to get JRuby to work with the Java Security Manager. I have a policy file in /root/java.policy that does not grant any socket permissions at all.. then I try the following:
monkstone has quit [Remote host closed the connection]
bbrowning_away is now known as bbrowning
Aethenelle has quit [Ping timeout: 258 seconds]
brettporter has joined #jruby
Aethenelle has joined #jruby
mitchellhenke has quit [Quit: Computer has gone to sleep.]
tvon has joined #jruby
<tvon>
Does jruby search for ssl certificates in a different place than MRI might? I'm using ruby-build/chruby and while any MRI ruby will work (for our local https gem server), jruby fails to verify the cert.
erikhatcher has quit [Quit: erikhatcher]
kgerman has quit [Remote host closed the connection]
<tvon>
rbx works as well
<nirvdrum>
tvon: It follows the JVM rules. So, it uses a keystore.
tcrawley-away is now known as tcrawley
* tvon
nods
<nirvdrum>
Specifically, it doesn't do whatever OpenSSL does.
<tvon>
Okay, thanks
triple_b has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<nirvdrum>
It's not an issue for the core root certs. But if you need a custom cert, it's annoying.
<uberjar>
speaking of Jruby security.. I'm curious as to why the JRuby community isn't more vocal about how powerful the Java Security Management sandboxing stuff is..
<uberjar>
I'm only starting to learn about it, but I think it kicks serious ass so far..
Aethenelle has quit [Ping timeout: 252 seconds]
<uberjar>
nooobody on the web talks about it though in the context of JRuby.. but my Rails app now feels a thousand times more secure thanks to it
Aethenelle has joined #jruby
<uberjar>
</rant>
<tvon>
get em!
<uberjar>
I might have to make a blog post about fine grained access controls and whitelisting and how it can make rails apps more secure
<uberjar>
if so I'll drop a link in here
<uberjar>
discoveirng this thing even existed is like xmas day :)
<tvon>
I'd read it
<Aethenelle>
uberjar: i think it's assumed jruby devs know something about Java so they'd know to use the sandbox controls if it would help them. Also, if your rails app requires the java sandbox for security, it's not portable to any other ruby implementation.
<Aethenelle>
i think most of the java web apps I've seen either use the default settings or set them wide open
<uberjar>
Aethenelle: yeah.. I suppose thats my point.. the java community knows about it but the rails community largely does not.. but should (imho). I agree it's bad to make your app *depend* on it, but it's a great way to harden any existing application
<Aethenelle>
i'd have to look into it but I suspect the security manager controls you'd normally have to worry about are likely covered by ruby or file system acces controls.
<uberjar>
it prevents a whole class of vulnerabilities.. what it boils down to is whitelisting only the resources your app uses is way more secure than thinking you can blacklist all the "bad stuff" that can happen on your unix box via filesystem permissions
<uberjar>
well.. not all are covered by filesystem access controls
<uberjar>
an attacker who gains control of a thread of execution in yoru rails app could load a trojan into memory without touching the filesystem and then it could "connect back" home (reverse shell)
<uberjar>
the Java Security Manager lets you say "the JVM can only open socket connections to these handful of whitelisted domains"
<uberjar>
which prevents the attacker from being able to "phone home" with an in-memory shellcode
<Aethenelle>
uberjar: that doesn't prevent me from utilizing your resources or messing up your application
<uberjar>
I suspect that even int he java community not enough people know about this stuff
<Aethenelle>
code execution is still bad regardless of how it's locked down.
<uberjar>
very true!
skade has joined #jruby
<uberjar>
and the attacker coudl always try to ferret information back out using the request cycle itself
<Aethenelle>
uberjar: i think it's well known enough jst seldom used because it's quite incomplete
<Aethenelle>
uberjar: yup, i've done that before (legally, under contract) myself
<uberjar>
Aethenelle: thats why you need fail2ban and other stuff listening for that kind of HTTP abuse
<Aethenelle>
your best defense against that sort of thing is making sure your data is always only data, never code (of any sort)
<Aethenelle>
rails does a great job of this wrt xss
bbrowning is now known as bbrowning_away
<uberjar>
yeah.. but I still worry that there may be remote exploits out there in the wild against the framework itself
<Aethenelle>
uberjar: IDS is a word of pain
<uberjar>
I think it's unlikely but these things could be a reality
<uberjar>
having your JVM nicely sandboxed makes it much more difficult for bad guys and dosnt' take that much work
<uberjar>
to achieve the same sort of egress filtering to prevent reverse-shells without it.. you'd need to get a reverse proxy involved.. firewal rules alone can't do it
<uberjar>
bleh I dunno.. I'm just suggestinging that this thing works
<uberjar>
and is something to brag about
<uberjar>
for the jruby community
<uberjar>
I write it up and we'll see how it goes
<uberjar>
maybe some real heavy duty rails security nerds will shoot it down
<Aethenelle>
uberjar: true... true... another layer isn't all that bad if it's used right...
<uberjar>
but then I'll learn somethign
<Aethenelle>
nah... rails doesn't do much past xss and sqli prevention...
<Aethenelle>
in general i worry about solutions like "we'll just put a waf in front of it" ... a waf can only do so much and the update cycles tend to be long (especially for enterprise wafs)
tcrawley is now known as tcrawley-away
<Aethenelle>
w/ the security manager it's more a worry about lazyness.. if it's developed to rely on the security manager, it'll be secure enough... until someone runs it under MRI or rbx
<uberjar>
Aethenelle: yea I agree on both fronts.. I suspect both IDS and security manager could end up being excuses to be lazy if you're not careful..
<Aethenelle>
so i guess devs working on a single app that won't be released publicly could use it safely-ish because they're unlikely to move away from JRuby (or any platform really) all that often or at all... anyone writing a framework should just stick to doing it right in code...
<Aethenelle>
hopefully your post will outrank stuff like jruby-sandbox quickly for that sort of thing.
<uberjar>
every programmer gets sloppy eventually a makes a mistake though... I'd rather have that extra protection.. knowing that my code *cant* do bad things
<uberjar>
and it's not really as diffciutl to setup as you'd think it just has kinda crappy documentation. I see this a big advantage over other Ruby implementations personally
<uberjar>
oh I didn't even know about jruby-sandbox
<Aethenelle>
it is certainly an advantage
<uberjar>
I'll take a peek thnx
<Aethenelle>
uberjar: do not use jruby-sandbox
<Aethenelle>
there's a reason _why stopped working on ruby-sandbox
<Aethenelle>
adding Java to the mix doesn't improve the situation
<uberjar>
hrm.. I bet I could wrap this java security manager thing in a ruby DSL and package it as a gem and then people might find it easier to use
<uberjar>
that might be a more efficent use of time than blogging.. hrmm
<uberjar>
I mean a ruby DSL to generate the config for it
<uberjar>
if I go down that route I'll drop a link in here too
DomKM has joined #jruby
<tvon>
On the ssl cert subject, if I run "${JAVA_HOME}/bin/keytool -list -alias myalias.com" and my key is listed, then bundler should be happy?
brettporter has quit [Remote host closed the connection]