This doesn't directly impact us, since we don't distribute Racket through the App store, but it's probably something to be aware of. From TidBITS:
**Sandboxing and Privilege Separation** -- Mac OS X has long supported sandboxing — optional mechanisms in the operating system that restrict what an application can do on your system. In recent years, Apple even used sandboxing to better protect some of their more vulnerable applications, like QuickTime. (Video players are notoriously difficult to secure due to all the different encoding methods they need to support and their high performance requirements.) Sandboxing in Lion is improved in two major ways, both of which we first saw in iOS. First are many under-the-hood improvements in sandboxing and much more robust support for applications. Lion supports over two dozen “entitlements,” which are the things an application is allowed to do. Entitlements include functions like writing to the file system (including different entitlements for temporary files), accessing the network, and interacting with hardware like the camera and USB connections. To make this work, developers design and compile their applications for sandboxing and give either an entire application, or different subprocesses, only the minimally required entitlements to work. Should an attacker exploit an application, they are thus restricted to the entitlements that application has, unless they can in some way break out of the sandbox. Ideally, developers break their applications into separate processes, with major components sandboxed to use only minimal entitlements. Called “privilege separation,” this approach provides security controls _inside_ an application. For example, reading PDF files, rendering Web pages, viewing videos, and using browser plug-ins like Flash are all notorious sources of bugs and vulnerabilities. Apple has separated and sandboxed the rendering processes from the core applications for Safari, QuickTime, Preview, and all Safari plug-ins (back with Snow Leopard). Adobe has already sandboxed the Acrobat and Reader applications on Windows, although they haven’t announced plans to do the same for the Mac OS X versions. In QuickTime, when viewing a video file, the rendering engine is sandboxed and restricted from writing files. So an attacker who exploits QuickTime would _also_ need to find a way to break out of the sandbox before they could, for example, install malware on your hard disk. Applications on iOS are heavily sandboxed, but a quick check on my Lion system shows that not a single application I’m running, other than those provided by Apple, uses sandboxing. Even Apple’s own Aperture isn’t sandboxed. This will all change in November 2011 when Apple implements the second major change to sandboxing and _requires_ it for all Mac App Store apps. We don’t know how carefully Apple will review individual sandboxing implementations, but at a minimum all apps submitted to the Mac App Store starting in November will have to enable sandboxing and will be less useful as a launch point for attacks. These sandboxed applications will be able to interact with your Mac only through entitlements. Developers aren’t universally thrilled with this change. Sandboxing is intrusive, and can be difficult to implement on existing code. It will even be impossible to sandbox certain applications that require features for which Apple has not yet designed entitlements. Those applications will still run on Lion, but Apple won’t allow them to be distributed through the Mac App Store, and that in turn may negatively affect sales, given the Mac App Store’s rapidly growing popularity as the source for Mac software. Whole article at: <http://tidbits.com/t/12417> John
smime.p7s
Description: S/MIME cryptographic signature
_________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
