[racket-dev] syntax taints instead of syntax certificates

From: Eli Barzilay (eli at barzilay.org)
Date: Wed Jul 6 01:21:44 EDT 2011

On Saturday, Matthew Flatt wrote:
> 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".

(FWIW, I've considered changing the encoding used -- there's more and
more sites that use a common markdown which has issues with parens in
the URL.  But OTOH there are links to these pages because of that, so
possibly do that with some rewrite rules to forward the old links.)


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

Large number of terms that are supposed to work as an analogy: taints,
dye-packs, arm/disarm, protect.

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

IIUC, all macros could have been abused previously, no?  If so, then
obviously new situation has fewer abusable macros.  But there *were*
some checks before which are now not done by default, right?

To put this differently, you mentioned that things are a little
smaller/faster now -- maybe this is a result of the checks that are
now not done?  (Or mostly not done.)


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

But what I'm suggesting keeps the option of writing an unprotected
macro, so I don't see what new benefits there are for not doing the
automatic protection thing.

BTW, there's another thing that is lost -- the easy way of switching
between

  (define-syntax foo (syntax-rules () [(_ x) (blah blah)]))

and

  (define-syntax (foo stx) (syntax-case stx () [(_ x) #'(blah blah)]))

A careful programmer will need to know about the lack of protection,
so in that sense the new setup is something that you need to deal with
explicitly much more than before.


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

Maybe something like that -- if it's posible to make it so that the
expander can expand (bar ...) but you can't access the binding directly?

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


Posted on the dev mailing list.