umm, no, not automagically. the playground is restricted. it would require some work to be put in to make it work with the latest release. that work isn't available for free.
Maybe I'm stupid and just always make stupid comments, but I think the attitude you displayed with your "umm, no" is way too common around here. Is it too hard for you to not be condescending when making a counter argument?
Edit: After re-reading both my comment and yours, I'm not sure if you were using the "umm, no" innocently in response to the `(Or is there?)` at the end of my sentence, or if you were trying to say it in a condescending way. I'll give you the benefit of the doubt and assume it was the former. I'm not trying to be one of those SJW people who gets offended at any little thing.
Regarding the rest of your comment:
> the playground is restricted
What exactly do you mean by that?
> automagically
And that?
I'm referring to large RCs like this. I think a lot of people want to test out new features/changes without pulling the latest version to their machine right away.
That work is going to have to be done anyway before the final release, right? And I can't really imagine it would be a lot of work, I would think _maybe_ a few things would break, but otherwise it should work?
And if you think I mean to have the normal `play.golang.org` start using the latest RC, that's not what I mean - I would imagine it would either be on a separate subdomain, like `play.beta.golang.org`. Or, have a dropdown on the main Playground, but that might be potentially confusing?
The Playground is a very special build of Go. I don't even think it's open sourced, often because while you can't depend on security-by-obscurity you still don't necessarily want to just hand people the source to attack on their own. It's written to prevent people from abusing the playground, so for instance, the os package can't read real files, the time package returns constants for "time.Now()" rather than using the clock, and an arbitrary number of other changes are made to prevent abuse. How many changes it is I don't know exactly, but there's certainly a number of them. But, more importantly, the QA work for such a thing is quite substantial. Many of the changes would also preclude using the playground to investigate the new features; for instance, you can't test HTTP2 support on there since you can't open sockets or servers. Presumably updating it would require significant effort, and at the very least, it can't be afforded to make that a blocker for a release.
I did know it was restricted, I guess I just underestimated how difficult that is to do. I didn't think the restrictions were actually implemented in the Go source, I thought it was more a locked down container plus a few restrictions implemented externally in the Playground's server code. It would be cool to know more about this, maybe I'll take a look at the source as @arjovr linked.
Thanks!
It's not. It uses NaCl (native client), but that's just a special GOOS/GOARCH pair with a supporting runtime. NaCl is what the chrome sandbox is based upon, it's cool technology :)
> It would be cool to know more about this, maybe I'll take a look at the source as @arjovr linked.
You can also start here: https://blog.golang.org/playground
Rust has two playgrounds (official: https://play.rust-lang.org/, unofficial: http://play.integer32.com/), and each is a completely different bit of open-source software (https://github.com/rust-lang/rust-playpen , https://github.com/integer32llc/rust-playground)
They both use docker for isolation, with a bunch of things to make it work. IIRC we haven't had any issues with this. Furthermore, the official playground used to be a third completely different bit of software until it was rewritten in Rust. It also used to use https://github.com/thestinger/playpen.
I'm skeptical that the problem will take that much effort since Rust has solved it (to some degree) twice.
At the same time, it's likely that Go's playpen does a lot more mitigation, e.g. the time.Now() probably futzes timing attacks. Though in that case they would need to mess with mutexes or scheduling as well (since you can use shared memory to build a timer), which complicates things.
(For timing attacks I still think the solution still lies in how you set up the container, specifically isolating its memory accesses -- instead of tweaking the compiler itself)
Im pretty sure the source code is available somewhere, though usage isn't very well documented. There's periodic requests on golang-nuts about how to get your own version up and running.
Looks like the reason the time functionality is restricted is to avoid DOSes and server load, not to prevent against side channel attacks (which like I said are possible anyway with mutexes and channels).
The rest could be pretty easily implemented via docker or some other sandboxing method (the time stuff sort of can be handled too, but it's trickier). It might be more vulnerable to load, but it will be able to work with a pristine Go toolchain and provide options like switching between versions; much like the Rust playground.
https://github.com/ethereum/go-ethereum/blob/master/p2p/disc...
Docker isn't really meant as a security mechanism. Among other things, you still expose the full kernel API as an attack surface. I can't imagine that they only use Docker, at the very least they'll probably have some dedicated machines for the playgrounds. Even then, this is probably not a great idea.
The playground uses NaCl (and AFAIK that includes seccomp), restricting both the instructions that you can use and the set of system calls that you can make (basically just read/write on fds 0-3 and exit). It's what chromes sandbox is based upon.
There are a couple of implications from this (most are described in the blog post linked elsewhere), e.g. that time is faked and that playground-code runs single-threaded. A great consequence, though, is that playground code is 100% deterministic, meaning it can be cached (and it is cached pretty aggressively), reducing the load for popular snippets.
IIRC they're on their own dedicated instances.
But now, this user has been heavily downvoted, which is aggressive, without any doubt. I really wish downvote features were out of the web, this is just group bullying. Upvoting is plenty enough to make good contributions raise above the others.
I hope you understand at least why I thought that. :)