Re: [racket-dev] sandboxing coming for Mac App Store Apps

[Brent Fulgham]

Hi,

On Sep 2, 2011, at 4:54 PM, John Clements wrote:

> 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:


I don't want to rehash history, but is there a technical reason that DrRacket 
isn't being distributed through the Mac App store?

I have to admit to enjoying the convenience of installing and keeping software 
up-to-date via the App store...

-Brent
_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

[racket-dev] sandboxing coming for Mac App Store Apps

[John Clements]

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:   

John



smime.p7s
Description: S/MIME cryptographic signature
_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] online check syntax deadlock: can you help?

[John Clements]

On Sep 2, 2011, at 5:29 AM, Matthew Flatt wrote:

> At Thu, 1 Sep 2011 15:20:27 -0700, John Clements wrote:
>>> Note that the code ignores the result of `TransformProcessType', which
>>> is a bad idea. If you remove the `void' wrapper, what number result
>>> gets printed on your machine?
>>> 
>> 
>> Looks like it's -50.
> 
> -50 means "bad argument".
> 
> Apple's docs say
> 
> struct ProcessSerialNumber {
>   unsigned long highLongOfPSN;
>   unsigned long lowLongOfPSN;
> };
> 
> but "MacTypes.h" says
> 
> struct ProcessSerialNumber {
>   UInt32  highLongOfPSN;
>   UInt32  lowLongOfPSN;
> };
> 
> and those aren't the same on a 64-bit system. Maybe the docs that I
> found are too old or are only meant to apply to 32-bit systems.
> 
> Can you remind me whether you're using a 32-bit or 64-bit build?
> 
> When I try the 64-bit build, then it fails in the way you describe
> until I fix the `_ProcessSerialNumber' declaration:
> 
> (define-cstruct _ProcessSerialNumber
>   ([highLongOfPSN _uint32]
>[lowLongOfPSN _uint32]))

Yep, this fixes it for me. I see you've pushed it already. Thanks!

John Clements



smime.p7s
Description: S/MIME cryptographic signature
_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] Who page

[Jay McCarthy]

Community > People

On Wed, Aug 31, 2011 at 11:45 PM, Neil Van Dyke  wrote:
> I couldn't immediately find a Who page on the www.racket-lang.org, although
> I've seen something like that in the past.  How do I get to it?  The About
> navbar link just goes to the home page.
>
> I'd like to see the names of all the PLTers there, with their affiliations
> and links to their home pages.
>
> _
>  For list-related administrative tasks:
>  http://lists.racket-lang.org/listinfo/dev
>



-- 
Jay McCarthy 
Assistant Professor / Brigham Young University
http://faculty.cs.byu.edu/~jay

"The glory of God is Intelligence" - D&C 93

_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

[racket-dev] No browser window coming up for HelpDesk on menu

[Kathi Fisler]

We're having intermittent problems in which the HelpDesk doesn't come up
from the DrRacket menu in our classroom installation.  We're running 5.1.3
on Windows 7 64-bit enterprise edition.
The default web browser is Internet Explorer 8.

We haven't detected a pattern.  Sometimes, simply nothing happens when we
invoke HelpDesk from the menu.  Other times, it works fine.

Our sysadmin reports the following details about our setup:

The only thing weird that could be causing the issue from our end, is that
we push out the deployment with Microsoft App-V (formerly softgrid) however
I've turned on the flag to allow local interaction with the application
which by all means allows it to open and run things outside of the
application itself.

Any ideas, or requests for other info about the system configuration that
would help here?

thanks,
Kathi
_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

[racket-dev] Who page

[Neil Van Dyke]

I couldn't immediately find a Who page on the www.racket-lang.org, 
although I've seen something like that in the past.  How do I get to 
it?  The About navbar link just goes to the home page.


I'd like to see the names of all the PLTers there, with their 
affiliations and links to their home pages.


_
 For list-related administrative tasks:
 http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] creating executables

[Vincent St-Amour]

At Fri, 02 Sep 2011 09:15:20 +0200,
Marijn wrote:
> I just tried with latest git and nothing has changed for me. Neither
> the wrong message, nor the failing executable.

You're building executables from DrRacket, right?

Does it work if you build them from the command-line, with `raco exe'?

Vincent
_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

[racket-dev] signatures?

[Danny Yoo]

I tried the following program in ASL.  In Definitions:

;
(: g (Number -> Number))
(define g
  (lambda (x)
(if (= x 0)
x
(list "three" x
;;

I ran Definitions, and then in my Interactions window, entered:

   > (g 20)

I got back a result that was not a number, but I did not see an
expected signature error.  Should I?  I tried this in Die Macht der
Abstraktion, with identical results.
_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] drRacket Close/Close tab

[Robby Findler]

On Fri, Sep 2, 2011 at 8:35 AM, Marijn  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hi Robby,
>
> On 09/02/11 14:33, Robby Findler wrote:
>> On Fri, Sep 2, 2011 at 2:50 AM, Marijn  wrote:
>>> But anyway, the test for whether the platform is Gtk seems to be
>>> faulty, because now I'm seeing the ``Windows/OS X''-style menu.
>>> The good news is that it's now working as you describe.
>>
>> Can you tell me the result of evaluating
>>
>> (system-type)
>>
>> on your machine?
>
> 'unix

Ah, stupid me. Fix pushed.

 All platforms:

 - changed "New Tab" to -t

 - changed "Run" to -r
>>>
>>> These are working.
>>>
 - changed "Replace" to -shift-f
>>>
>>> This also seems to be working.
>>>
>>> I think Find&Replace could be so much more useful though: Ctrl-F
>>>  instead of Ctrl-F 
>>> Ctrl-G,
>>
>> I'll note two things here: it does search as you type (and it
>> circles the search results); it just does not jump around as you
>> type. I find this to be easier to use as it helps me navigate more
>> effectively through the buffer. But I realize others don't like
>> this (especially those coming from Emacs) so there is an attempt to
>> do things in a more Emacs-y way that you can get to by chosing the
>> "search with anchors" (or something like that) preference.
>
> I feel really stupid now; I could have sworn that there was no
> search-as-you-type, and it was there all along right in front of me.
> I'll try and keep my eyes open next time ;P. Thanks for your patience.

Oh, not your fault. Our preferences dialog is not exactly small 

Robby
_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] racket tests

[Paulo J. Matos]

On 31/08/11 17:35, Eli Barzilay wrote:


Much easier to run and to follow -- run this:

   racket -r quiet.rktl

with your newly made executable.



Just a note that for that to work I need to be in:
lib/racket/collects/tests/racket/

--
PMatos

_
 For list-related administrative tasks:
 http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] drRacket Close/Close tab

[Marijn]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Robby,

On 09/02/11 14:33, Robby Findler wrote:
> On Fri, Sep 2, 2011 at 2:50 AM, Marijn  wrote:
>> But anyway, the test for whether the platform is Gtk seems to be
>> faulty, because now I'm seeing the ``Windows/OS X''-style menu.
>> The good news is that it's now working as you describe.
> 
> Can you tell me the result of evaluating
> 
> (system-type)
> 
> on your machine?

'unix

>>> All platforms:
>>> 
>>> - changed "New Tab" to -t
>>> 
>>> - changed "Run" to -r
>> 
>> These are working.
>> 
>>> - changed "Replace" to -shift-f
>> 
>> This also seems to be working.
>> 
>> I think Find&Replace could be so much more useful though: Ctrl-F 
>>  instead of Ctrl-F 
>> Ctrl-G,
> 
> I'll note two things here: it does search as you type (and it
> circles the search results); it just does not jump around as you
> type. I find this to be easier to use as it helps me navigate more
> effectively through the buffer. But I realize others don't like
> this (especially those coming from Emacs) so there is an attempt to
> do things in a more Emacs-y way that you can get to by chosing the
> "search with anchors" (or something like that) preference.

I feel really stupid now; I could have sworn that there was no
search-as-you-type, and it was there all along right in front of me.
I'll try and keep my eyes open next time ;P. Thanks for your patience.

Marijn
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.18 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk5g27wACgkQp/VmCx0OL2w+fwCdEwwfdTD+RqHSH1mhPiFN0RyJ
F90Anjktee2gw20jm8fRXsqbV93NjdD3
=icI7
-END PGP SIGNATURE-
_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] drRacket Close/Close tab

[Robby Findler]

On Fri, Sep 2, 2011 at 2:50 AM, Marijn  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hi Robby,
>
> On 09/01/11 17:55, Robby Findler wrote:
>> Okay, thanks everyone for the comments. Generally speaking, I
>> dread keybinding-based discussions because it is impossible to make
>> everyone happy (and usually only the unhappy people speak up :).
>
> It will probably get really quiet now then ;P.

Nice! :)

But to you unhappy folks: now is the time to speak up! It is better to
make the changes together so I only get yelled at once. :)

>> Still, I think you folks are right that changes need to happen.
>> I've looked over various apps and the guidelines and whatnot and
>> (yep, I buy the argument that 'Terminal and Safari don't follow the
>> HIG so why should we?'.) so here's the changes I've just pushed.
>>
>> Mac OS X & Windows :
>>
>> - renamed "Close" to "Close Window" (but kept the keybinding
>> switchero-ness as is)
>>
>> Gtk:
>>
>> - changed the menus so there is only one "Close" menu (no "Close
>> Tab" or "Close Window"); if there are multiple tabs, it closes the
>> tab otherwise it closes the window. To close the window in the
>> multiple tabs case, you have to use the close box (or maybe alt-f4
>> if the OS-level keybindings map it to closing the window).
>
> I think the distinction (between platforms) in the menu is mostly
> academic (both are good choices) and should IMHO be eliminated since
> it can only create confusion when people on different platforms talk
> to each other.

Well, that's something that you'll have to talk to Apple and Gnome
about, not us. :)

> But anyway, the test for whether the platform is Gtk
> seems to be faulty, because now I'm seeing the ``Windows/OS X''-style
> menu. The good news is that it's now working as you describe.

Can you tell me the result of evaluating

  (system-type)

on your machine?

>> All platforms:
>>
>> - changed "New Tab" to -t
>>
>> - changed "Run" to -r
>
> These are working.
>
>> - changed "Replace" to -shift-f
>
> This also seems to be working.
>
> I think Find&Replace could be so much more useful though: Ctrl-F
>  instead of Ctrl-F  Ctrl-G,

I'll note two things here: it does search as you type (and it circles
the search results); it just does not jump around as you type. I find
this to be easier to use as it helps me navigate more effectively
through the buffer. But I realize others don't like this (especially
those coming from Emacs) so there is an attempt to do things in a more
Emacs-y way that you can get to by chosing the "search with anchors"
(or something like that) preference.

> identifier renaming (ignore strings, symbols, partial matches),
> regular expression replacements, identifier regular expression
> renaming (lifts restriction on partial matches, by using wildcards to
> extend to full match). I'm sure other people have more/better ideas.

There's also the online check syntax which does actual identifier
renaming, not a heuristic one.

Robby
_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] online check syntax deadlock: can you help?

[Matthew Flatt]

At Thu, 1 Sep 2011 15:20:27 -0700, John Clements wrote:
> > Note that the code ignores the result of `TransformProcessType', which
> > is a bad idea. If you remove the `void' wrapper, what number result
> > gets printed on your machine?
> > 
> 
> Looks like it's -50.

-50 means "bad argument".

Apple's docs say

 struct ProcessSerialNumber {
   unsigned long highLongOfPSN;
   unsigned long lowLongOfPSN;
 };

but "MacTypes.h" says

 struct ProcessSerialNumber {
   UInt32  highLongOfPSN;
   UInt32  lowLongOfPSN;
 };

and those aren't the same on a 64-bit system. Maybe the docs that I
found are too old or are only meant to apply to 32-bit systems.

Can you remind me whether you're using a 32-bit or 64-bit build?

When I try the 64-bit build, then it fails in the way you describe
until I fix the `_ProcessSerialNumber' declaration:

 (define-cstruct _ProcessSerialNumber
   ([highLongOfPSN _uint32]
[lowLongOfPSN _uint32]))

_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] drRacket Close/Close tab

[Marijn]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Robby,

On 09/01/11 17:55, Robby Findler wrote:
> Okay, thanks everyone for the comments. Generally speaking, I
> dread keybinding-based discussions because it is impossible to make
> everyone happy (and usually only the unhappy people speak up :).

It will probably get really quiet now then ;P.

> Still, I think you folks are right that changes need to happen.
> I've looked over various apps and the guidelines and whatnot and
> (yep, I buy the argument that 'Terminal and Safari don't follow the
> HIG so why should we?'.) so here's the changes I've just pushed.
> 
> Mac OS X & Windows :
> 
> - renamed "Close" to "Close Window" (but kept the keybinding 
> switchero-ness as is)
> 
> Gtk:
> 
> - changed the menus so there is only one "Close" menu (no "Close
> Tab" or "Close Window"); if there are multiple tabs, it closes the
> tab otherwise it closes the window. To close the window in the
> multiple tabs case, you have to use the close box (or maybe alt-f4
> if the OS-level keybindings map it to closing the window).

I think the distinction (between platforms) in the menu is mostly
academic (both are good choices) and should IMHO be eliminated since
it can only create confusion when people on different platforms talk
to each other. But anyway, the test for whether the platform is Gtk
seems to be faulty, because now I'm seeing the ``Windows/OS X''-style
menu. The good news is that it's now working as you describe.

> All platforms:
> 
> - changed "New Tab" to -t
> 
> - changed "Run" to -r

These are working.

> - changed "Replace" to -shift-f

This also seems to be working.

I think Find&Replace could be so much more useful though: Ctrl-F
 instead of Ctrl-F  Ctrl-G,
identifier renaming (ignore strings, symbols, partial matches),
regular expression replacements, identifier regular expression
renaming (lifts restriction on partial matches, by using wildcards to
extend to full match). I'm sure other people have more/better ideas.

> Please let me know if you spot any problems.

No problems, just work in progress (as is all software) ;P
Thanks for working on this!

Marijn
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.18 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk5girYACgkQp/VmCx0OL2y3/ACfY5Gv2BKIYyY+dbFFog16FXGL
C4oAn3+iXbOJiA3f2k8dhSQ160Wlm08h
=aDXI
-END PGP SIGNATURE-
_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] drRacket Close/Close tab

[Marijn]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Matthew,

On 09/01/11 16:41, Marijn wrote:
> On 09/01/11 16:29, Matthew Flatt wrote:
>> At Thu, 1 Sep 2011 09:14:47 -0500, Robby Findler wrote:
>>> On Wed, Aug 31, 2011 at 3:30 AM, Marijn  
>>> wrote:
> I like the idea of adding shift, but I've changed things
> so that instead of the w shortcut going away, the close
> menu item becomes -shift-w (so the shifting
> behavior is still there and we are complying with the
> guidelines in the no-tabs case).
 
 On Gtk nothing has changed for me.
 
>>> 
>>> I've managed to get my ubuntu 10.04.1 vm back in shape and 
>>> rebuild drracket there and the various keybindings and menu
>>> items seem to shift around as expected.
> 
>> Was that after commit 459d2422e3ad8?
> 
>> I looked into menu-item shortcuts this morning and pushed a 
>> Gtk-specific fix for updating the displayed shortcut.
> 
> 
> Alright, that probably explains it. I'll test again tomorrow to
> make sure.

It now works for me too. Thanks,

Marijn
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.18 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk5gg7MACgkQp/VmCx0OL2wWxQCfdI9CZWxBDy0BEaZlplHvUx4o
inAAoJe6JT3LIkGqzfpEs/a++TxWlqTf
=wtt/
-END PGP SIGNATURE-
_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] creating executables

[Marijn]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Vincent,

On 09/01/11 17:27, Vincent St-Amour wrote:
> I had a similar problem on Linux x86. Matthew just pushed a fix,
> and now everything works for me. Haven't tried on amd64, though.
> 
> Vincent

I just tried with latest git and nothing has changed for me. Neither
the wrong message, nor the failing executable.

Marijn

> At Thu, 01 Sep 2011 16:24:02 +0200, Marijn wrote:
>> 
> Hi list,
> 
> when creating executables from racket, when I choose (the
> defaults) standalone based on racket, it will say "creating
> executable for distribution". I did not choose for distribution, so
> that is wrong.The created executable fails to run like this:
> 
> $ ./hello read failed to read all 885878182 bytes from file 
> /home/marijn/racketzooi/./hello Aborted
> 
> 
> 
> My test program:
> 
> 
> 
> #lang racket
> 
> (print "hello")
> 
> 
> 
> This is on amd64 Linux with a racket from a day old.
> 
> Marijn
>> _ For
>> list-related administrative tasks: 
>> http://lists.racket-lang.org/listinfo/dev

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.18 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk5ggogACgkQp/VmCx0OL2yBqwCfa08Brqs0eBj2CYV8GxGIgLwo
t34AniKekcSvspiJAAZL7Q8/vzgv2ivA
=qdBp
-END PGP SIGNATURE-
_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev