On Wed, Feb 1, 2017 at 1:31 PM, Michael Paquier
wrote:
> On Wed, Feb 1, 2017 at 1:31 PM, Michael Paquier
> wrote:
>> On Tue, Nov 29, 2016 at 1:33 PM, Michael Paquier
>> wrote:
>>> Patch moved to CF 2017-01.
>>
>>
On Wed, Feb 1, 2017 at 1:31 PM, Michael Paquier
wrote:
> On Tue, Nov 29, 2016 at 1:33 PM, Michael Paquier
> wrote:
>> Patch moved to CF 2017-01.
>
> And nothing has happened since, the patch rotting a bit because of a
> conflict in pg_dump's
On Tue, Nov 29, 2016 at 1:33 PM, Michael Paquier
wrote:
> On Fri, Nov 25, 2016 at 4:41 PM, Michael Paquier
> wrote:
>> On Fri, Nov 25, 2016 at 4:02 PM, Ideriha, Takeshi
>> wrote:
>>> I applied your fixed patch
On Fri, Nov 25, 2016 at 4:41 PM, Michael Paquier
wrote:
> On Fri, Nov 25, 2016 at 4:02 PM, Ideriha, Takeshi
> wrote:
>> I applied your fixed patch and new one, and confirmed the applied source
>> passed the tests successfully. And I
On Fri, Nov 25, 2016 at 4:02 PM, Ideriha, Takeshi
wrote:
> I applied your fixed patch and new one, and confirmed the applied source
> passed the tests successfully. And I also checked manually the error messages
> were emitted successfully when cr/lf are included
> > [Summary]
> > 1. apply patch and make world
> > -> failed because was mistakenly coded .
> >
> > 2.correct this mistake and make check-world
> > -> got 1 failed test: "'pg_dumpall with \n\r in database name'"
> > because test script cannot createdb "foo\n\rbar"
>
> The attached
On Tue, Nov 22, 2016 at 5:55 PM, Ideriha, Takeshi
wrote:
> Here's a summary for what I tested in RHEL7.0, details follow.
Thanks for the review.
> [Summary]
> 1. apply patch and make world
> -> failed because was mistakenly coded .
>
> 2.correct this mistake
Hi,
Here's a summary for what I tested in RHEL7.0, details follow.
[Summary]
1. apply patch and make world
-> failed because was mistakenly coded .
2.correct this mistake and make check-world
-> got 1 failed test: "'pg_dumpall with \n\r in database name'"
because test script cannot
On Tue, Oct 11, 2016 at 11:00 AM, Noah Misch wrote:
> I count one person disfavoring the patch concept of rejecting these characters
> early, and I count two people, plus yourself as author, favoring it.
> Therefore, the patch can move forward with the proposed design. The
On Sun, Oct 02, 2016 at 10:47:04PM +0900, Michael Paquier wrote:
> On Mon, Sep 12, 2016 at 11:38 AM, Michael Paquier
> wrote:
> > On Mon, Sep 12, 2016 at 10:01 AM, Noah Misch wrote:
> >> I discourage documenting LF/CR restrictions. For the epsilon
On Sun, Oct 2, 2016 at 10:47 PM, Michael Paquier
wrote:
> And seeing nothing happening here, I still don't know what to do with
> this patch. Thoughts? If we are going to do nothing I would suggest to
> just remove the comment in string_utils.c saying that such LF and
On Mon, Sep 12, 2016 at 11:38 AM, Michael Paquier
wrote:
> On Mon, Sep 12, 2016 at 10:01 AM, Noah Misch wrote:
>> I discourage documenting LF/CR restrictions. For the epsilon of readers who
>> would benefit from this knowledge, the error message
On Mon, Sep 12, 2016 at 10:01 AM, Noah Misch wrote:
> I discourage documenting LF/CR restrictions. For the epsilon of readers who
> would benefit from this knowledge, the error message suffices. For everyone
> else, it would just dilute the text. (One could argue against
On Thu, Sep 08, 2016 at 12:12:49PM -0400, Peter Eisentraut wrote:
> On 9/6/16 1:42 PM, Robert Haas wrote:
> > On Tue, Sep 6, 2016 at 9:43 PM, Peter Eisentraut
> > wrote:
> > > Everything that is using appendShellString() is now going to reject LF
> > > and CR
On 9/6/16 1:42 PM, Robert Haas wrote:
> If we were talking about pathnames containing spaces, I would agree,
> but I've never heard of a legitimate pathname containing CR or LF. I
> can't see us losing much by refusing to allow such pathnames, except
> for security holes.
The flip side of that
On Wed, Sep 7, 2016 at 2:32 AM, Tom Lane wrote:
> I think probably a better answer is to reject bad paths earlier, eg have
> initdb error out before doing anything if the proposed -D path contains
> CR/LF.
Yes, that's a bug that we had better address. It is not nice to not
On Tue, Sep 6, 2016 at 9:43 PM, Peter Eisentraut
wrote:
> On 8/11/16 9:12 PM, Michael Paquier wrote:
>> Note that pg_dump[all] and pg_upgrade already have safeguards against
>> those things per the same routines putting quotes for execution as
>> commands into
Peter Eisentraut writes:
> On 8/11/16 9:12 PM, Michael Paquier wrote:
>> Note that pg_dump[all] and pg_upgrade already have safeguards against
>> those things per the same routines putting quotes for execution as
>> commands into psql and shell. So attached is a
On 8/11/16 9:12 PM, Michael Paquier wrote:
> Note that pg_dump[all] and pg_upgrade already have safeguards against
> those things per the same routines putting quotes for execution as
> commands into psql and shell. So attached is a patch to implement this
> restriction in the backend, and I am
On Fri, Sep 2, 2016 at 2:44 AM, Peter Eisentraut
wrote:
> On 8/11/16 9:12 PM, Michael Paquier wrote:
>> Note that pg_dump[all] and pg_upgrade already have safeguards against
>> those things per the same routines putting quotes for execution as
>> commands into
On 8/11/16 9:12 PM, Michael Paquier wrote:
> Note that pg_dump[all] and pg_upgrade already have safeguards against
> those things per the same routines putting quotes for execution as
> commands into psql and shell. So attached is a patch to implement this
> restriction in the backend,
How about
Peter Geoghegan writes:
> On Mon, Aug 22, 2016 at 6:28 PM, Michael Paquier
> wrote:
>> There is no need to put restrictions on those I think, and they are
>> actually supported.
> Bi-directional text support (i.e., the use of right-to-left control
>
On Mon, Aug 22, 2016 at 6:28 PM, Michael Paquier
wrote:
> There is no need to put restrictions on those I think, and they are
> actually supported.
Bi-directional text support (i.e., the use of right-to-left control
characters) is known to have security implications,
On Tue, Aug 23, 2016 at 10:19 AM, Peter Geoghegan wrote:
> I haven't looked at the patch, but offhand I wonder if it's worth
> considering control characters added by unicode, if you haven't already.
There is no need to put restrictions on those I think, and they are
actually
I haven't looked at the patch, but offhand I wonder if it's worth
considering control characters added by unicode, if you haven't already.
--
Peter Geoghegan
On Fri, Aug 12, 2016 at 10:12 AM, Michael Paquier
wrote:
> Note that pg_dump[all] and pg_upgrade already have safeguards against
> those things per the same routines putting quotes for execution as
> commands into psql and shell. So attached is a patch to implement this
Hi all,
As CVE-2016-5424 has put recently in light, using LF and CR in
database and role names can lead to unexpected problems in the way
they are handled in logical backups or generated command lines. There
is as well a comment in the code mentioning a potential restriction
for that, precisely
27 matches
Mail list logo