3 ms·

MacRuby 0.7 is released

41 points by Zev 16y ago

ROFISH 16y ago
Why would "Sandbox" functionality need to be first-class implemented in any Ruby? Perhaps a version of Ruby that will run on the iPhone where some carrier's rules could include "No free apps can use cellular internet access". Let AT&T dig their own grave.
- Zev 16y ago
  ...limit potential damage that can happen if a vulnerability is exploited. Security aspects are a much more likely reason for using sandboxing than carriers complaining is. Plus, sandbox is already available from C -- see: `man 7 sandbox`. Anyway, I imagine tptacek (or anyone who knows more about security than I do) can explain this better than I can, but, I'll give it a shot: In limiting your process, you're preventing an unknown state from happening within your process. Its another level of control that you can use to ensure that your program will only do what you programmed it to do and that it can't do anything else. One part of how this sandboxing works is that any process spawned will also be contained within the sandbox. So, say there is a vulnerability -- in your code, in a gem you use, whatever -- the point is, there is a vulnerability. Maybe it will give an evil nasty person remote access to your system, or perhaps a local user can use it to gain privileges that they shouldn't have. Or something else that I'm not thinking of. Anyway, as a result of a vulnerability, the user now has access to your system. Or maybe they have more access than they should. You can use Sandbox to forcibly limit how much access a process and child processes can have. You can make it so that a process can't write to any directory except the temporary directory that it uses and block access to the internet. Make it harder for the evil nasty person to break, steal or otherwise continue doing things that they shouldn't be doing. // edit: to summarize: No matter how safe your Ruby code happens to be, if you use an unsafe C extension, you're screwed if you're not using sandbox(7).
  - ROFISH 16y ago
    Not that extra security is bad for your gems, but I was more or less insinuating iPhone support since that's what I really want. ;)
pkaler 16y ago
I think my postulating from a few months ago is becoming closer to reality. http://parveenkaler.com/2010/06/30/could-ruby-be-apples-language-and-api-future-3/ http://parveenkaler.com/2010/06/30/could-ruby-be-apples-lang... The release notes mention that there has been work on static Ruby compilation as well as well as fixes for clang/llvm. The one weakness on Apple's platform is that they don't have the rich, language-agnostic runtime and a modern language to match Microsoft like .NET/C#. And Google is building on top of the JVM. I think the future Apple stack looks like: Objective-C & Ruby ---- Language-agnostic runtime (Grand Central Dispatch, Blocks, etc) ---- CLANG ---- LLVM ---- Unix (iOS or OS X)
- frou_dh 16y ago
  You'd hope so. Objective-C remaining the only option this decade seems nuts.
  - pkaler 16y ago
    Garbage collection was added in 2.0, boilerplate properties code can be removed with the latest LLVM/CLang, and it's message passing rather than method calling. Add namespaces and remove the .h/.m split and I'd argue it was a better language than C# or Java. And the spec is less than 135 pages long. The Java spec is 650 pages. The C# spec is 530 pages. http://developer.apple.com/library/mac/#documentation/cocoa/conceptual/ObjectiveC/ObjC.pdf http://developer.apple.com/library/mac/#documentation/cocoa/... http://java.sun.com/docs/books/jls/download/langspec-3.0.pdf http://java.sun.com/docs/books/jls/download/langspec-3.0.pdf http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-334.pdf http://www.ecma-international.org/publications/files/ECMA-ST... To be fair the Java and C# specs are written in a terse but exhaustive manner because standards bodies are the main audience. But it still says something about the conciseness of the languages.
    - frou_dh 16y ago
      But it's forever a superset of C. Not a bad thing, but that shouldn't be the only option.
    - 16y ago

41 points by Zev 16y ago

Why would "Sandbox" functionality need to be first-class implemented in any Ruby? Perhaps a version of Ruby that will run on the iPhone where some carrier's rules could include "No free apps can use cellular internet access". Let AT&T dig their own grave.

Zev 16y ago
...limit potential damage that can happen if a vulnerability is exploited. Security aspects are a much more likely reason for using sandboxing than carriers complaining is. Plus, sandbox is already available from C -- see: `man 7 sandbox`. Anyway, I imagine tptacek (or anyone who knows more about security than I do) can explain this better than I can, but, I'll give it a shot: In limiting your process, you're preventing an unknown state from happening within your process. Its another level of control that you can use to ensure that your program will only do what you programmed it to do and that it can't do anything else. One part of how this sandboxing works is that any process spawned will also be contained within the sandbox. So, say there is a vulnerability -- in your code, in a gem you use, whatever -- the point is, there is a vulnerability. Maybe it will give an evil nasty person remote access to your system, or perhaps a local user can use it to gain privileges that they shouldn't have. Or something else that I'm not thinking of. Anyway, as a result of a vulnerability, the user now has access to your system. Or maybe they have more access than they should. You can use Sandbox to forcibly limit how much access a process and child processes can have. You can make it so that a process can't write to any directory except the temporary directory that it uses and block access to the internet. Make it harder for the evil nasty person to break, steal or otherwise continue doing things that they shouldn't be doing. // edit: to summarize: No matter how safe your Ruby code happens to be, if you use an unsafe C extension, you're screwed if you're not using sandbox(7).
- ROFISH 16y ago
  Not that extra security is bad for your gems, but I was more or less insinuating iPhone support since that's what I really want. ;)

pkaler 16y ago

I think my postulating from a few months ago is becoming closer to reality. http://parveenkaler.com/2010/06/30/could-ruby-be-apples-language-and-api-future-3/ http://parveenkaler.com/2010/06/30/could-ruby-be-apples-lang... The release notes mention that there has been work on static Ruby compilation as well as well as fixes for clang/llvm. The one weakness on Apple's platform is that they don't have the rich, language-agnostic runtime and a modern language to match Microsoft like .NET/C#. And Google is building on top of the JVM. I think the future Apple stack looks like: Objective-C & Ruby ---- Language-agnostic runtime (Grand Central Dispatch, Blocks, etc) ---- CLANG ---- LLVM ---- Unix (iOS or OS X)

frou_dh 16y ago
You'd hope so. Objective-C remaining the only option this decade seems nuts.
- pkaler 16y ago
  Garbage collection was added in 2.0, boilerplate properties code can be removed with the latest LLVM/CLang, and it's message passing rather than method calling. Add namespaces and remove the .h/.m split and I'd argue it was a better language than C# or Java. And the spec is less than 135 pages long. The Java spec is 650 pages. The C# spec is 530 pages. http://developer.apple.com/library/mac/#documentation/cocoa/conceptual/ObjectiveC/ObjC.pdf http://developer.apple.com/library/mac/#documentation/cocoa/... http://java.sun.com/docs/books/jls/download/langspec-3.0.pdf http://java.sun.com/docs/books/jls/download/langspec-3.0.pdf http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-334.pdf http://www.ecma-international.org/publications/files/ECMA-ST... To be fair the Java and C# specs are written in a terse but exhaustive manner because standards bodies are the main audience. But it still says something about the conciseness of the languages.
  - frou_dh 16y ago
    But it's forever a superset of C. Not a bad thing, but that shouldn't be the only option.
  - 16y ago