Re: Is there any security risk related to the use of the reader?

[Amirouche Boubekki]

On 2018-03-02 00:56, Mark H Weaver wrote:
> I would not consider Guile's 'read' to be trustworthy when processing
> potentially malicious inputs.
>
>       Mark

Thanks for the input.

FWIW, I've written a procedure 'read' that is AFAIK safe but can
_fail_ on malicious input.

It can read:

- strings,
- booleans,
- simple numbers like 123456,
- rationals like 1/4 and
- simple symbols .ie unlike what is generated by 'gensym'

I attached to this mail all the files. It based on the stream
library I've been working on and a simple parser combinator
library based on it.

The main issue I see is that combinatorix doesn't take a port
as input. I could probably turn a port into a functional stream
but right now I don't need it. Patch welcome :)

Also I greatly improved error reporting compared to my last
attempt at building a parser combinator. Now the library
will tell you the failing parser with the argument that were
passed to it and the char line and column that triggered the
error.

For instance, given the following definitions:

  (define parse-a (parse-xchar #\a))
  (define parse-b (parse-xchar #\b))
  (define parse-c (parse-xchar #\c))

  (define parse-abc (each parse-a parse-b parse-c))

If you run the parser like that:

  (pk (parse parse-abc "ab©"))

You get the following exception:

  neon/read.scm:75:4: Throw to key `combinatorix' with args `(#<<error> 
value: <xchar #\© [1,3] @ 2> parser: #<procedure parse-xchar (char)> 
args: #\c>)'.

That is parse-xchar #\c that is failing. Things could be improved
but its encouraging I think.

For info on parser combinators see https://epsil.github.io/gll/


Happy hacking!

read.scm
Description: Text document

streams.scm
Description: Text document

combinatorix.scm
Description: Text document