On Tue, Sep 13, 2016 at 12:42 PM, Daniel Bünzli <daniel.buen...@erratique.ch> wrote: > On Tuesday 13 September 2016 at 12:56, David Sheets wrote: >> > "Note that yojson never checks the encoding of strings." >> >> This refers to the internal string representation. > > Please, check your facts.
From the yojson docs: Note that yojson never checks the encoding of strings. All ASCII-compatible encodings including UTF-8 are supported by yojson readers and writers. Non-ASCII-compatible encodings UTF-16BE, UTF-16LE, UTF-32BE and UTF-32LE are not supported. "\uXXXX" escape sequences are converted by the readers into the equivalent UTF-8 multibyte sequences. Characters outside the ASCII range are always written as is, as permitted by the JSON standard. Bytes that do not form valid UTF-8 characters are also output as is. It is the user's responsibility to check for the correctness of UTF-8 data when appropriate. >> It's not clear to me why or how this will result in users "being sorry" for >> using a >> library in order to get a certificate from a (trusted) CA. > > Any yojson user might end up being sorry at some point and I have said this > for a long time [1]. There are quite a few scenarios where you could be > bitten by this behaviour since it invalidates invariants you may think hold > about a string that was decoded about a standard compliant JSON parser (like > absence of NULL byte in the original string -- note that decoded strings > reencoded to UTF-8 may have null bytes because U+0000 is allowed via > *escape*). Now store that original string somewhere and think about the fact > that most OCaml's system APIs were vulnerable to NULL byte injection until > recently (and I'm sure a lot of other C bindings are). The attack you are partially describing would be the ACME CA sending you malicious JSON. This seems fairly unlikely and in violation of the trust model of the CA system, though, I admit, it is possible. It is likely that the author of the library is not aware of these facts which is why I continue to urge you to help them understand the issues. >> Telling them is certainly more effective (and socially responsible) than >> spreading FUD on an unrelated mailing list. > > I'm not spreading FUD I'm talking about a reality, on mailing list were this > project was mentioned to be used. And sorry I don't have time to loose with > random people toying in a random, unreleased, github repository. You are sending messages containing unsubstantiated security claims which result in fear (probably overblown), uncertainty (because the claims have no demonstration), and doubt (about the author's "ability to actually implement these things"). 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. > Security is a mindset. Security is also an economic proposition and a community effort. A CA attacking you is possible but unlikely. Helping others to develop secure software is beneficial to all the users of that software. We are talking about a project that is *already written in OCaml* so it is unlikely that the author is incapable of building excellent software in the short to medium term. > You are showing that you are not having it and I personally feel that neither > does an individual that uses insecure libraries to build security > infrastructure. Now trust who you want I just happens that I have different > expectations about the quality of the code I use. It's interesting that defending against knee-jerk FUD attacks is not compatible with a "security mindset". I think that a blanket dismissal of the library (and its author) due to the adoption of a widespread (though fraught) library is absurd. It is very likely the author does not know the things you know and does not have the experience with yojson or the OCaml community that you have. Clearly they are interested in security and clearly they have produced something of value even if not perfect (it's unreleased!). David _______________________________________________ opam-devel mailing list opam-devel@lists.ocaml.org http://lists.ocaml.org/listinfo/opam-devel
