On 3/28/20 1:45 PM, Tom Lane wrote:
> Andreas Karlsson writes:
>> On 3/22/20 1:08 AM, Andrew Dunstan wrote:
>>> Latest patch attached, I think all comments have been addressed. I
>>> propose to push this later this coming week if there are no more comments.
>> I do not have any objections.
>
Andreas Karlsson writes:
> On 3/22/20 1:08 AM, Andrew Dunstan wrote:
>> Latest patch attached, I think all comments have been addressed. I
>> propose to push this later this coming week if there are no more comments.
> I do not have any objections.
This CF entry is still open, should it not be
On 3/22/20 1:08 AM, Andrew Dunstan wrote:
Latest patch attached, I think all comments have been addressed. I
propose to push this later this coming week if there are no more comments.
I do not have any objections.
Andreas
On 3/21/20 9:18 AM, Andrew Dunstan wrote:
> On 3/19/20 4:10 AM, asaba.takan...@fujitsu.com wrote:
>
>
>
>> Trailing space:
>>
>> 220 + X509v3 Subject Key Identifier:
>> 222 + X509v3 Authority Key Identifier:
>
> We're going to remove all the text, so this becomes moot.
>
>
>>
On 3/19/20 4:10 AM, asaba.takan...@fujitsu.com wrote:
> Trailing space:
>
> 220 + X509v3 Subject Key Identifier:
> 222 + X509v3 Authority Key Identifier:
We're going to remove all the text, so this becomes moot.
>
> Missing "d"(password?):
>
> 121 +/* init hook for
On 3/15/20 10:14 PM, Andreas Karlsson wrote:
> On 2/18/20 11:39 PM, Andrew Dunstan wrote:
>> This should fix the issue, it happened when I switched to using a
>> pre-generated cert/key.
>
> # Review
>
> The patch still applies and passes the test suite, both with openssl
> enabled and with it
Hello Andrew,
From: Andreas Karlsson
> # Nitpicking
>
> The certificate expires in 2030 while all other certificates used in
> tests expires in 2046. Should we be consistent?
>
> There is text in server.crt and server.key, while other certificates and
> keys used in the tests do not have this.
On 2/18/20 11:39 PM, Andrew Dunstan wrote:
This should fix the issue, it happened when I switched to using a
pre-generated cert/key.
# Review
The patch still applies and passes the test suite, both with openssl
enabled and with it disabled.
As for the feature I agree that it is nice to
On Wed, Feb 19, 2020 at 7:10 AM Andrew Dunstan
wrote:
>
> On Tue, Feb 18, 2020 at 2:01 PM Thomas Munro wrote:
> >
> > On Wed, Jan 22, 2020 at 8:02 PM Andrew Dunstan
> > wrote:
> > > Not sure if the placement is what you want, but maybe something like this?
> >
> > Hi Andrew, FYI this failed
On Tue, Feb 18, 2020 at 2:01 PM Thomas Munro wrote:
>
> On Wed, Jan 22, 2020 at 8:02 PM Andrew Dunstan
> wrote:
> > Not sure if the placement is what you want, but maybe something like this?
>
> Hi Andrew, FYI this failed here:
>
> t/001_testfunc.pl .. Bailout called. Further testing stopped:
On Wed, Jan 22, 2020 at 8:02 PM Andrew Dunstan
wrote:
> Not sure if the placement is what you want, but maybe something like this?
Hi Andrew, FYI this failed here:
t/001_testfunc.pl .. Bailout called. Further testing stopped: pg_ctl
start failed
FAILED--Further testing stopped: pg_ctl start
On Thu, Nov 14, 2019 at 8:54 AM Sehrope Sarkuni wrote:
> Has the idea of using environment variables (rather than command line
> args) for external commands been brought up before? I couldn't find
> anything in the mailing list archives.
Passing data through environment variables isn't secure.
On Sun, Dec 8, 2019 at 9:02 AM Tom Lane wrote:
>
> Andrew Dunstan writes:
> > Well that pretty much brings us back to the patch as submitted :-)
>
> Yeah, pretty nearly. Taking a quick look over the v3 patch, my
> only quibble is that it doesn't provide any convenient way for the
> external
On Sat, 7 Dec 2019 at 07:21, Tom Lane wrote:
> Andrew Dunstan writes:
> > I've just been looking at that. load_external_function() doesn't
> > actually do anything V1-ish with the value, it just looks up the symbol
> > using dlsym and returns it cast to a PGFunction. Is there any reason I
> >
Andrew Dunstan writes:
> Well that pretty much brings us back to the patch as submitted :-)
Yeah, pretty nearly. Taking a quick look over the v3 patch, my
only quibble is that it doesn't provide any convenient way for the
external module to make decisions about how to interact with
On 12/7/19 12:16 PM, Tom Lane wrote:
> Andrew Dunstan writes:
>> Bruce was worried about what would happen if we defined both
>> ssl_passphrase_command and ssl_passphrase_callback. The submitted patch
>> let's the callback have precedence, but it might be cleaner to error out
>> with such a
Andrew Dunstan writes:
> Bruce was worried about what would happen if we defined both
> ssl_passphrase_command and ssl_passphrase_callback. The submitted patch
> let's the callback have precedence, but it might be cleaner to error out
> with such a config. OTOH, that wouldn't be so nice on a
On 12/6/19 6:20 PM, Tom Lane wrote:
> Andrew Dunstan writes:
>> I've just been looking at that. load_external_function() doesn't
>> actually do anything V1-ish with the value, it just looks up the symbol
>> using dlsym and returns it cast to a PGFunction. Is there any reason I
>> can't just use
Andrew Dunstan writes:
> I've just been looking at that. load_external_function() doesn't
> actually do anything V1-ish with the value, it just looks up the symbol
> using dlsym and returns it cast to a PGFunction. Is there any reason I
> can't just use that and cast it again to the callback
On 11/15/19 8:59 AM, Andrew Dunstan wrote:
> On 11/14/19 3:21 PM, Alvaro Herrera wrote:
>> On 2019-Nov-14, Andrew Dunstan wrote:
>>
>>> I guess this would work. There would have to be a deal of code to load
>>> the library and lookup the symbol. Do we really think it's worth it?
>>> Leveraging
On Fri, 15 Nov 2019 at 00:34, Andrew Dunstan
wrote:
>
> On 11/14/19 11:07 AM, Bruce Momjian wrote:
> > On Thu, Nov 14, 2019 at 11:42:05AM +0100, Magnus Hagander wrote:
> >> On Wed, Nov 13, 2019 at 9:23 PM Tomas Vondra <
> tomas.von...@2ndquadrant.com>
> >> I think it would be beneficial to
On 11/14/19 3:21 PM, Alvaro Herrera wrote:
> On 2019-Nov-14, Andrew Dunstan wrote:
>
>> I guess this would work. There would have to be a deal of code to load
>> the library and lookup the symbol. Do we really think it's worth it?
>> Leveraging shared_preload_libraries makes this comparatively
On 2019-Nov-14, Andrew Dunstan wrote:
> I guess this would work. There would have to be a deal of code to load
> the library and lookup the symbol. Do we really think it's worth it?
> Leveraging shared_preload_libraries makes this comparatively simple.
Using the generic interface has the
On 11/14/19 12:07 PM, Alvaro Herrera wrote:
> On 2019-Nov-14, Bruce Momjian wrote:
>
>> I was assuming if the variable starts with a #, it is a shared object,
>> if not, it is a shell command:
>>
>> ssl_passphrase_command='#/lib/x.so'
>> ssl_passphrase_command='my_command a b c'
> Note
On Thu, Nov 14, 2019 at 02:07:58PM -0300, Alvaro Herrera wrote:
> On 2019-Nov-14, Bruce Momjian wrote:
>
> > I was assuming if the variable starts with a #, it is a shared object,
> > if not, it is a shell command:
> >
> > ssl_passphrase_command='#/lib/x.so'
> >
On 2019-Nov-14, Bruce Momjian wrote:
> I was assuming if the variable starts with a #, it is a shared object,
> if not, it is a shell command:
>
> ssl_passphrase_command='#/lib/x.so'
> ssl_passphrase_command='my_command a b c'
Note that the proposed patch doesn't use a separate GUC
On Thu, Nov 14, 2019 at 11:34:24AM -0500, Andrew Dunstan wrote:
>
> On 11/14/19 11:07 AM, Bruce Momjian wrote:
> > On Thu, Nov 14, 2019 at 11:42:05AM +0100, Magnus Hagander wrote:
> >> On Wed, Nov 13, 2019 at 9:23 PM Tomas Vondra
> >> I think it would be beneficial to explain why shared
On Thu, Nov 14, 2019 at 11:34:24AM -0500, Andrew Dunstan wrote:
On 11/14/19 11:07 AM, Bruce Momjian wrote:
On Thu, Nov 14, 2019 at 11:42:05AM +0100, Magnus Hagander wrote:
On Wed, Nov 13, 2019 at 9:23 PM Tomas Vondra
I think it would be beneficial to explain why shared object is more
On 11/14/19 11:07 AM, Bruce Momjian wrote:
> On Thu, Nov 14, 2019 at 11:42:05AM +0100, Magnus Hagander wrote:
>> On Wed, Nov 13, 2019 at 9:23 PM Tomas Vondra
>> I think it would be beneficial to explain why shared object is more
>> secure than an OS command. Perhaps it's common
On Thu, Nov 14, 2019 at 11:42:05AM +0100, Magnus Hagander wrote:
> On Wed, Nov 13, 2019 at 9:23 PM Tomas Vondra
> I think it would be beneficial to explain why shared object is more
> secure than an OS command. Perhaps it's common knowledge, but it's not
> quite obvious to me.
>
>
>
On Wed, Nov 13, 2019 at 3:23 PM Tomas Vondra
wrote:
> I think it would be beneficial to explain why shared object is more
> secure than an OS command. Perhaps it's common knowledge, but it's not
> quite obvious to me.
External command args can be viewed by other OS users (not just the
postgres
On Wed, Nov 13, 2019 at 9:23 PM Tomas Vondra
wrote:
> On Wed, Nov 13, 2019 at 01:20:43PM +, Simon Riggs wrote:
> >On Wed, 13 Nov 2019 at 13:08, Bruce Momjian wrote:
> >
> >> On Tue, Nov 12, 2019 at 09:51:33PM -0500, Bruce Momjian wrote:
> >> > On Sun, Nov 10, 2019 at 01:01:17PM -0600,
On Wed, Nov 13, 2019 at 02:48:01PM -0500, Andrew Dunstan wrote:
On 11/13/19 8:08 AM, Bruce Momjian wrote:
Also, why was this patch posted without any discussion of these issues?
Shouldn't we ideally discuss the API first?
This is a very tiny patch. I don't think it's unusual to post such
On Wed, Nov 13, 2019 at 01:20:43PM +, Simon Riggs wrote:
On Wed, 13 Nov 2019 at 13:08, Bruce Momjian wrote:
On Tue, Nov 12, 2019 at 09:51:33PM -0500, Bruce Momjian wrote:
> On Sun, Nov 10, 2019 at 01:01:17PM -0600, Magnus Hagander wrote:
> > On Wed, Nov 6, 2019 at 7:24 PM Bruce Momjian
On 11/13/19 8:08 AM, Bruce Momjian wrote:
>
>>
>> Also, why was this patch posted without any discussion of these issues?
>> Shouldn't we ideally discuss the API first?
This is a very tiny patch. I don't think it's unusual to post such
things without prior discussion. I would agree with your
On Wed, 13 Nov 2019 at 13:08, Bruce Momjian wrote:
> On Tue, Nov 12, 2019 at 09:51:33PM -0500, Bruce Momjian wrote:
> > On Sun, Nov 10, 2019 at 01:01:17PM -0600, Magnus Hagander wrote:
> > > On Wed, Nov 6, 2019 at 7:24 PM Bruce Momjian wrote:
>
> > > One of the main reasons there being to be
On Tue, Nov 12, 2019 at 09:51:33PM -0500, Bruce Momjian wrote:
> On Sun, Nov 10, 2019 at 01:01:17PM -0600, Magnus Hagander wrote:
> > On Wed, Nov 6, 2019 at 7:24 PM Bruce Momjian wrote:
> > We had this
> > discussion in relation to archive_command years ago, and decided on a
> >
On Sun, Nov 10, 2019 at 01:01:17PM -0600, Magnus Hagander wrote:
> On Wed, Nov 6, 2019 at 7:24 PM Bruce Momjian wrote:
> We had this
> discussion in relation to archive_command years ago, and decided on a
> shell command as the best API.
>
> I don't recall that from back then, but
On 11/7/19 12:30 PM, Andrew Dunstan wrote:
> On 11/4/19 4:43 PM, Thomas Munro wrote:
>> It looks like the new declarations in libpq-be.h are ifdef'd out in a
>> non-USE_SSL build, but then we still try to build the new test module
>> and it fails:
>>
>>
On Wed, Nov 6, 2019 at 7:24 PM Bruce Momjian wrote:
> On Fri, Nov 1, 2019 at 01:57:29PM -0400, Andrew Dunstan wrote:
> >
> > On 11/1/19 11:01 AM, Robert Haas wrote:
> > > On Thu, Oct 31, 2019 at 11:37 AM Andrew Dunstan
> > > wrote:
> > >> This patch provides a hook for a function that can
On Fri, Nov 08, 2019 at 11:12:08PM +0900, Simon Riggs wrote:
On Thu, 7 Nov 2019 at 10:24, Bruce Momjian wrote:
What is the value of a shared library over a shell command? We had
this discussion in relation to archive_command years ago, and decided
on a shell command as the best API.
I
On Thu, 7 Nov 2019 at 10:24, Bruce Momjian wrote:
> What is the value of a shared library over a shell command? We had this
> discussion in relation to archive_command years ago, and decided on a
> shell command as the best API.
>
I don't recall such a discussion, but I can give perspective:
On 11/4/19 4:43 PM, Thomas Munro wrote:
>
> It looks like the new declarations in libpq-be.h are ifdef'd out in a
> non-USE_SSL build, but then we still try to build the new test module
> and it fails:
>
> https://ci.appveyor.com/project/postgresql-cfbot/postgresql/build/1.0.64071
I think this
On Fri, Nov 1, 2019 at 01:57:29PM -0400, Andrew Dunstan wrote:
>
> On 11/1/19 11:01 AM, Robert Haas wrote:
> > On Thu, Oct 31, 2019 at 11:37 AM Andrew Dunstan
> > wrote:
> >> This patch provides a hook for a function that can supply an SSL
> >> passphrase. The hook can be filled in by a shared
On Sat, Nov 2, 2019 at 6:57 AM Andrew Dunstan
wrote:
> On 11/1/19 11:01 AM, Robert Haas wrote:
> > On Thu, Oct 31, 2019 at 11:37 AM Andrew Dunstan
> > wrote:
> >> This patch provides a hook for a function that can supply an SSL
> >> passphrase. The hook can be filled in by a shared preloadable
On 11/1/19 11:01 AM, Robert Haas wrote:
> On Thu, Oct 31, 2019 at 11:37 AM Andrew Dunstan
> wrote:
>> This patch provides a hook for a function that can supply an SSL
>> passphrase. The hook can be filled in by a shared preloadable module. In
>> order for that to be effective, the startup order
On Thu, Oct 31, 2019 at 11:37 AM Andrew Dunstan
wrote:
> This patch provides a hook for a function that can supply an SSL
> passphrase. The hook can be filled in by a shared preloadable module. In
> order for that to be effective, the startup order is modified slightly.
> There is a test attached
This is the first of a number of patches to enhance SSL functionality,
particularly w.r.t. passphrases.
This patch provides a hook for a function that can supply an SSL
passphrase. The hook can be filled in by a shared preloadable module. In
order for that to be effective, the startup order is
48 matches
Mail list logo
