> On 4 Feb 2022, at 21:03, Stephen Frost wrote:
> I wonder about the 'not in tree' bit since it is in the header files,
> certainly for NSPR which I've been poking at due to this discussion.
What I meant was that the documentation on the website isn't published from
documentation source code (in
Greetings,
* Daniel Gustafsson (dan...@yesql.se) wrote:
> I am writing done above in quotes, since the documentation also needs to be
> updated, completed, rewritten, organized etc etc. The above is an import of
> what was found, and is in a fairly poor state. Unfortunately, it's still not
> in
Greetings,
* Bruce Momjian (br...@momjian.us) wrote:
> On Thu, Feb 3, 2022 at 02:33:37PM -0500, Robert Haas wrote:
> > As a philosophical matter, I don't think it's great for us - or the
> > Internet in general - to be too dependent on OpenSSL. Software
> > monocultures are not great, and OpenSSL
Greetings,
* Bruce Momjian (br...@momjian.us) wrote:
> On Thu, Feb 3, 2022 at 01:42:53PM -0500, Stephen Frost wrote:
> > * Bruce Momjian (br...@momjian.us) wrote:
> > > On Tue, Feb 1, 2022 at 01:52:09PM -0800, Andres Freund wrote:
> > > > There's https://hg.mozilla.org/projects/nspr/file/tip/pr/
> On 4 Feb 2022, at 19:22, Bruce Momjian wrote:
>
> On Thu, Feb 3, 2022 at 02:33:37PM -0500, Robert Haas wrote:
>> As a philosophical matter, I don't think it's great for us - or the
>> Internet in general - to be too dependent on OpenSSL. Software
>> monocultures are not great, and OpenSSL has
On Fri, Feb 4, 2022 at 01:33:00PM -0500, Robert Haas wrote:
> > I don't think it is fair to be criticizing OpenSSL for its mediocre
> > documentation when the alternative being considered, NSS, has no public
> > documentation. Can the source-code-defined NSS documentation be
> > considered better
On Fri, Feb 4, 2022 at 1:22 PM Bruce Momjian wrote:
> On Thu, Feb 3, 2022 at 02:33:37PM -0500, Robert Haas wrote:
> > As a philosophical matter, I don't think it's great for us - or the
> > Internet in general - to be too dependent on OpenSSL. Software
> > monocultures are not great, and OpenSSL
On Thu, Feb 3, 2022 at 02:33:37PM -0500, Robert Haas wrote:
> As a philosophical matter, I don't think it's great for us - or the
> Internet in general - to be too dependent on OpenSSL. Software
> monocultures are not great, and OpenSSL has near-constant security
> updates and mediocre documentati
On Thu, Feb 3, 2022 at 01:42:53PM -0500, Stephen Frost wrote:
> Greetings,
>
> * Bruce Momjian (br...@momjian.us) wrote:
> > On Tue, Feb 1, 2022 at 01:52:09PM -0800, Andres Freund wrote:
> > > There's https://hg.mozilla.org/projects/nspr/file/tip/pr/src - which is I
> > > think the upstream sour
On Thu, Feb 3, 2022 at 2:16 PM Peter Eisentraut
wrote:
> If we want simply an alternative, we had a GnuTLS variant almost done a
> few years ago, but in the end people didn't want it enough. It seems to
> be similar now.
Yeah. I think it's pretty clear that the only real downside of
committing s
On 03.02.22 15:53, Daniel Gustafsson wrote:
I see quite a few valid reasons to want an alternative, a few off the top of my
head include:
- Using trust stores like Keychain on macOS with Secure Transport. There is
AFAIK something similar on Windows and NSS has it's certificate databases.
Especi
Greetings,
* Daniel Gustafsson (dan...@yesql.se) wrote:
> > On 3 Feb 2022, at 15:07, Peter Eisentraut
> > wrote:
> >
> > On 28.01.22 15:30, Robert Haas wrote:
> >> I would really, really like to have an alternative to OpenSSL for PG.
> >
> > What are the reasons people want that? With OpenSSL
Greetings,
* Bruce Momjian (br...@momjian.us) wrote:
> On Tue, Feb 1, 2022 at 01:52:09PM -0800, Andres Freund wrote:
> > There's https://hg.mozilla.org/projects/nspr/file/tip/pr/src - which is I
> > think the upstream source.
> >
> > A project without even a bare-minimal README at the root does
> On 3 Feb 2022, at 15:07, Peter Eisentraut
> wrote:
>
> On 28.01.22 15:30, Robert Haas wrote:
>> I would really, really like to have an alternative to OpenSSL for PG.
>
> What are the reasons people want that? With OpenSSL 3, the main reasons --
> license and FIPS support -- have gone away.
On 28.01.22 15:30, Robert Haas wrote:
I would really, really like to have an alternative to OpenSSL for PG.
What are the reasons people want that? With OpenSSL 3, the main reasons
-- license and FIPS support -- have gone away.
On Tue, Feb 1, 2022 at 01:52:09PM -0800, Andres Freund wrote:
> There's https://hg.mozilla.org/projects/nspr/file/tip/pr/src - which is I
> think the upstream source.
>
> A project without even a bare-minimal README at the root does have a "internal
> only" feel to it...
I agree --- it is a libr
Hi,
On 2022-02-01 15:12:28 -0500, Stephen Frost wrote:
> The concern about the documentation not being easily available is
> certainly something to consider. I remember in prior reviews not having
> that much difficulty looking up documentation for functions
I've definitely several times in the
Greetings,
* Daniel Gustafsson (dan...@yesql.se) wrote:
> > On 31 Jan 2022, at 22:48, Daniel Gustafsson wrote:
> >> On 31 Jan 2022, at 17:24, Stephen Frost wrote:
>
> >> I agree that it's concerning to hear that OpenLDAP dropped support for
> >> NSS... though I don't seem to be able to find any
> On 31 Jan 2022, at 22:48, Daniel Gustafsson wrote:
>> On 31 Jan 2022, at 17:24, Stephen Frost wrote:
>> I agree that it's concerning to hear that OpenLDAP dropped support for
>> NSS... though I don't seem to be able to find any information as to why
>> they decided to do so.
>
> I was also un
> On 31 Jan 2022, at 22:32, Andres Freund wrote:
>
> Hi,
>
> On 2022-01-31 14:24:03 +0100, Daniel Gustafsson wrote:
>>> On 28 Jan 2022, at 15:30, Robert Haas wrote:
>>> I would really, really like to have an alternative to OpenSSL for PG.
>>> I don't know if this is the right thing, though. If
> On 31 Jan 2022, at 17:24, Stephen Frost wrote:
> * Daniel Gustafsson (dan...@yesql.se) wrote:
>> I'm counting this and Andres' comment as a -1 on the patchset, and given
>> where
>> we are in the cycle I'm mark it rejected in the CF app shortly unless anyone
>> objects.
>
> I agree that it's
Hi,
On 2022-01-31 14:24:03 +0100, Daniel Gustafsson wrote:
> > On 28 Jan 2022, at 15:30, Robert Haas wrote:
> > I would really, really like to have an alternative to OpenSSL for PG.
> > I don't know if this is the right thing, though. If other people are
> > dropping support for it, that's a pret
Greetings,
* Daniel Gustafsson (dan...@yesql.se) wrote:
> > On 28 Jan 2022, at 15:30, Robert Haas wrote:
> > On Fri, Jan 28, 2022 at 9:08 AM Daniel Gustafsson wrote:
> >>> Kinda makes me question the wisdom of starting to depend on NSS. When
> >>> openssl
> >>> docs are vastly outshining a libr
> On 28 Jan 2022, at 15:30, Robert Haas wrote:
>
> On Fri, Jan 28, 2022 at 9:08 AM Daniel Gustafsson wrote:
>>> Kinda makes me question the wisdom of starting to depend on NSS. When
>>> openssl
>>> docs are vastly outshining a library's, that library really should start to
>>> ask itself some h
> On 28 Jan 2022, at 15:30, Robert Haas wrote:
>
> On Fri, Jan 28, 2022 at 9:08 AM Daniel Gustafsson wrote:
>>> Kinda makes me question the wisdom of starting to depend on NSS. When
>>> openssl
>>> docs are vastly outshining a library's, that library really should start to
>>> ask itself some h
On Fri, Jan 28, 2022 at 9:08 AM Daniel Gustafsson wrote:
> > Kinda makes me question the wisdom of starting to depend on NSS. When
> > openssl
> > docs are vastly outshining a library's, that library really should start to
> > ask itself some hard questions.
Yeah, OpenSSL is very poor, so being
>>> Can we propose a patch to document them? Don't want to get bitten by this
>>> suddenly changing...
>>
>> I can certainly propose something on their mailinglist, but I unfortunately
>> wouldn't get my hopes up too high as NSS and documentation aren't exactly
>> best
>> friends (the in-tree doc
On Wed, 2022-01-26 at 15:59 -0800, Andres Freund wrote:
> > > Do we have a testcase for embedded NULLs in common names?
> >
> > We don't, neither for OpenSSL or NSS. AFAICR Jacob spent days trying to
> > get a
> > certificate generation to include an embedded NULL byte but in the end gave
> > u
Hi,
On 2022-01-26 21:39:16 +0100, Daniel Gustafsson wrote:
> > What about
> > reconfiguring (note: add --enable-depend) the linux tasks to build against
> > nss, and then run the relevant subset of tests with it? Most tests don't
> > use
> > tcp / SSL anyway, so rerunning a small subset of tests
On Tue, 2022-01-25 at 22:26 +, Jacob Champion wrote:
> On Wed, 2022-01-19 at 10:01 +0100, Daniel Gustafsson wrote:
> > > On 18 Jan 2022, at 17:37, Jacob Champion wrote:
> > >
> > > On Wed, 2021-12-15 at 23:10 +0100, Daniel Gustafsson wrote:
> > > > I've attached a v50 which fixes the issues f
On Wed, 2022-01-19 at 10:01 +0100, Daniel Gustafsson wrote:
> > On 18 Jan 2022, at 17:37, Jacob Champion wrote:
> >
> > On Wed, 2021-12-15 at 23:10 +0100, Daniel Gustafsson wrote:
> > > I've attached a v50 which fixes the issues found by Joshua upthread, as
> > > well as
> > > rebases on top of
Hi,
On 2022-01-18 13:42:54 +0100, Daniel Gustafsson wrote:
> Fixed, I had made a mistake in the OpenSSL.pm testcode and failed to catch it
> in testing.
> +task:
> + name: Linux - Debian Bullseye (nss)
> [ copy of a bunch of code ]
I also needed similar-but-not-quite-equivalent tasks for the m
> On 18 Jan 2022, at 17:37, Jacob Champion wrote:
>
> On Wed, 2021-12-15 at 23:10 +0100, Daniel Gustafsson wrote:
>> I've attached a v50 which fixes the issues found by Joshua upthread, as well
>> as
>> rebases on top of all the recent SSL and pgcrypto changes.
>
> I'm currently tracking down a
On Wed, 2021-12-15 at 23:10 +0100, Daniel Gustafsson wrote:
> I've attached a v50 which fixes the issues found by Joshua upthread, as well
> as
> rebases on top of all the recent SSL and pgcrypto changes.
I'm currently tracking down a slot leak. When opening and closing large
numbers of NSS datab
On Tue, Jan 18, 2022 at 7:43 AM Daniel Gustafsson wrote:
>
> > On 18 Jan 2022, at 07:36, Julien Rouhaud wrote:
>
> > On Mon, Jan 17, 2022 at 03:09:11PM +0100, Daniel Gustafsson wrote:
> >>
> >> I must've fat-fingered the "git add -p" for v50 as the fix was in
> >> configure.ac
> >> but not confi
Hi,
On Mon, Jan 17, 2022 at 03:09:11PM +0100, Daniel Gustafsson wrote:
>
> I must've fat-fingered the "git add -p" for v50 as the fix was in configure.ac
> but not configure. Fixed now.
Thanks! Apparently this version now fails on all OS, e.g.:
https://cirrus-ci.com/task/4643868095283200
[22:
Hi,
On Wed, Dec 15, 2021 at 11:10:14PM +0100, Daniel Gustafsson wrote:
>
> I've attached a v50 which fixes the issues found by Joshua upthread, as well
> as
> rebases on top of all the recent SSL and pgcrypto changes.
The cfbot reports that the patchset doesn't apply anymore:
http://cfbot.cput
On Wed, Dec 15, 2021 at 5:05 PM Daniel Gustafsson wrote:
>
> > On 25 Nov 2021, at 14:39, Joshua Brindle
> > wrote:
> > On Wed, Nov 24, 2021 at 8:49 AM Joshua Brindle
> > wrote:
> >>
> >> On Wed, Nov 24, 2021 at 8:46 AM Joshua Brindle
> >> wrote:
>
> >> I don't know enough about NSS to know if
On Wed, 2021-12-15 at 23:10 +0100, Daniel Gustafsson wrote:
> > On 30 Nov 2021, at 20:03, Jacob Champion wrote:
> >
> > On Mon, 2021-09-27 at 15:44 +0200, Daniel Gustafsson wrote:
> > > > Speaking of IP addresses in SANs, it doesn't look like our OpenSSL
> > > > backend can handle those. That's a
> On 25 Nov 2021, at 14:39, Joshua Brindle
> wrote:
> On Wed, Nov 24, 2021 at 8:49 AM Joshua Brindle
> wrote:
>>
>> On Wed, Nov 24, 2021 at 8:46 AM Joshua Brindle
>> wrote:
>> I don't know enough about NSS to know if this is problematic or not
>> but if I try verify-full without having the ro
On Mon, 2021-09-27 at 15:44 +0200, Daniel Gustafsson wrote:
> > Speaking of IP addresses in SANs, it doesn't look like our OpenSSL
> > backend can handle those. That's a separate conversation, but I might
> > take a look at a patch for next commitfest.
>
> Please do.
Didn't get around to it for N
On Wed, Nov 24, 2021 at 8:49 AM Joshua Brindle
wrote:
>
> On Wed, Nov 24, 2021 at 8:46 AM Joshua Brindle
> wrote:
> >
> > On Wed, Nov 24, 2021 at 6:59 AM Daniel Gustafsson wrote:
> > >
> > > > On 23 Nov 2021, at 23:39, Joshua Brindle
> > > > wrote:
> > >
> > > > It no longer happens with v49,
On Wed, Nov 24, 2021 at 8:46 AM Joshua Brindle
wrote:
>
> On Wed, Nov 24, 2021 at 6:59 AM Daniel Gustafsson wrote:
> >
> > > On 23 Nov 2021, at 23:39, Joshua Brindle
> > > wrote:
> >
> > > It no longer happens with v49, since it was a null deref of the pr_fd
> > > which no longer happens.
> > >
On Wed, Nov 24, 2021 at 6:59 AM Daniel Gustafsson wrote:
>
> > On 23 Nov 2021, at 23:39, Joshua Brindle
> > wrote:
>
> > It no longer happens with v49, since it was a null deref of the pr_fd
> > which no longer happens.
> >
> > I'll continue testing now, so far it's looking better.
>
> Great, th
> On 23 Nov 2021, at 23:39, Joshua Brindle
> wrote:
> It no longer happens with v49, since it was a null deref of the pr_fd
> which no longer happens.
>
> I'll continue testing now, so far it's looking better.
Great, thanks for confirming. I'm still keen on knowing how you triggered the
segfa
On Tue, Nov 23, 2021 at 9:12 AM Daniel Gustafsson wrote:
>
> > On 17 Nov 2021, at 19:42, Joshua Brindle
> > wrote:
> > On Tue, Nov 16, 2021 at 1:26 PM Joshua Brindle
> > wrote:
>
> >> I think there it a typo in the docs here that prevents them from
> >> building (this diff seems to fix it):
>
>
On Tue, Nov 16, 2021 at 1:26 PM Joshua Brindle
wrote:
>
> On Tue, Nov 16, 2021 at 9:45 AM Joshua Brindle
> wrote:
> >
> > On Mon, Nov 15, 2021 at 5:37 PM Joshua Brindle
> > wrote:
> > >
> > > On Mon, Nov 15, 2021 at 4:44 PM Daniel Gustafsson wrote:
> > > >
> > > > > On 15 Nov 2021, at 20:51, Jo
On Tue, Nov 16, 2021 at 9:45 AM Joshua Brindle
wrote:
>
> On Mon, Nov 15, 2021 at 5:37 PM Joshua Brindle
> wrote:
> >
> > On Mon, Nov 15, 2021 at 4:44 PM Daniel Gustafsson wrote:
> > >
> > > > On 15 Nov 2021, at 20:51, Joshua Brindle
> > > > wrote:
> > >
> > > > Apologies for the delay, this d
On Mon, Nov 15, 2021 at 5:37 PM Joshua Brindle
wrote:
>
> On Mon, Nov 15, 2021 at 4:44 PM Daniel Gustafsson wrote:
> >
> > > On 15 Nov 2021, at 20:51, Joshua Brindle
> > > wrote:
> >
> > > Apologies for the delay, this didn't go to my inbox and I missed it on
> > > list.
> > >
> > > The bitcod
On Mon, Nov 15, 2021 at 4:44 PM Daniel Gustafsson wrote:
>
> > On 15 Nov 2021, at 20:51, Joshua Brindle
> > wrote:
>
> > Apologies for the delay, this didn't go to my inbox and I missed it on list.
> >
> > The bitcode generation is still broken, this time for nspr.h:
>
> Interesting, I am unable
> On 15 Nov 2021, at 20:51, Joshua Brindle
> wrote:
> Apologies for the delay, this didn't go to my inbox and I missed it on list.
>
> The bitcode generation is still broken, this time for nspr.h:
Interesting, I am unable to replicate that in my tree but I'll investigate
further tomorrow using
On Wed, Nov 10, 2021 at 8:49 AM Daniel Gustafsson wrote:
>
> > On 9 Nov 2021, at 22:22, Joshua Brindle
> > wrote:
> > On Tue, Nov 9, 2021 at 2:02 PM Joshua Brindle
> > wrote:
> >>
> >> On Tue, Nov 9, 2021 at 1:59 PM Joshua Brindle
> >> wrote:
>
> >>> Hello, I'm looking to help out with reviews
On Tue, Nov 9, 2021 at 2:02 PM Joshua Brindle
wrote:
>
> On Tue, Nov 9, 2021 at 1:59 PM Joshua Brindle
> wrote:
> >
> > On Fri, Nov 5, 2021 at 6:01 AM Daniel Gustafsson wrote:
> > >
> > > Attached is a rebase fixing a tiny bug in the documentation which
> > > prevented it
> > > from being able
On Tue, Nov 9, 2021 at 1:59 PM Joshua Brindle
wrote:
>
> On Fri, Nov 5, 2021 at 6:01 AM Daniel Gustafsson wrote:
> >
> > Attached is a rebase fixing a tiny bug in the documentation which prevented
> > it
> > from being able to compile.
> >
>
> Hello, I'm looking to help out with reviews for this
On Fri, Nov 5, 2021 at 6:01 AM Daniel Gustafsson wrote:
>
> Attached is a rebase fixing a tiny bug in the documentation which prevented it
> from being able to compile.
>
Hello, I'm looking to help out with reviews for this CF and I'm
currently looking at this patchset.
currently I'm stuck tryin
For anyone else trying to test out this branch I'm able to get the patches
to apply cleanly if I check out e.g. commit
92e6a98c3636948e7ece9a3260f9d89dd60da278.
Kevin
--
Kevin Burke
phone: 925-271-7005 | kevin.burke.dev
On Thu, Oct 28, 2021 at 9:31 PM Kevin Burke wrote:
> Hi all, apologies bu
Hi all, apologies but I'm having trouble applying the latest patch (v45) to
the latest commit on master (6b0f6f79eef2168ce38a8ee99c3ed76e3df5d7ad)
I downloaded all of the patches to my local filesystem, and then ran:
for patch in
../../kevinburke/rustls-postgres/patchsets/2021-10-05-gustafsson-ma
On Tue, 2021-10-05 at 15:08 +0200, Daniel Gustafsson wrote:
> Thanks! These changes looks good. Since you accidentally based this on v43
> and not the v44 I posted with the cryptohash fix in, the attached is a v45
> with
> both your v44 and the previous one, all rebased over HEAD.
Thanks, and s
> On 1 Oct 2021, at 02:02, Jacob Champion wrote:
> On my machine, at least, exit() is coming in due to a few calls to
> psprintf(), pstrdup(), and pg_malloc() in the new NSS code.
> (Disassembly via `objdump -S libpq.so` helped me track those down.) I'm
> working on a patch.
Ah, that makes perfe
On Thu, 2021-09-30 at 16:04 +, Jacob Champion wrote:
> On Thu, 2021-09-30 at 14:17 +0200, Daniel Gustafsson wrote:
> > The libpq libnss implementation doesn't call either of these, and neither
> > does
> > libnss.
>
> I thought the refs check only searched for direct symbol dependencies;
> is
On Thu, 2021-09-30 at 14:17 +0200, Daniel Gustafsson wrote:
> The libpq libnss implementation doesn't call either of these, and neither does
> libnss.
I thought the refs check only searched for direct symbol dependencies;
is that piece of NSPR being statically included somehow?
> I'm not entirely
On Mon, Sep 20, 2021 at 2:38 AM Daniel Gustafsson wrote:
>
> Rebased on top of HEAD with off-list comment fixes by Kevin Burke.
>
Hello Daniel,
I've been playing with your patch on Mac (OS 11.6 Big Sur) and have
run into a couple of issues so far.
1. I get 7 warnings while running make (truncat
On Mon, 2021-09-27 at 15:44 +0200, Daniel Gustafsson wrote:
> > On 21 Sep 2021, at 02:06, Jacob Champion wrote:
> > but I'm not sure that would be
> > correct either. If the user has the default sslsni="1" and supplies an
> > IP address for the host parameter, I don't think we should fail the
> >
> On 21 Sep 2021, at 02:06, Jacob Champion wrote:
>
> On Mon, 2021-07-26 at 15:26 +0200, Daniel Gustafsson wrote:
>>> On 19 Jul 2021, at 21:33, Jacob Champion wrote:
>>> ..client connections will crash if
>>> hostaddr is provided rather than host, because SSL_SetURL can't handle
>>> a NULL argum
On Mon, 2021-07-26 at 15:26 +0200, Daniel Gustafsson wrote:
> > On 19 Jul 2021, at 21:33, Jacob Champion wrote:
> > ..client connections will crash if
> > hostaddr is provided rather than host, because SSL_SetURL can't handle
> > a NULL argument. I'm running with 0002 to fix it for the moment, but
> On 18 Aug 2021, at 02:32, Michael Paquier wrote:
>
> On Wed, Aug 18, 2021 at 12:06:59AM +, Jacob Champion wrote:
>> I have a local test suite that I've been writing against libpq. With
>> the new ssldatabase connection option, one tricky aspect is figuring
>> out whether it's supported or n
On Wed, Aug 18, 2021 at 12:06:59AM +, Jacob Champion wrote:
> I have a local test suite that I've been writing against libpq. With
> the new ssldatabase connection option, one tricky aspect is figuring
> out whether it's supported or not. It doesn't look like there's any way
> to tell, from a c
On Tue, 2021-08-10 at 19:22 +0200, Daniel Gustafsson wrote:
> Another rebase to work around the recent changes in the ssl Makefile.
I have a local test suite that I've been writing against libpq. With
the new ssldatabase connection option, one tricky aspect is figuring
out whether it's supported o
On Wed, 2021-06-23 at 15:48 +0200, Daniel Gustafsson wrote:
> Attached is a rebased version which incorporates your recent patchset for
> resource handling, as well as the connect_ok test patch.
With v38 I do see the "one-time function was previously called and
failed" message you mentioned before
> On 16 Jun 2021, at 18:15, Jacob Champion wrote:
>
> On Wed, 2021-06-16 at 15:31 +0200, Daniel Gustafsson wrote:
>>> On 16 Jun 2021, at 01:50, Jacob Champion wrote:
>>> I've been tracking down reference leaks in the client. These open
>>> references prevent NSS from shutting down cleanly, which
On Wed, 2021-06-16 at 15:31 +0200, Daniel Gustafsson wrote:
> > On 16 Jun 2021, at 01:50, Jacob Champion wrote:
> > I've been tracking down reference leaks in the client. These open
> > references prevent NSS from shutting down cleanly, which then makes it
> > impossible to open a new context in t
> On 16 Jun 2021, at 01:50, Jacob Champion wrote:
> I've been tracking down reference leaks in the client. These open
> references prevent NSS from shutting down cleanly, which then makes it
> impossible to open a new context in the future. This probably affects
> other libpq clients more than it
On Wed, 2021-06-16 at 00:08 +0200, Daniel Gustafsson wrote:
> > On 15 Jun 2021, at 00:15, Jacob Champion wrote:
> > Attached is a quick patch; does it work on your machine?
>
> It does, thanks! I've included it in the attached v37 along with a few tiny
> non-functional improvements in comment sp
On Fri, 2021-05-28 at 11:04 +0200, Daniel Gustafsson wrote:
> Attached is a rebase to keep bitrot at bay.
I get a failure during one of the CRL directory tests due to a missing
database -- it looks like the Makefile is missing an entry. (I'm
dusting off my build after a few months away, so I don't
On Thu, Jun 3, 2021 at 11:14 PM Daniel Gustafsson wrote:
>
> > On 3 Jun 2021, at 23:11, Tom Lane wrote:
> >
> > Bruce Momjian writes:
> >> I wonder if we should use SSL/TLS in more places in our documentation.
> >
> > No objection to doing that in the docs; I'm just questioning
> > switching the
> On 3 Jun 2021, at 23:11, Tom Lane wrote:
>
> Bruce Momjian writes:
>> I wonder if we should use SSL/TLS in more places in our documentation.
>
> No objection to doing that in the docs; I'm just questioning
> switching the code-visible names.
As long as it's still searchable by "SSL", "TLS" a
Bruce Momjian writes:
> I wonder if we should use SSL/TLS in more places in our documentation.
No objection to doing that in the docs; I'm just questioning
switching the code-visible names.
regards, tom lane
On Thu, Jun 3, 2021 at 04:55:45PM -0400, Tom Lane wrote:
> Daniel Gustafsson writes:
> > It might also put us a hard spot if the next TLS spec ends up being called
> > something other than TLS? It's clearly happened before =)
>
> Good point. I'm inclined to just stick with the SSL terminology.
> On 3 Jun 2021, at 22:55, Tom Lane wrote:
>>> Also, do we have precedent for GUC aliases? That might be a little
>>> weird.
>
>> I don't think we do currently, but I have a feeling the topic has surfaced
>> here
>> before.
>
> We do, look for "sort_mem" in guc.c.
I knew it seemed familiar bu
Daniel Gustafsson writes:
> It might also put us a hard spot if the next TLS spec ends up being called
> something other than TLS? It's clearly happened before =)
Good point. I'm inclined to just stick with the SSL terminology.
>> Also, do we have precedent for GUC aliases? That might be a lit
> On 3 Jun 2021, at 22:14, Jeff Davis wrote:
>
> On Thu, 2021-06-03 at 15:53 -0400, Andrew Dunstan wrote:
>> Yeah, but it's annoying to have to start every talk I give touching
>> this
>> subject with the slide that says "When we say SSL we really means
>> TLS".
>> Maybe release 15 would be a goo
On Thu, 2021-06-03 at 15:53 -0400, Andrew Dunstan wrote:
> Yeah, but it's annoying to have to start every talk I give touching
> this
> subject with the slide that says "When we say SSL we really means
> TLS".
> Maybe release 15 would be a good time to rename user-visible option
> names etc, with s
On 6/3/21 1:47 PM, Daniel Gustafsson wrote:
>> On 3 Jun 2021, at 19:37, Jeff Davis wrote:
>>
>> On Tue, 2020-10-27 at 23:39 -0700, Andres Freund wrote:
>>> Maybe we should just have --with-ssl={openssl,nss}? That'd avoid
>>> needing
>>> to check for errors.
>> [ apologies for the late reply ]
>>
> On 3 Jun 2021, at 19:37, Jeff Davis wrote:
>
> On Tue, 2020-10-27 at 23:39 -0700, Andres Freund wrote:
>> Maybe we should just have --with-ssl={openssl,nss}? That'd avoid
>> needing
>> to check for errors.
>
> [ apologies for the late reply ]
>
> Would it be more proper to call it --with-tls=
On Tue, 2020-10-27 at 23:39 -0700, Andres Freund wrote:
> Maybe we should just have --with-ssl={openssl,nss}? That'd avoid
> needing
> to check for errors.
[ apologies for the late reply ]
Would it be more proper to call it --with-tls={openssl,nss} ?
Regards,
Jeff Davis
> On 25 Mar 2021, at 00:56, Jacob Champion wrote:
> Databases that are opened *after* the first one are given their own separate
> slots. Any certificates that are part of those databases seemingly can't be
> referenced directly by nickname. They have to be prefixed by their token name
> -- a
On Mon, Apr 05, 2021 at 11:12:22AM +0900, Michael Paquier wrote:
> Please find an updated set, v35, attached, and my apologies for
> breaking again your patch set. While testing this patch set and
> adjusting the SSL tests with HEAD, I have noticed what looks like a
> bug with the DN mapping that
Greetings,
* Michael Paquier (mich...@paquier.xyz) wrote:
> On Wed, Mar 31, 2021 at 10:15:15PM +, Jacob Champion wrote:
> > I think we're going to need some analogue to PQinitOpenSSL() to help
> > client applications cut through the mess, but I'm not sure what it
> > should look like, or how w
On Wed, Mar 31, 2021 at 10:15:15PM +, Jacob Champion wrote:
> I think we're going to need some analogue to PQinitOpenSSL() to help
> client applications cut through the mess, but I'm not sure what it
> should look like, or how we would maintain any sort of API
> compatibility between the two fl
On Fri, 2021-03-26 at 18:05 -0400, Stephen Frost wrote:
> * Jacob Champion (pchamp...@vmware.com) wrote:
> > Yeah. I was hoping to avoid implementing our own locks and refcounts,
> > but it seems like it's going to be required.
>
> Yeah, afraid so.
I think it gets worse, after having debugged som
Greetings,
* Jacob Champion (pchamp...@vmware.com) wrote:
> On Fri, 2021-03-26 at 15:33 -0400, Stephen Frost wrote:
> > * Jacob Champion (pchamp...@vmware.com) wrote:
> > > Databases that are opened *after* the first one are given their own
> > > separate slots. [...]
> >
> > This is more-or-less
On Fri, 2021-03-26 at 15:33 -0400, Stephen Frost wrote:
> * Jacob Champion (pchamp...@vmware.com) wrote:
> > Databases that are opened *after* the first one are given their own
> > separate slots. [...]
>
> This is more-or-less what we would want though, right..? If a user asks
> for a connection
Greetings,
* Jacob Champion (pchamp...@vmware.com) wrote:
> On Wed, 2021-03-24 at 14:10 -0400, Stephen Frost wrote:
> > * Jacob Champion (pchamp...@vmware.com) wrote:
> > > I could see this being a problem if two client certificate nicknames
> > > collide across multiple in-use databases, maybe?
>
On Fri, 2021-03-26 at 00:22 +0100, Daniel Gustafsson wrote:
> > On 23 Mar 2021, at 20:04, Stephen Frost wrote:
> >
> > Eh, poor wording on my part. You're right, the question, reworded
> > again, was "Would someone want to get the context returned by
> > NSS_InitContext?". If we think there's a
On Wed, 2021-03-24 at 14:10 -0400, Stephen Frost wrote:
> * Jacob Champion (pchamp...@vmware.com) wrote:
> > I could see this being a problem if two client certificate nicknames
> > collide across multiple in-use databases, maybe?
>
> Right, in such a case either cert might get returned and it's p
> On 24 Mar 2021, at 04:54, Michael Paquier wrote:
>
> On Tue, Mar 23, 2021 at 12:38:50AM +0100, Daniel Gustafsson wrote:
>> Thanks again for reviewing, another version which addresses the remaining
>> issues will be posted soon but I wanted to get this out to give further
>> reviews
>> somethin
Greetings,
* Jacob Champion (pchamp...@vmware.com) wrote:
> On Wed, 2021-03-24 at 13:00 -0400, Stephen Frost wrote:
> > * Jacob Champion (pchamp...@vmware.com) wrote:
> > > Right, but to clarify -- I was asking if *NSS* supports loading and
> > > using separate certificate databases as part of its
On Wed, 2021-03-24 at 13:00 -0400, Stephen Frost wrote:
> * Jacob Champion (pchamp...@vmware.com) wrote:
> > Right, but to clarify -- I was asking if *NSS* supports loading and
> > using separate certificate databases as part of its API. It seems like
> > the internals make it possible, but I don't
Greetings Jacob,
* Jacob Champion (pchamp...@vmware.com) wrote:
> On Wed, 2021-03-24 at 09:28 +0900, Michael Paquier wrote:
> > On Wed, Mar 24, 2021 at 12:05:35AM +, Jacob Champion wrote:
> > > I can work around it temporarily for the
> > > tests, but this will be a problem if any libpq client
On Wed, 2021-03-24 at 09:28 +0900, Michael Paquier wrote:
> On Wed, Mar 24, 2021 at 12:05:35AM +, Jacob Champion wrote:
> > I can work around it temporarily for the
> > tests, but this will be a problem if any libpq clients load up multiple
> > independent databases for use with separate connec
1 - 100 of 166 matches
Mail list logo
