On Mon, 13 Feb 2012 00:32:07 +0100
mar...@v.loewis.de wrote:
> >> No, you are missing my point. I assume you proposed (even though you
> >> didn't say so explicitly) that parse_qs gets an opt-in API change to
> >> limit the number of parameters. If that is added, it will have no
> >> effect on any
No, you are missing my point. I assume you proposed (even though you
didn't say so explicitly) that parse_qs gets an opt-in API change to
limit the number of parameters. If that is added, it will have no
effect on any existing applications, as they will all currently not
pass that parameter.
No,
On Mon, 13 Feb 2012 00:08:45 +0100
mar...@v.loewis.de wrote:
>
> >> b) of limited use for existing installations which won't use the API.
> >
> > Obviously it won't fix vulnerabilities due to some other API. If you
> > propose other APIs we can also fix them.
>
> No, you are missing my point. I a
It's an API change, so it is
a) in violation with current practice for bug fix releases, and
We are already violating a lot of things in order to fix this issue.
Not really. There isn't any significant API change in the proposed patch
(the ones that are there are safe to ignore in applications
On Sun, 12 Feb 2012 21:44:22 +0100
"Martin v. Löwis" wrote:
> > Given the randomization fix will ship disabled, I thought it would be
> > nice to add a maximum element count argument to urlparse.parse_qs, with
> > a default value of e.g. 1000 (including in bugfix releases). What do
> > you think?
> Given the randomization fix will ship disabled, I thought it would be
> nice to add a maximum element count argument to urlparse.parse_qs, with
> a default value of e.g. 1000 (including in bugfix releases). What do
> you think?
It's an API change, so it is
a) in violation with current practice
