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.
>>
>> And nothing has happened since, the patch rotting a bit because of a
>> conflict in
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 TAP tests. Attached is a rebased version.
Moved to CF
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 and new one, and confirmed the applied source
>>> passed the tests successfully. And
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 also checked manually the error
>> messages were emitted succe
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 in dbname or rolename or
> data
> > [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 versi
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 and make check-world
> -> got 1
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 c
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 next
> step, then, is f
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 of readers
> >> who
> >> would benefit from thi
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 CR
> will be unsupported in a
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 suffices. For everyone
>> else, it would just dil
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 other parts of
> our do
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 characters, but there is no systemati
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 is
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
clean up PGDATA in this
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 psql and shell. So attached is a patc
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 patch to implement this
>> restrict
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 add
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 psql and shell. So attached is a patc
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 s
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
> characters) is known to have security implicat
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, FWIW. There is an
interesting
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 supported. Look for
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
> restriction in the backen
26 matches
Mail list logo
