On Tuesday 13 September 2016 at 14:10, David Sheets wrote: > From the yojson docs:
[...] So precisely: it will decode a lot of things the string production of RFC 7159 would not decode (it's not only about UTF-8 validity, you are not supposed to have control characters in encoded json text). I'm not demonstrating an attack but I precisely think that security is one of these topics were you don't want to "do it like this until proven otherwise". If you like it that way so be it, but stop accusing me of FUD. When you implement a standard that refers to others final correctness is assumed given the other standards being implemented correctly, weakest link bla bla. > The attack you are partially describing would be the ACME CA sending > you malicious JSON. I'm not describing an attack I'm describing an attack *vector* in any program that uses yojson. It may or may not be exploitable, but I absolutely dont care about this: you have the choice of not having this attack vector at all. Given the current trend of security breaches I expect good and responsible programmers to actually make the right choices. > You are sending messages containing unsubstantiated security claims See above. I'm not sending messages about security claims (I'm absolutely not a security expert and not interested beyond what is needed for me to write dependable software users can trust). I'm sending messages about a security mindset; don't use unsecure libraries that can open attack vectors in your programs. > I find it quite something that your original messages were vague to the point > of useless but now you > have expended far more effort justifying your opinion than would have been > required to help the project. Well I expected you to be a little more subtle than that and to understand the points without having to go that far in this discussion. Daniel _______________________________________________ opam-devel mailing list opam-devel@lists.ocaml.org http://lists.ocaml.org/listinfo/opam-devel
