[racket-dev] syntax taints instead of syntax certificates

I read the guide chapter -- it has a few typos:

1. The page is "stx-certs.html".

2. There's still one mention of "certificate".

3. Some modules are referred to by name where there is no such name.
   For example, "the q module" (I'm pretty sure that there were more).

4. Talks about defining `protect-go-syntax', but it should be
   `go-syntax-protect'.

Also, I still find the relatively large number of as something that
makes understanding it hard, and maybe it's because I'm not a native,
but I find the taints/dye-pack confusing and unhelpful.


On Wednesday, Matthew Flatt wrote:
> 
> I think you want to use `syntax-protect' on any exported macro.

This does sound like what I was worried about.

Here's an example that shows that `enter!' is now "more broken" than
it was:

  Welcome to Racket v5.1.1.8.
  > ((eval (cadr (syntax->list (expand-syntax #'(enter! foo))))) 1 2 3)
  procedure do-enter!: expects 2 arguments, given 3: 1 2 3
  > (hash-set! (eval (datum->syntax (cadr (syntax->list (expand-syntax #'(enter! foo)))) 'loaded)) (collection-file-path "main.rkt" "racket") 'junk)
  > (enter! (file "/tmp/x"))
  mod-depends: expects argument of type <struct:mod>; given 'junk

I really liked that these things didn't work before.  It's good to
know that there was a hole that is now plugable, but it looks to me
like the cost is getting many more holes by mistake.


> > On Wed, Jun 29, 2011 at 10:10 PM, Eli Barzilay <eli at barzilay.org> wrote:
> > > An attempt to clarify what's unclear to me: if I'm supposed to almost
> > > always "arm" the result of a transformer, then why not have the
> > > expander do that for me, and add some new thing so in the exceptional
> > > cases I could do
> > >
> > >  (define-syntax (foo stx)
> > >    (dont-arm ...blah...))
> > >
> > > ?
> 
> Sorry --- that point was buried too deeply in my message (first
> sub-bullet for the last bullet in the third set of bullets).
> 
> The problem with having the macro transformer add `syntax-protect' for
> 
>  (define-syntax bar
>    (lambda (stx) ...))
> 
> is that some other transformer can say
> 
>  ((syntax-local-value #'bar) stx)
> 
> to get the transformer's result without `syntax-protect' --- which
> was a gaping hole that Ryan noticed in the certificate system.
> 
> We considered ways of automating `syntax-protect' for all macros,
> but the ways we found seemed to create more problems than they
> solved.

Yes, I realize that.  It looks to me like if all transformer results
are protected (except for results explicitly tagged for exclusion),
then we're at least getting the same automatic protection we got
before, and with the same security hole.  If so -- is it a good idea
to drop protections just because there is a known way of getting
around them?  (At least as far as an army goes, I know what the answer
to that would be...)

Also, isn't it possible to somehow protect that #'bar so that you
can't get its `syntax-local-value' without a powerful enough inspector
or something along this line?

-- 
          ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
                    http://barzilay.org/                   Maze is Life!