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.
