Found another one: GLSL Studio. It came out yesterday.
Edit: I just noticed they have Code Export, via Document sharing in iTunes. It will be interesting to see if apple cares about sharing GLSL code.
Sharing GLSL code is significantly more of a security risk, given that your code is compiled and run directly on the hardware and can potentially violate the sandbox.
Haha. Things are looking up for Codea iTunes project sharing… or not…
@Simeon - I don’t agree, but I’m open to the argument - can you cite a case of GLSL actually being used to expoit a system in the real world? Or even in theory in literature? I’ve been unable to find one. But I can find TONS of examples of a general purpose language like Lua (and javascript and C and every other one, really) being used to get around security.
Google’s NACL basically runs at the raw hardware level - and yet is one of the most demonstrably secure sandboxes to date. Closeness to hardware doesn’t make things less secure, necessarily.
More to the point - GLSL and it’s C-like syntax do not compile down into a machine code - they’re compiled by the GL drivers from the GPU’s manufacturer into instructions for their cards, which are interpreted by the low level hardware running a local machine code (in other words, as I understand it, internally they’re a p-code or virtual machine - there is, in effect an OS and hypervisor running that deals with things like distributing work and arbitrating access to the bus and so on). And given the cards themselves don’t have access to main memory, or filesystems… I don’t see how any program could “get out of the sandbox” - the sandbox is the GPU or graphics card. Presumably, an exploit would have to be against the systems getting the GLSL to the GPU - the OS graphics drivers - and presumably those are open to abuse the same as any other system service, ie. no added risk.
Could malicious GLSL hose your video, forcing a reboot (or restart of the video at least)? Of course - hell, I do it accidentally. But being able to make something break doesn’t imply you can exploit a security hole.
I don’t know enough about the hardware to say, but it just seems that with a shared-memory video system any possible exploit in the shader hardware might be able to bypass memory protection.
One of the reasons Firefox was (and is) hesitant to adopt WebGL is due to security issues. I don’t know whether there’s any merit to them, but some are detailed here: http://www.contextis.co.uk/resources/blog/webgl/
Those security concerns, from what I understand, are from attacks on the GLSL and WebGL drivers - not security concerns from within. Yes - that a weird fine line. I think the key point is that until recently (webgl), there was no real potential for outside code to get to poke at the video card drivers at that level (again, at the “load some GLSL” stuff, not when executing it, because the stuff executing it is fairly removed from the system), and so the drivers had virtually no real hardening - they were an easy target.
And - that may still be the case in iOS - I note mobile safari does not have WebGL yet, and you can bet Apple is both looking at doing it, and aware of the issues the PC browsers have had.
Point being - I’ll worry for real about something being a security threat when I hear of someone in the real world, researcher or otherwise, actually suggesting (or demonstrating) that it’s plausible. I don’t see anyone, ever, using GLSL code to exploit anything. Attacks against the drivers are just regular machine code attacks - a buffer overflow on the GLSL compiler in the driver or such - that happen on the regular old CPU). Doesn’t mean Apple isn’t susceptible, but I’d wager their attack surface is way reduced, and they are approving apps that do GLSL, as we’ve seen. (I want to try the new one, but TWO BUCKS!!! highway robbery. 
)
Just to make it clear, I’m not worried about the security issues of GLSL or WebGL. I think they’re fine. But I think that Apple could be (and I might be if I was in Apple’s position).
We see 3 apps that do GLSL approved in the last few weeks (I lie - I don’t know how long paragraf’s been there). So - they seem to get by.
From a security engineering standpoint (and that’s a lot of what I do ‘for reals’, which is why I argue about it, not that I need an excuse), setting aside my desire to see GLSL, I see this as significantly less a threat than Codea itself. So it seems unlikely Apple will, either.
Having said that - show me one exploit, even theoretical, and I reserve the right to change my mind.
I sort of hesitate discussing the issues because one has to be careful about giving people ideas.
I think I can explain it in a way that is of no pratical use but gets the point across.
Two avenues of exploits off the top of my head are firmware access and cache and transfer.
Everything has firmware and it is meant to be upgraded. Just about anything can be told to respond to the rest of the system as if it was something that it isn’t. It doesn’t matter what the current iteration of GSGL does, it matters if it will ever have the addition of some kind of cross platform firmware access. At that point it crosses a line into chaos and a target for ultra coordinated MFery. (FYI any motherboard on a server with built in video is an accident waiting to happen, btw this is most of them, servers should emulate video not have a real one)
For cache and transfer it’s best to start by talking history. In the days of yore CRTs by their physics alone broadcasted what they displayed omnidirectionally. You had to be close and it would be blurry but you could read screen over the air though a (unshelled) wall. Video memory is meant to be shared for speed, it’s a gap in and of itself. You cache what you see and you store it for later distribution. But all that is dependent on compromising other components so it really a secondary issue. It’s like “someone could steal our passwords” (right after they broke down the front door and don’t need them).
Mmmm… a stretch, at best. The first talks about an imaginary vulnerability, maybe, someday. The second is a data leak, not a security exploit in the sense we’re using here (or, to put it another way, the second one is exploitable even if we don’t have GLSL access).
I keep coming back to exposure - we’re talking about bolting the 3rd deadbolt on the upstairs attic window, when the garage door is wide open, comparatively. We’re talking about maybe someday exploitable stuff in a hugely limited language, sitting on top of a full blown general computing language on a platform that’s been jailbroken (and so is presumably vulnerable to reverse engineering of exploits). If I can compromise the base OS - I can do whatever GLSL I want.
I think the chances of GLSL exposing a vulnerability of any real consequence that was not exposed in some other manner (ie. by virtue of running on the GPU) is about as close to “vanishingly small” as you are going to find in the real world. And as always - open to other evidence (or speculation…)
(I always assume the people smart enough to exploit already know what I’m going to say - but I understand, I keep dancing around the things I could do with sockets. Crazy powerful also means potential for abuse…)
Hi! I created GLSL Studio, found this page while google-stalking “GLSL Studio” and figured I’d jump in to let you know some of what I dealt with in getting approved. 
I submitted around mid December last year and got approved 2 days ago. I got rejected twice for the usual “external code” then took it to the appeals board who finally approved. Where this is relevant is that I am only allowed to export - iTunes File Sharing is enabled but only one way - any kind of import (i.e. “downloading code”) is still forbidden.
This is really unfortunate since sharing of files would be a huge benefit to everyone and I also agree that GLSL is probably the least likely point of entry for any exploit. That said, I totally understand their caution. I’m hoping that at some point in the future they will relax this stance a little, or at the very least treat things on a case by case basis (which it looks like they may be since they’ve let apps like Codea + GLSL Studio into the store).
@kode80 - welcome! Heh - I sprung the 2 bucks last night, had to poke your app and see what I could see.
You’re really in the same boat here as Codea is - I notice I can cut and paste into your app, so there’s the “back door” import right there.
I can tell you from experience that when you can simply import the file, as opposed to making a new project and cutting and pasting, the end-user experience is entirely different. To be blunt, Apple’s text selection specifically does a poor job of allowing users to easily select a chunk of code to copy and paste - there are a million things common done on web sites (including github!) that break it. When it’s just ‘click on this in mobile safari and choose import to your app’, you’ll see a ton more activity and sharing with your users.
Apple’s policy does nothing but put a fig leaf over security, but it puts a serious hurt on ease of use.
@kode80 interesting! I’m glad you were able to sort out your issues with the appeals board.
We had similar one-way file sharing through iTunes but were rejected due to “downloadable code,” as well. Even though, as you say, it’s not downloading because it can’t import code into the app.
@Simeon wow, sorry to hear that. If it’s only exporting there’s no way that could be interpreted as “downloading code” I’d take that to appeal, my experience definitely renewed my confidence in the reviews process somewhat.
Alright. Now that I’ve seen what you can do with GLSL like making 3D objects, I REALLY want it in Codea. Now another suggestion for sharing code: Will apple allow it if you just export the project as a zipped .txt files (and sprites when you get to it?) It’s normal file types and anybody could read it. Or how about adding a feature that when you create a new project or class/blank page, it gives you an option to import from clipboard.
Getting his app soon to try it out.
Nice that you like my old app Paragraf! Hopefully Codea will replace the need for it with the next release. Then it’s just an iPhone version that’s missing.