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
Currently, texteq() and textne() are marked leakproof, while
sibling operations such as textlt() are not. The argument
for that was that those two functions depend only on memcmp()
so they can be seen to be safe, whereas it's a whole lot less
clear that text_cmp() should be considered leakproof.
12 matches
Mail list logo
