On Thu, 25 Jul 2019 at 02:16, Nam Nguyen <bitsink@gmail.com> wrote:
> Back to my original requests to the list: 1) Whether we want to have a (possibly private) parsing library in the stdlib
In the abstract, no. Propose a specific library, and that answer would
change to "maybe".
I have no specific library to propose. I'm looking for a list of features such a library should have.
> and 2) What features it should have.
That question only makes sense if you get agreement to the abstract
proposal that "we should add a parsing library. And as I said, I don't
agree to that so I can't answer the second question.
As Chris summarized it correctly, I am advocating for a general solution to individual problems (which have the same nature). We can certainly solve the problems when they are reported, or we can take a proactive approach to make them less likely to occur. I am talking about a class of input validation issues here and I thought parsing would be a very natural solution to that. This is quite similar to a context-sensitive templating library that prevents cross-site-scripting on the output side. So I don't know why (or what it takes) to convince people that it's a good thing(tm).
Generally, things go into the stdlib when they have been developed
externally and proved their value. The bar for designing a whole
library from scratch, "specifically" targeted at stdlib inclusion, is
very high, and you're nowhere near reaching it IMO.
This is a misunderstanding. I have not proposed any from-scratch, or existing library to be used. And on this note, please allow me to make it clear once more time that I am not asking for a publicly-facing library either.
> These are good points to set as targets! What does it take for me to get the list to agree on one such set of criteria?
You need to start by getting agreement on the premise that adding a
newly-written parser to the stdlib is a good idea. And so far your
*only* argument seems to be that "it will avoid a class of security
bugs" which I find extremely unconvincing (and I get the impression
others do, too).
Why? What is unconvincing about a parsing library being able... parse (and therefore, validate) inputs?
But even if "using a real parser" was useful in that
context, there's *still* no argument for writing one from scratch,
rather than using an existing, proven library.
Never a goal.
At the most basic
level, what if there's a bug in your new parsing library? If we're
using it in security-critical code, such a bug would be a
vulnerability just like the ones you're suggesting your parser would
avoid. Are you asking us to believe that your code will be robust
enough to trust over code that's been used in production systems for
years?
I think you need to stop getting distracted by details, and focus on
your stated initial request "Whether we want to have a (possibly
private) parsing library in the stdlib". You don't seem to me to have
persuaded anyone of this basic suggestion yet,
Good observation. How do I convince you that complex input validation tasks should be left to a parser?
Thanks!
Nam