Peter Eisentraut writes:
> On 2019-09-16 06:24, Tom Lane wrote:
>> So it seems that the consensus is that it's okay to mark these
>> functions leakproof, because if any of the errors they throw
>> are truly reachable for other than data-corruption reasons,
>> we would wish to try to prevent such e
On 2019-09-16 06:24, Tom Lane wrote:
> So it seems that the consensus is that it's okay to mark these
> functions leakproof, because if any of the errors they throw
> are truly reachable for other than data-corruption reasons,
> we would wish to try to prevent such errors. (Maybe through
> upstrea
Stephen Frost writes:
> * Robert Haas (robertmh...@gmail.com) wrote:
>> On Thu, Sep 12, 2019 at 5:19 PM Tom Lane wrote:
>>> However, if there is some character C that makes ICU misbehave like
>>> that, we are going to have problems with indexing strings containing C,
>>> whether we think varstr_c
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Thu, Sep 12, 2019 at 5:19 PM Tom Lane wrote:
> > However, if there is some character C that makes ICU misbehave like
> > that, we are going to have problems with indexing strings containing C,
> > whether we think varstr_cmp is leaky or
On Thu, Sep 12, 2019 at 5:19 PM Tom Lane wrote:
> However, if there is some character C that makes ICU misbehave like
> that, we are going to have problems with indexing strings containing C,
> whether we think varstr_cmp is leaky or not. So I'm not sure that
> focusing our attention on leakiness
Robert Haas writes:
> I wouldn't feel comfortable with ignoring information leaks that can
> happen with some valid strings but not others. That sounds like
> exactly the sort of information leak that we must prevent. The user
> can write arbitrary stuff in their query, potentially transforming
>
On Thu, Sep 12, 2019 at 1:38 PM Tom Lane wrote:
> In any case, from a purely theoretical viewpoint, such an error message
> *does* constitute a leak of information about the input strings. Whether
> it's a usable leak is very debatable, but that's basically what we've
> got to decide.
I'm pretty
I wrote:
> I agree with your point that this is a shouldn't-happen corner case.
> The question boils down to, if it *does* happen, does that constitute
> a meaningful information leak? Up to now we've taken quite a hard
> line about what leakproofness means, so deciding that varstr_cmp
> is leakpr
Robert Haas writes:
> On Thu, Sep 12, 2019 at 12:19 PM Tom Lane wrote:
>> After burrowing down further, it's visibly the case that
>> text_cmp and varstr_cmp don't leak in the sense of actually
>> reporting any part of their input strings. What they do do,
>> in some code paths, is things like
>
On Thu, Sep 12, 2019 at 12:19 PM Tom Lane wrote:
> After burrowing down further, it's visibly the case that
> text_cmp and varstr_cmp don't leak in the sense of actually
> reporting any part of their input strings. What they do do,
> in some code paths, is things like
>
> ereport(ERROR,
>
I wrote:
> Seems like we have two choices:
> 1. Remove the leakproof marking on texteq()/textne(). This
> would, unfortunately, be catastrophic for performance in
> a lot of scenarios where leakproofness matters.
> 2. Fix text_cmp to actually be leakproof, whereupon we might
> as well mark all the
11 matches
Mail list logo
