Re: [racket-dev] OS X 10.8 includes new restrictions on running apps
On Feb 22, 2012, at 6:42 PM, Brian Mastenbrook wrote: > "In the middle setting, you can also install applications from identified > developers. This code isn’t reviewed or sandboxed, but it is code-signed to > eliminate the possibility of tampering after the fact. Since Apple Developer > IDs tie back to a registered member of the Apple Developer Program, there is > also some attribution if a malicious application is issued, and, once it has > been discovered, Apple can immediately blacklist that digital certificate to > protect the rest of the user population." It's contracts. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] OS X 10.8 includes new restrictions on running apps
On 02/22/2012 04:25 PM, Norman Gray wrote: All very entertaining, but it doesn't actually answer your question. I'm afraid I can find neither chapter and verse, nor exegesis, which makes it clear what the default will be. Rich Mogull from TidBITS has written an article about Gatekeeper. He's a smart and well-informed guy, so I'd expect his explanation to be accurate. http://tidbits.com/article/12795 "In the middle setting, you can also install applications from identified developers. This code isn’t reviewed or sandboxed, but it is code-signed to eliminate the possibility of tampering after the fact. Since Apple Developer IDs tie back to a registered member of the Apple Developer Program, there is also some attribution if a malicious application is issued, and, once it has been discovered, Apple can immediately blacklist that digital certificate to protect the rest of the user population." -- Brian Mastenbrook br...@mastenbrook.net http://brian.mastenbrook.net/ _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] OS X 10.8 includes new restrictions on running apps
John, hello. On 2012 Feb 22, at 21:52, John Clements wrote: > FWIW: actually, I don't see Jens saying that signed apps will by default run > in a mode that enforces privilege checking, and I just spent a few minutes > digging, and didn't find anything saying that. Are you really sure that > Gatekeeper's "level 2"--code must be signed, but not app-store-ready--will > enforce access restrictions? Pointers gladly appreciated, and maybe I'm just > not reading carefully enough. I had formed that impression, and it seems consistent with what I've read, but now I'm not so sure. I've found two (good as usual) Ars Technica discussions of Gatekeeper in general [1], plus a reasonably detailed account of the sandboxing mechanism and how Apple expect people to use it [2]. It seems that the expectation is that different threads might have different entitlements, depending on what they do, so that a thread which is decoding a PDF is denied access to the filesystem; and that certain user actions, such as saving a file, will be handed over (if necessary) to a privileged 'Powerbox' daemon. All very entertaining, but it doesn't actually answer your question. I'm afraid I can find neither chapter and verse, nor exegesis, which makes it clear what the default will be. So I'd appreciate pointers, too! Best wishes, Norman [1] http://arstechnica.com/apple/news/2012/02/developers-gatekeeper-a-concern-but-still-gives-power-users-control.ars http://arstechnica.com/apple/news/2011/11/apple-pushes-back-sandboxing-deadline-as-devs-struggle-with-tradeoffs.ars [2] http://arstechnica.com/apple/reviews/2011/07/mac-os-x-10-7.ars/9 -- Norman Gray : http://nxg.me.uk SUPA School of Physics and Astronomy, University of Glasgow, UK _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] OS X 10.8 includes new restrictions on running apps
On Feb 22, 2012, at 1:05 PM, Norman Gray wrote: > > Greetings. > > On 2012 Feb 22, at 20:03, Jens Axel Søgaard wrote: > >> The tech press reports that the default is to "medium" i.e. applications >> downloaded from the mac app store and from identified developers (that is >> signed applications) are allowed to run. > > For those who haven't chased this up already (I haven't gone into much > detail), there are some interesting links at Daring Fireball[1], including a > piece which highlights some of the likely problems[2]. > > The short version appears to be that, as Jens says, Gatekeeper will by > default run in a mode which enforces MAC on applications, and the principal > problem -- voiced at length and at high volume -- is that the currently > available set of 'entitlements' (where the application declares what set of > resources it wishes to have access to) is too small for a significant > minority of applications. FWIW: actually, I don't see Jens saying that signed apps will by default run in a mode that enforces privilege checking, and I just spent a few minutes digging, and didn't find anything saying that. Are you really sure that Gatekeeper's "level 2"--code must be signed, but not app-store-ready--will enforce access restrictions? Pointers gladly appreciated, and maybe I'm just not reading carefully enough. John smime.p7s Description: S/MIME cryptographic signature _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] build fail for 64-bit OS X af9bab74265
Just wanted to throw in my two cents that I was having the same problem as John, and his fix works for me also. I'd misdiagnosed it on my machines, tried a couple of things, and then just ended up disabling mac64 until now. Thanks, John! Stevie On Feb 22, 2012, at 4:25 PM, John Clements wrote: > > On Feb 13, 2012, at 5:16 PM, Matthew Flatt wrote: > >> Have you changed anything about your installation via MacPorts lately? >> >> I think you're seeing a mismatch between a MacPorts iconv and the >> pre-installed iconv. See also >> >> https://lists.racket-lang.org/dev/archive/2011-April/006153.html > > To follow up on this, and perhaps for others: it turned out that the build > was pulling include files from /usr/include but getting its libraries from > /opt/local/lib. I solved it this once by setting CPPFLAGS: > > export CPPFLAGS=-I/opt/local/include > > ... before running configure. > > I'm puzzled, though, because I've never had this problem before, including > another OS X machine (this one, running 10.6) where I have libiconv installed > through macports as well, and where CPPFLAGS is also not set by default in my > environment. This isn't high enough on my list to paw through configure and > try to figure out how include paths are computed, so I'll just leave this as > a "use it if you need it" item. > > Hope this helps others, > > John > > _ > Racket Developers list: > http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] build fail for 64-bit OS X af9bab74265
On Feb 13, 2012, at 5:16 PM, Matthew Flatt wrote: > Have you changed anything about your installation via MacPorts lately? > > I think you're seeing a mismatch between a MacPorts iconv and the > pre-installed iconv. See also > > https://lists.racket-lang.org/dev/archive/2011-April/006153.html To follow up on this, and perhaps for others: it turned out that the build was pulling include files from /usr/include but getting its libraries from /opt/local/lib. I solved it this once by setting CPPFLAGS: export CPPFLAGS=-I/opt/local/include ... before running configure. I'm puzzled, though, because I've never had this problem before, including another OS X machine (this one, running 10.6) where I have libiconv installed through macports as well, and where CPPFLAGS is also not set by default in my environment. This isn't high enough on my list to paw through configure and try to figure out how include paths are computed, so I'll just leave this as a "use it if you need it" item. Hope this helps others, John smime.p7s Description: S/MIME cryptographic signature _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] OS X 10.8 includes new restrictions on running apps
Greetings. On 2012 Feb 22, at 20:03, Jens Axel Søgaard wrote: > The tech press reports that the default is to "medium" i.e. applications > downloaded from the mac app store and from identified developers (that is > signed applications) are allowed to run. For those who haven't chased this up already (I haven't gone into much detail), there are some interesting links at Daring Fireball[1], including a piece which highlights some of the likely problems[2]. The short version appears to be that, as Jens says, Gatekeeper will by default run in a mode which enforces MAC on applications, and the principal problem -- voiced at length and at high volume -- is that the currently available set of 'entitlements' (where the application declares what set of resources it wishes to have access to) is too small for a significant minority of applications. For what it's worth, it seems to me that MAC is a Good Thing for me as a user -- there are some applications that really have no business wandering all over my system, poking around (no, you may _not_ have access to my address book!) -- but I can see this potentially being a right pain in the tender bits for me as a developer, and a user of scripting environments such as Racket. It all depends on the details of the entitlements DSL, and who gets to declare what, when. All the best, Norman (currently with no plans to move from 10.6) [1] http://daringfireball.net/linked/2012/02/21/sandboxing [2] http://www.red-sweater.com/blog/2324/fix-the-sandbox -- Norman Gray : http://nxg.me.uk SUPA School of Physics and Astronomy, University of Glasgow, UK _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] OS X 10.8 includes new restrictions on running apps
The tech press reports that the default is to "medium" i.e. applications downloaded from the mac app store and from identified developers (that is signed applications) are allowed to run. /Jens Axel 2012/2/21 Robby Findler > I'm hoping that there will be some backlash from this and we'll not > actually see a high setting being the default in 10.8 > > Robby > > On Tue, Feb 21, 2012 at 3:56 PM, John Clements > wrote: > > In a move that I find not even slightly surprising, the new Apple > operating system (10.8, out soon?) includes new features that make it > harder for developers to deploy their code on user machines. > > > > http://tidbits.com/article/12795 > > > > Specifically, the technology is called "Gatekeeper", and it allows users > to choose between various levels of security. At the highest level, you > can choose to run only programs distributed through Apple's "App Store." > Bleah. There is also a next level down, though, that runs any program that > has acquired a signing certificate from Apple. It's free... if you're a > member of Apple's developer program, which appears to currently be $99/year. > > > > I'm also curious/worried about what the terms of the agreement are; as > with any development environment, Racket can *certainly* be used to run > ill-behaved programs; if acquiring the certificate means signing something > accepting legal liability for harm done by users of the application, Racket > is a non-starter. > > > > Anyhow, just something else to be aware of. > > > > John > > > > > > _ > > Racket Developers list: > > http://lists.racket-lang.org/dev > > > > _ > Racket Developers list: > http://lists.racket-lang.org/dev > -- -- Jens Axel Søgaard _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] OS X 10.8 includes new restrictions on running apps
On Tue, Feb 21, 2012 at 9:59 PM, John Clements wrote: > As I've said before, I'll be sad but not surprised when Apple decides to > become evil and I have to leave OS X for Linux. [OT] I uninstalled OS X on my MacBook Air in December because of the signs of the times from the last update. I'm now a happy "Ubuntu" [*] user. Jay [*] I don't use any of Ubuntu Mac-copying UI. I use undefiled xmonad, emacs, and conkeror. -- Jay McCarthy Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay "The glory of God is Intelligence" - D&C 93 _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] Scribble documentation bug
In scribblings/scribble/manual.scrbl: cite does not take only strings. I've been using bib-entries with it exclusively, actually. What all can it take? I see it makes a link element with a tag like `(cite ,@all-things-that-might-be-strings). I'd rather not go mucking about with what tags are and such to know what's really going on. Thanks, -Ian _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] Possible bug in get-module-code function of syntax/modcode
Hi all! It seems to me that a bug exists in handling so-extensions inside get-module-code. Imagine a situation when we want to use get-module-code on mzmimer.so file which is located inside /opt/dozor/racket/lib/racket/collects/jetinfo/compiled/native/i386-linux/3m and is specified by (lib "mzmimer" "jetinfo") module-spec. No, I don't really want to do some introspection on so-extension, but geiser (emacs extension for racket) does. Going inside get-module-code (look for squre-bracketed line numbers in listing below), path = /opt/dozor/racket/lib/racket/collects/jetinfo/mzmimer ... [1]: orig-path = /opt/dozor/racket/lib/racket/collects/jetinfo/mzmimer [2]: base = /opt/dozor/racket/lib/racket/collects/jetinfo, orig-file = mzmimer [3]: main-file = mzmimer, alt-file = #f [4]: main-path = /opt/dozor/racket/lib/racket/collects/jetinfo/mzmimer [5]: alt-path = #f [6]: main-path-d = #f [7]: alt-path-d = #f [8]: try-alt? = #t [9]: error! main-path-d is #f because orig-path doesn't actually exist, but it is ok for so-extension. alt-file doesn't exist neither, but stiil we try to calculate path to it. The bug in my opinion resides in line [8]: [try-alt? (and (not alt-path-d) (not main-path-d))] so I've changed it to: [try-alt? (and alt-file (not alt-path-d) (not main-path-d))] and it has worked for me. I doubt whether that fix is good for everyone, but know for sure it should be fixed somehow. (let*-values ([(orig-path) (resolve path)] [1] [(base orig-file dir?) (split-path path)] [2] [(main-file alt-file) [3] (if rkt-try-ss? (let* ([b (path->bytes orig-file)] [len (bytes-length b)]) (cond [(and (len . >= . 4) (bytes=? #".rkt" (subbytes b (- len 4 ;; .rkt => try .rkt then .ss (values orig-file (bytes->path (bytes-append (subbytes b 0 (- len 4)) #".ss")))] [else ;; No search path (values orig-file #f)])) (values orig-file #f))] [(main-path) (if (eq? main-file orig-file)[4] orig-path (build-path base main-file))] [(alt-path) (and alt-file [5] (if (eq? alt-file orig-file) orig-path (build-path base alt-file)))] [(base) (if (eq? base 'relative) 'same base)]) (let* ([main-path-d (file-or-directory-modify-seconds orig-path #f (lambda () #f))] [6] [alt-path-d (and alt-path [7] (not main-path-d) (file-or-directory-modify-seconds alt-path #f (lambda () #f)))] [path-d (or main-path-d alt-path-d)] [file (if alt-path-d alt-file main-file)] [path (if alt-path-d alt-path main-path)] [try-alt? (and (not alt-path-d) (not main-path-d))] [8] [get-so (lambda (file) (build-path base sub-path "native" (system-library-subpath) (path-add-suffix file (system-type 'so-suffix] [zo (build-path base sub-path (path-add-suffix file #".zo"))] [alt-zo (and try-alt? (build-path base sub-path (path-add-suffix alt-file #".zo")))] [9] -- Best regards, Timur _ Racket Developers list: http://lists.racket-lang.org/dev
