On Tue, 2021-10-19 at 20:21 +0200, Daniel Gustafsson wrote:
> > On 15 Oct 2021, at 14:01, Daniel Gustafsson wrote:
> > The attached contains the requested fixes, and has been tested on all (by
> > us)
> > supported versions of OpenSSL. Unless there are objections I will apply
> > this
> > to
> On 15 Oct 2021, at 14:01, Daniel Gustafsson wrote:
> The attached contains the requested fixes, and has been tested on all (by us)
> supported versions of OpenSSL. Unless there are objections I will apply this
> to master shortly.
Which is now done.
--
Daniel Gustafsson
> On 1 Oct 2021, at 09:02, Daniel Gustafsson wrote:
>
>> On 1 Oct 2021, at 08:59, Michael Paquier wrote:
>>
>> On Wed, Sep 15, 2021 at 12:31:31AM +0200, Daniel Gustafsson wrote:
>>> Correct. In my head, "rebuild" is when dealing with individually changed
>>> files
>>> and "recreate" means
> On 1 Oct 2021, at 08:59, Michael Paquier wrote:
>
> On Wed, Sep 15, 2021 at 12:31:31AM +0200, Daniel Gustafsson wrote:
>> Correct. In my head, "rebuild" is when dealing with individually changed
>> files
>> and "recreate" means rebuild everything regardless. Thats just my in my head
>>
On Wed, Sep 15, 2021 at 12:31:31AM +0200, Daniel Gustafsson wrote:
> Correct. In my head, "rebuild" is when dealing with individually changed
> files
> and "recreate" means rebuild everything regardless. Thats just my in my head
> though, so clearly the wording should be expanded. Will do.
So
> On 15 Sep 2021, at 00:14, Jacob Champion wrote:
> On Mon, 2021-09-13 at 15:04 +0200, Daniel Gustafsson wrote:
>> -# Convert client.key to encrypted PEM (X.509 text) and DER (X.509 ASN.1)
>> formats
>> -# to test libpq's support for the sslpassword= option.
>> -ssl/client-encrypted-pem.key:
On Mon, 2021-09-13 at 15:04 +0200, Daniel Gustafsson wrote:
> A few things noted (and fixed as per the attached, which is v6 squashed and
> rebased on HEAD; commitmessage hasn't been addressed yet) while reviewing:
>
> * Various comment reflowing to fit within 79 characters
>
> * Pass through
> On 9 Sep 2021, at 03:32, Michael Paquier wrote:
>
> On Wed, Sep 08, 2021 at 07:32:03PM +, Jacob Champion wrote:
>> On Fri, 2021-09-03 at 23:21 +, Jacob Champion wrote:
One small-ish comment that I have is about all the .config files we
have at the root of src/test/ssl/,
On Wed, Sep 08, 2021 at 07:32:03PM +, Jacob Champion wrote:
> On Fri, 2021-09-03 at 23:21 +, Jacob Champion wrote:
> > > One small-ish comment that I have is about all the .config files we
> > > have at the root of src/test/ssl/, bloating the whole. I think that
> > > it would be a bit
On Fri, 2021-09-03 at 09:46 +0900, Michael Paquier wrote:
> Nice. This is neat. The split helps a lot to understand how you've
> changed things from the original implementation. As a whole, this
> looks rather committable to me.
Great!
> One small-ish comment that I have is about all the
On Thu, Sep 02, 2021 at 04:42:14PM +, Jacob Champion wrote:
> Done that way in v5. It's a lot of moved code, so I've kept it as two
> commits for review purposes.
Nice. This is neat. The split helps a lot to understand how you've
changed things from the original implementation. As a whole,
On 9/1/21 8:09 PM, Jacob Champion wrote:
> On Fri, 2021-08-27 at 15:02 +0900, Michael Paquier wrote:
>> On Fri, Aug 13, 2021 at 12:08:16AM +, Jacob Champion wrote:
>>> If _that's_ the case, then our build system is holding all of us
>>> hostage. Which is frustrating to me. Should I shift
On Fri, 2021-08-27 at 15:02 +0900, Michael Paquier wrote:
> On Fri, Aug 13, 2021 at 12:08:16AM +, Jacob Champion wrote:
> > If _that's_ the case, then our build system is holding all of us
> > hostage. Which is frustrating to me. Should I shift focus to help with
> > that, first?
>
> Fresh
e attached a v4 to
make the cfbot happy.
--Jacob
From 6e038173717798dcd375e3741862152979c414fb Mon Sep 17 00:00:00 2001
From: Jacob Champion
Date: Fri, 26 Feb 2021 15:25:28 -0800
Subject: [PATCH v4] test/ssl: rework the sslfiles Makefile target
Adding a new certificate is as easy as dropping in a
On Fri, Aug 13, 2021 at 12:08:16AM +, Jacob Champion wrote:
> (Things would get hairier if someone included the SSL Makefile
> somewhere else, but I don't see anyone doing that now and I don't know
> why someone would.)
That would not happen. Hopefully.
> But -- if I do spend the time to
On Tue, 2021-08-10 at 11:26 -0400, Tom Lane wrote:
> Yeah, I don't like that change either. It would be one thing if
> we had several places in which suppressing .SECONDARY was useful,
> but if there's only one then it seems better to design around it.
Maybe. The current Makefile already tried
On Tue, 2021-08-10 at 16:22 +0900, Michael Paquier wrote:
> Regarding 0002, I am not sure. Even if this reduces a lot of
> duplication, which is really nice, enforcing .SECONDARY to not trigger
> with a change impacting Makefile.global.in does not sound very
> appealing to me in the long-run,
On Tue, Aug 10, 2021 at 09:36:14AM +0200, Daniel Gustafsson wrote:
> I personally think the increased readability and usability from what we have
> today warrants the changes. Is it the use of .SECONDARY or the change in the
> global Makefile you object to (or both)?
The part I am mainly
Michael Paquier writes:
> Regarding 0002, I am not sure. Even if this reduces a lot of
> duplication, which is really nice, enforcing .SECONDARY to not trigger
> with a change impacting Makefile.global.in does not sound very
> appealing to me in the long-run, TBH.
Yeah, I don't like that change
> On 10 Aug 2021, at 09:22, Michael Paquier wrote:
>
> On Fri, Jul 30, 2021 at 03:11:49PM +, Jacob Champion wrote:
>> No worries, it's easy enough to unroll the expansion manually. The
>> annoyances without secondary expansion are the duplicated lines for
>> each individual CA and the need
On Fri, Jul 30, 2021 at 03:11:49PM +, Jacob Champion wrote:
> No worries, it's easy enough to unroll the expansion manually. The
> annoyances without secondary expansion are the duplicated lines for
> each individual CA and the need to introduce .INTERMEDIATE targets so
> that cleanup works as
> On 28 Jul 2021, at 23:02, Tom Lane wrote:
> Jacob Champion writes:
>> As long as the .SECONDARYEXPANSION magic is clear enough to others, I'm
>> happy.
>
> After reading the gmake docs about that, I'd have to say it's likely to be
> next
> door to unmaintainable.
Personally, I don’t think
Jacob Champion writes:
> On Wed, 2021-07-28 at 00:24 +0200, Daniel Gustafsson wrote:
>> GNU Make is already a requirement, I don't see this shifting the needle in
>> any
>> direction.
Um ... the existing requirement is for gmake 3.80 or newer;
if you want to use newer features we'd have to have
On 7/28/21 4:10 PM, Jacob Champion wrote:
>
>>> - I am making _heavy_ use of GNU Make-isms, which does not improve
>>> long-term maintainability.
>> GNU Make is already a requirement, I don't see this shifting the needle in
>> any
>> direction.
> As long as the .SECONDARYEXPANSION magic is
On Wed, 2021-07-28 at 00:24 +0200, Daniel Gustafsson wrote:
> > On 4 Mar 2021, at 01:03, Jacob Champion wrote:
> > Andrew pointed out elsewhere [1] that it's pretty difficult to add new
> > certificates to the test/ssl suite without blowing away the current
> > state and starting over. I needed
> On 4 Mar 2021, at 01:03, Jacob Champion wrote:
> Andrew pointed out elsewhere [1] that it's pretty difficult to add new
> certificates to the test/ssl suite without blowing away the current
> state and starting over. I needed new cases for the NSS backend work,
> and ran into the same pain, so
26 Feb 2021 15:25:28 -0800
Subject: [PATCH v2] test/ssl: rework the sslfiles Makefile target
Adding a new certificate is as easy as dropping in a new .config file,
adding it to the top of the Makefile, and running `make sslfiles`.
Improvements:
- Interfile dependencies should be fixed, with the
3414796bf8e5ea0134bdf524cf932a15f6227354 Mon Sep 17 00:00:00 2001
From: Jacob Champion
Date: Fri, 26 Feb 2021 15:25:28 -0800
Subject: [PATCH] test/ssl: rework the sslfiles Makefile target
Adding a new certificate is as easy as dropping in a new .config file,
adding it to the top of the Makefile
28 matches
Mail list logo
