If you don't need the on-the-wire form to be human-readable, you should
look at `racket/fasl`: https://docs.racket-lang.org/reference/fasl.html It
can handle all of the acyclic data that `read` and `write` can (plus a
little extra), it *doesn't* have `read`'s many configuration parameters
that
Thanks everyone. I feel fine to use `read` for this use case now. I
overlooked `call-with-default-reading-parameterization` which specifically
mentions "reading from untrusted sources" so that is very reassuring.
On Sunday, February 28, 2021 at 3:36:29 PM UTC-6 John K wrote:
>
>
> On Feb 28,
> On Feb 28, 2021, at 2:50 PM, Ryan Kramer wrote:
>
>
[…]
>
> 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.
I don’t think this
Typo: "but the library itself leverages the reader" should read "but if the
library itself leverages the reader"
On 2/28/21 4:20 PM, Sage Gerard wrote:
> Does call-with-default-reading-parameterization help?
>
>
Does call-with-default-reading-parameterization help?
https://docs.racket-lang.org/reference/Reading.html?q=accept-compiled#%28def._%28%28lib._racket%2Fprivate%2Fmisc..rkt%29._call-with-default-reading-parameterization%29%29
The parameters you are seeing re: accepting -lang, -reader are for when
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
6 matches
Mail list logo
