[racket-dev] syntax taints instead of syntax certificates

At Sat, 2 Jul 2011 12:34:49 -0400, Eli Barzilay wrote:
> I read the guide chapter -- it has a few typos:
> 
> 1. The page is "stx-certs.html".

Intentional, though I'm not sure it's a good idea. There's a small
benefit of keeping the URL the same and making old links to the
certificate chapter point to the taint chapter; that small benefit
seemed to me to outweigh the benefit of making the URL and
section-reference tag say "taint".

> 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'.

Fixed.

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

A large number of technical terms? It bothers me too, and I tried to
write the documentation with fewer terms before, but I think it turns
out better with more terms. Ryan and I spent a lot of time refining the
terminology, but I guess it could always be better.

> 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've added `syntax-protect' for `enter!'.

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

I think I understand how you define "hole", but just to be clear, I
think the switch to taints strictly decreases the number of macros that
can be abused --- since any macro that can be abused after the taint
change could always be abused via `syntax-local-expand'.

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

It's not obvious to me either way. It may turn out that not arming a
macro expansion helps keep the taint system out of your way when you
don't need it. That benefit could outweigh the benefit of blocking
casual attempts at abuse, and I'm inclined to explore the possibility
for now.

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

Do you mean `protect-out'?