Hi all –
I’ve created a site called ruby-versions.net, on which I’m giving out
shell accounts. The site gives you command-line access to Ruby
versions dating back to 1.0, and several modern Ruby interpreters
inclusing JRuby, Rubinius, and Ruby Enterprise Edition (as well as MRI
1.8.6, 1.8.7, 1.9.1, and development snapshots).
To get a shell account, please start by reading
http://ruby-versions.net, and use the link there to email me. That
will help me semi-automate the process.
ruby-versions.net is an EC2 instance, which means it’s potentially a
bit volatile… I haven’t decided how aggressively to back stuff up.
Please treat it as a place to try things out, learn about Ruby
history, compare versions and implementations – but not as a
development platform or a place from which to operate Internet
services.
Have fun!
David
Sigh. ruby-versions.net has apparently decided to stop resolving.
(It’s attached to an AWS Elastic IP address.) Stay tuned. I’ll see
what I can do.
David
All I can say is: try it, and if it doesn’t connect, try again.
Apparently Amazon Elastic IP, with which this is my first experience,
is flakier than one might wish (at least judging by the “Data error”
indication in the AWS console that I was seeing).
David
On 11 Jul 2009, at 14:42, David A. Black wrote:
All I can say is: try it, and if it doesn’t connect, try again.
Apparently Amazon Elastic IP, with which this is my first experience,
is flakier than one might wish (at least judging by the “Data error”
indication in the AWS console that I was seeing).
If you need a fast-switching dynamic DNS provider I can recommend
afraid.freedns.org - it’s free and very stable.
Ellie
raise ArgumentError unless @reality.responds_to? :reason
On 7/11/09, David A. Black [email protected] wrote:
I’ve created a site called ruby-versions.net, on which I’m giving out
shell accounts. The site gives you command-line access to Ruby
versions dating back to 1.0, and several modern Ruby interpreters
inclusing JRuby, Rubinius, and Ruby Enterprise Edition (as well as MRI
1.8.6, 1.8.7, 1.9.1, and development snapshots).
Wow, this sounds like it will be extremely useful.
I wonder if you could say a word about security, since it’s obviously
a big concern with a service of this type…
On Jul 11, 2009, at 11:10 AM, Caleb C. wrote:
I wonder if you could say a word about security, since it’s obviously
a big concern with a service of this type…
Is it?
I suspect David has the EC2 image saved on S3. If you screw up his
instance he can stop it, load a fresh copy from the S3 image, and move
the elastic IP to point at the new instance.
It’s not like you’ll be stealing his data or breaking into his
computer, right?
James Edward G. II
On 7/11/09, James G. [email protected] wrote:
On Jul 11, 2009, at 11:10 AM, Caleb C. wrote:
I wonder if you could say a word about security, since it’s obviously
a big concern with a service of this type…
Is it?
I suspect David has the EC2 image saved on S3. If you screw up his
instance he can stop it, load a fresh copy from the S3 image, and move
the elastic IP to point at the new instance.
I assumed this was more or less the case, but it’s nice to have it
stated explicitly.
It’s not like you’ll be stealing his data or breaking into his
computer, right?
I think there are still many security issues to consider. What if one
user manages to crack the root account? This attacker can then mess
the service up for other users in many subtle or not-so-subtle ways,
steal passwords, etc. This extra privilege will only last as long as
the current instance is running, but that may be for a good long
while. David may not notice anything wrong and just leave the same
instance running for weeks… Even if he makes it a policy to reboot
just in case periodically, what’s to prevent the attacker from just
reexecuting the same attack against the new instance?
Even without root privs, rogue users can launch attacks on other
systems. Hopefully, there’s a least a log being kept. Better yet would
be to forbid network traffic altogether (other than incoming ssh,
clearly).
On Jul 11, 2009, at 2:18 PM, Caleb C. wrote:
move
the elastic IP to point at the new instance.
I assumed this was more or less the case, but it’s nice to have it
stated explicitly.
Yeah, I’m just worried we’ve gotten into the habit of always over
thinking these security issues.
It’s not like you’ll be stealing his data or breaking into his
computer, right?
I think there are still many security issues to consider. What if one
user manages to crack the root account? This attacker can then mess
the service up for other users in many subtle or not-so-subtle ways,
steal passwords, etc.
So, if you steal my password to David’s service, you can do what
exactly? Log into David’s service that you were obviously already
logged into? I guess you could run Ruby 1.0 as me instead of you.
Are we worried about that?
As for “screwing up” the service, well, I’m not too sure what that
means. Make old Ruby interpreters not run correctly? I guess I assume
the tool is more for curiosity than any reliable testing service, so I
didn’t really feel that was a huge threat. Perhaps there are worse
things they could do that I’m not imagining though.
Even without root privs, rogue users can launch attacks on other
systems. Hopefully, there’s a least a log being kept. Better yet would
be to forbid network traffic altogether (other than incoming ssh,
clearly).
OK, that I can see as a legitimate issue. The box could be used as a
jumping off point in attacking other services. Good point there.
James Edward G. II
Caleb C. wrote:
What if I were to switch the 186 and 187 versions of the interpreter?
That’s subtle enough that it might not get noticed for a while. But it
sure could cause confusion. Maybe not a huge issue, but it would sure
be annoying.
pets persian cat Mwa ha ha ha!
On 7/11/09, James G. [email protected] wrote:
So, if you steal my password to David’s service, you can do what
exactly? Log into David’s service that you were obviously already
logged into? I guess you could run Ruby 1.0 as me instead of you.
Are we worried about that?
I could launch my spam relay (or whatever malware) from your account,
that way when the spam cops come knocking you get the blame and I
still have the chance to steal someone else’s password.
As for “screwing up” the service, well, I’m not too sure what that
means. Make old Ruby interpreters not run correctly? I guess I assume
What if I were to switch the 186 and 187 versions of the interpreter?
That’s subtle enough that it might not get noticed for a while. But it
sure could cause confusion. Maybe not a huge issue, but it would sure
be annoying.
On Saturday 11 July 2009 03:02:36 pm James G. wrote:
Yeah, I’m just worried we’ve gotten into the habit of always over
thinking these security issues.
Maybe. Shouldn’t be hard to figure it out, though.
So, if you steal my password to David’s service, you can do what
exactly? Log into David’s service that you were obviously already
logged into?
Most people tend to use the same password on multiple services.
Those who don’t should hopefully be smart enough to use ssh keys instead
of
passwords for a service like this.
I guess you could run Ruby 1.0 as me instead of you.
Are we worried about that?
Well, or take whatever code I’m working on. Or launch attacks on other
services, or take keys I’ve left to other services.
As for “screwing up” the service, well, I’m not too sure what that
means. Make old Ruby interpreters not run correctly?
rm -rf /
I’m also not sure if this is still an issue, but at one point, it was
possible
to feed control characters back through an SSH session and at the very
least
screw up someone’s terminal. I wouldn’t be surprised if it was possible
to
actually compromise the connecting machine.
Of course, these concerns are already there anyway, but it’s generally
safer
to trust one entity (whoever legitimately has root) than it is to trust
many
(whoever might access this service).
On Saturday 11 July 2009 06:35:01 pm James G. wrote:
I also feel like you guys felt this service was for heavy work. I
felt much more that it was for poking around, satisfying historical
curiosities, and trying things out. If you are uploading production
code, my opinion is that you’ve already screwed up.
Makes sense. I wouldn’t upload anything I cared about to Try Ruby,
either.
But, doing this kind of harsh analysis – poking at its security –
helps
establish that it’s for curiosity only, hopefully before anyone uses it
for
heavy work!
On Jul 11, 2009, at 5:44 PM, David M. wrote:
On Saturday 11 July 2009 03:02:36 pm James G. wrote:
So, if you steal my password to David’s service, you can do what
exactly? Log into David’s service that you were obviously already
logged into?
Most people tend to use the same password on multiple services.
Those who don’t should hopefully be smart enough to use ssh keys
instead of passwords for a service like this.
Yeah, I feel like we keep discussing security bugs in the users of
David’s service, not of the service itself. 
I also feel like you guys felt this service was for heavy work. I
felt much more that it was for poking around, satisfying historical
curiosities, and trying things out. If you are uploading production
code, my opinion is that you’ve already screwed up.
Perhaps David could be persuaded to make the AMI he launched the
instance off of publicly available. Then you could just launch your
own instance to avoid these security problems.
James Edward G. II
David A. Black wrote:
Hi all –
I’ve created a site called ruby-versions.net, on which I’m giving out
shell accounts. The site gives you command-line access to Ruby
versions dating back to 1.0, and several modern Ruby interpreters
inclusing JRuby, Rubinius, and Ruby Enterprise Edition (as well as MRI
1.8.6, 1.8.7, 1.9.1, and development snapshots).
Nice.
Might also be nice to have 1.9.0
Something like
http://redmine.ruby-lang.org/issues/show/1560
lists.
Thanks again.
=r
Hi –
On Sun, 12 Jul 2009, David M. wrote:
heavy work!
It is definitely, and explicitly (the website and /etc/motd both say
so), not for long-term or large-scale development. I don’t guarantee
that files will not be deleted. It’s just a place where you can do
some comparisons and learn about the evolution of Ruby.
Let me know if you (anyone) want an account.
David
On Sun, Jul 12, 2009 at 11:04 AM, David A. Black[email protected]
wrote:
some comparisons and learn about the evolution of Ruby.
Let me know if you (anyone) want an account.
Interesting idea, but I find that multiruby serves the purpose for me.
–
Rick DeNatale
Blog: http://talklikeaduck.denhaven2.com/
Twitter: http://twitter.com/RickDeNatale
WWR: http://www.workingwithrails.com/person/9021-rick-denatale
LinkedIn: http://www.linkedin.com/in/rickdenatale
Hi –
On Mon, 13 Jul 2009, Rick DeNatale wrote:
On Sun, Jul 12, 2009 at 11:04 AM, David A. Black[email protected] wrote:
Let me know if you (anyone) want an account.
Interesting idea, but I find that multiruby serves the purpose for me.
I’m sure there will be lots of other people who aren’t interested in
ruby-versions.net, but just so there’s no misunderstanding:
ruby-versions.net and multiruby are very different things, with little
or no overlap in what they’re trying to provide. So interest in
multiruby is not at all likely to be a predictor of lack of interest
in ruby-versions.net 
If you haven’t seen it yet, have a look: http://ruby-versions.net.
David