Leaving aside bugs, the intention with those parameters you mention (-lang,
-reader, -compiled) is to help with security. They certainly would allow
for code execution and they are off by default precisely because they allow
that. I think that the general principle (read should, with the default
parameter values, not evaluate any code) is one that is unlikely to change.

Robby

On Sun, Feb 28, 2021 at 1:50 PM Ryan Kramer <default.kra...@gmail.com>
wrote:

> I want to send some Racket structs across a network. I know that I can use
> prefab structs, serializable-structs, or even `eval` with a carefully
> curated namespace. I was trying to think of security problems with the eval
> approach and now I've become more afraid of `read` than I am of eval. And
> read seems necessary for all 3 approaches.
>
> The first concern I thought of was cyclic data. My code assumes there are
> no cycles; if an attacker can get me to process cyclic data my server will
> probably loop forever or crash. This can be solved by setting
> `read-accept-graph` to #f... I think. Right? (I guess another solution is
> "you need to validate the input" which is fair, but it's easy to forget or
> make a mistake.)
>
> This caused me to notice other `read-accept-***` parameters that looked
> scary (-lang, -reader, -compiled). I don't know if there is an attack
> vector here, but I felt safer turning them off also.
>
> Now I'm thinking that even if I can get it working safely today, Racket
> would be well within its rights to make enhancements to the reader in the
> future. So someday there might be new parameters that I would want to turn
> off to preserve my definition of "safe", and I have to remember this when I
> upgrade.
>
> All this makes me think that `read` is not quite the right tool for the
> job. But it's close. If there were a version of read that accepts nothing
> by default and requires the caller to opt-in to everything they want, that
> would probably be perfect.
>
> I could use JSON or XML, but that just seems silly when you have a Racket
> client talking to a Racket server.
>
> Are my concerns founded? Are there any existing solutions? Thanks for any
> advice.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to racket-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/racket-users/a2580765-3cc2-482b-8d20-f62dc1e1dc91n%40googlegroups.com
> <https://groups.google.com/d/msgid/racket-users/a2580765-3cc2-482b-8d20-f62dc1e1dc91n%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/CAL3TdOPu7ycrz%2BEMvUP9%2Bh%2BYn7d%2BOb4r8bfb6SJ3g_BxqLKJYQ%40mail.gmail.com.

Reply via email to