> On 29 Jun 2022, at 11:44, Jelte Fennema wrote:
>
>> See upthread in ef5c7896-20cb-843f-e91e-0ee5f7fd9...@enterprisedb.com
>
> I saw that section, but I thought that only applied before you
> backpatched the actual fixes to PG13 and below. I mean there's no
> reason anymore not to compile those
> See upthread in ef5c7896-20cb-843f-e91e-0ee5f7fd9...@enterprisedb.com
I saw that section, but I thought that only applied before you
backpatched the actual fixes to PG13 and below. I mean there's no
reason anymore not to compile those older versions with OpenSSL 3.0,
right? If so, it seems confu
> On 29 Jun 2022, at 11:02, Jelte Fennema wrote:
>
> On Wed, 29 Jun 2022 at 10:55, Daniel Gustafsson wrote:
>> These have now been pushed to 14 through to 10 ahead of next week releases
>
> I upgraded my OS to Ubuntu 22.04 and it seems that "Define
> OPENSSL_API_COMPAT" commit was never backpor
On Wed, 29 Jun 2022 at 10:55, Daniel Gustafsson wrote:
> These have now been pushed to 14 through to 10 ahead of next week releases
I upgraded my OS to Ubuntu 22.04 and it seems that "Define
OPENSSL_API_COMPAT" commit was never backported
(4d3db13621be64fbac2faf7c01c4879d20885c1b). I now get vari
> On 25 Sep 2021, at 15:45, Tom Lane wrote:
>
> Daniel Gustafsson writes:
>>> On 25 Sep 2021, at 12:03, Michael Paquier wrote:
>>> As 9.6 will be EOL'd in a couple of weeks, is that really
>>> worth the effort though? It sounds risky to me to introduce an
>>> invasive change as that would incr
Daniel Gustafsson writes:
>> On 25 Sep 2021, at 12:03, Michael Paquier wrote:
>> As 9.6 will be EOL'd in a couple of weeks, is that really
>> worth the effort though? It sounds risky to me to introduce an
>> invasive change as that would increase the risk of bugs for existing
>> users. So my vo
> On 25 Sep 2021, at 12:03, Michael Paquier wrote:
> As 9.6 will be EOL'd in a couple of weeks, is that really
> worth the effort though? It sounds risky to me to introduce an
> invasive change as that would increase the risk of bugs for existing
> users. So my vote would be to just let this on
On Sat, Sep 25, 2021 at 11:55:03AM +0200, Daniel Gustafsson wrote:
> These have now been pushed to 14 through to 10 ahead of next week releases, I
> will keep an eye on caiman as it builds these branches. The OpenSSL support
> in
> 9.6 pgcrypto isn't using the EVP API (committed in 5ff4a67f63) so
> On 23 Sep 2021, at 23:41, Daniel Gustafsson wrote:
> Thanks for confirming, I will go ahead and do that.
These have now been pushed to 14 through to 10 ahead of next week releases, I
will keep an eye on caiman as it builds these branches. The OpenSSL support in
9.6 pgcrypto isn't using the EV
> On 23 Sep 2021, at 23:26, Peter Eisentraut
> wrote:
>
> On 23.09.21 20:51, Daniel Gustafsson wrote:
>> For the 13- backbranches we also need to backport 22e1943f1 ("pgcrypto: Check
>> for error return of px_cipher_decrypt()" by Peter E) in order to avoid
>> incorrect results for decrypt tests
On 23.09.21 20:51, Daniel Gustafsson wrote:
For the 13- backbranches we also need to backport 22e1943f1 ("pgcrypto: Check
for error return of px_cipher_decrypt()" by Peter E) in order to avoid
incorrect results for decrypt tests on disallowed ciphers. Does anyone have
any concerns about applying
On Thu, Sep 23, 2021 at 2:51 PM Daniel Gustafsson wrote:
> For the 13- backbranches we also need to backport 22e1943f1 ("pgcrypto: Check
> for error return of px_cipher_decrypt()" by Peter E) in order to avoid
> incorrect results for decrypt tests on disallowed ciphers. Does anyone have
> any con
> On 22 Sep 2021, at 10:06, Daniel Gustafsson wrote:
> Agreed, I will go ahead and prep backpatches for 318df8 and 72bbff4cd.
These commits are enough to keep 14 happy, and I intend to apply them tomorrow
after another round of testing and caffeine.
For the 13- backbranches we also need to back
> On 22 Sep 2021, at 09:49, Michael Paquier wrote:
>
> On Tue, Sep 07, 2021 at 02:04:23PM +0200, Daniel Gustafsson wrote:
>> On 10 Aug 2021, at 15:27, Daniel Gustafsson wrote:
>>
>>> These have now been committed, when OpenSSL 3.0.0 ships and there is
>>> coverage
>>> in the buildfarm I’ll rev
On Tue, Sep 07, 2021 at 02:04:23PM +0200, Daniel Gustafsson wrote:
> On 10 Aug 2021, at 15:27, Daniel Gustafsson wrote:
>
>> These have now been committed, when OpenSSL 3.0.0 ships and there is coverage
>> in the buildfarm I’ll revisit this for the backbranches.
>
> As an update to this, I’ve te
> On 10 Aug 2021, at 15:27, Daniel Gustafsson wrote:
> These have now been committed, when OpenSSL 3.0.0 ships and there is coverage
> in the buildfarm I’ll revisit this for the backbranches.
As an update to this, I’ve tested the tree frozen for the upcoming 3.0.0
release (scheduled for today AF
> On 6 Aug 2021, at 21:17, Tom Lane wrote:
>
> Daniel Gustafsson writes:
>> Until there is an animal running OpenSSL 3.0.0 in the buildfarm I think this
>> should be HEAD only. Further down the line we need to support OpenSSL 3 in
>> all
>> backbranches IMO since they are all equally likely to
Daniel Gustafsson writes:
> Until there is an animal running OpenSSL 3.0.0 in the buildfarm I think this
> should be HEAD only. Further down the line we need to support OpenSSL 3 in
> all
> backbranches IMO since they are all equally likely to be compiled against it,
> but not until we can regul
> On 6 Aug 2021, at 21:01, Tom Lane wrote:
>
> Peter Eisentraut writes:
>> Are you going to commit these?
Absolutely, a combination of unplanned home renovations and vacations changed
my plans a bit recently.
> Note that with release wraps scheduled for Monday, we are probably
> already past t
Peter Eisentraut writes:
> Are you going to commit these?
Note that with release wraps scheduled for Monday, we are probably
already past the time when it'd be wise to push anything that has
a significant chance of introducing portability issues. There's
just not much time to deal with it if the
On 20.07.21 01:23, Daniel Gustafsson wrote:
So I think your proposed patch is sound and a good short-term and low-risk
solution
The attached 0001 disables the padding. I've tested this with OpenSSL 1.0.1,
1.0.2, 1.1.1 and Git HEAD at e278127cbfa2709d.
Another aspect of OpenSSL 3 compatibility
> On 20 Jul 2021, at 09:54, Michael Paquier wrote:
>
> On Tue, Jul 20, 2021 at 01:23:42AM +0200, Daniel Gustafsson wrote:
>> Another aspect of OpenSSL 3 compatibility is that of legacy cipher support,
>> and
>> as we concluded upthread it's best to leave that to the user to define in
>> openssl.
On Tue, Jul 20, 2021 at 01:23:42AM +0200, Daniel Gustafsson wrote:
> Another aspect of OpenSSL 3 compatibility is that of legacy cipher support,
> and
> as we concluded upthread it's best to leave that to the user to define in
> openssl.cnf. The attached 0002 adds alternative output files for 3.0
> On 3 Jul 2021, at 17:00, Peter Eisentraut
> wrote:
>
> On 12.03.21 08:51, Peter Eisentraut wrote:
>> On 11.03.21 11:41, Daniel Gustafsson wrote:
>>> .. and apply the padding changes as proposed in a patch upthread like this
>>> (these
>>> work for all OpenSSL versions I've tested, and I'm rat
On 12.03.21 08:51, Peter Eisentraut wrote:
On 11.03.21 11:41, Daniel Gustafsson wrote:
.. and apply the padding changes as proposed in a patch upthread like
this (these
work for all OpenSSL versions I've tested, and I'm rather more puzzled
as to
why we got away with not having them in the pas
On 12.03.21 00:22, Daniel Gustafsson wrote:
On 12 Mar 2021, at 00:04, Peter Eisentraut
wrote:
On 11.03.21 11:41, Daniel Gustafsson wrote:
Then there are a few where we get padding back where we really should have
ended up with the "Cipher cannot be initialized" error since DES is in the
legac
On 11.03.21 11:41, Daniel Gustafsson wrote:
.. and apply the padding changes as proposed in a patch upthread like this
(these
work for all OpenSSL versions I've tested, and I'm rather more puzzled as to
why we got away with not having them in the past):
Yes, before proceeding with this, we s
> On 12 Mar 2021, at 00:04, Peter Eisentraut
> wrote:
>
> On 11.03.21 11:41, Daniel Gustafsson wrote:
>> Then there are a few where we get padding back where we really should have
>> ended up with the "Cipher cannot be initialized" error since DES is in the
>> legacy provider:
>> select decrypt
On 11.03.21 11:41, Daniel Gustafsson wrote:
Then there are a few where we get padding back where we really should have
ended up with the "Cipher cannot be initialized" error since DES is in the
legacy provider:
select decrypt_iv(decode('50735067b073bb93', 'hex'), '0123456', 'abcd',
'des');
-
On Thu, Mar 11, 2021 at 11:41:22AM +0100, Daniel Gustafsson wrote:
> .. and apply the padding changes as proposed in a patch upthread
> like this (these work for all OpenSSL versions I've tested, and I'm
> rather more puzzled as to why we got away with not having them in
> the past):
No objectio
> On 11 Mar 2021, at 11:03, Peter Eisentraut
> wrote:
> The ssl tests fail with a small error message difference that must have been
> introduced recently, because I think this was never reported before:
This was mentioned by Michael on 26/11, it was earlier in the 3.0.0 cycle
reported as "nes
On 10.03.21 09:23, Daniel Gustafsson wrote:
On 3 Mar 2021, at 14:55, Peter Eisentraut
wrote:
This thread is still in the commit fest, but I don't see any actual proposed
patch still pending. Most of the activity has moved into other threads.
The doc changes in the patch proposed on 29/9 st
> On 3 Mar 2021, at 14:55, Peter Eisentraut
> wrote:
>
> This thread is still in the commit fest, but I don't see any actual proposed
> patch still pending. Most of the activity has moved into other threads.
The doc changes in the patch proposed on 29/9 still stands, although I see that
it ha
On Wed, Mar 03, 2021 at 02:55:41PM +0100, Peter Eisentraut wrote:
> This thread is still in the commit fest, but I don't see any actual proposed
> patch still pending. Most of the activity has moved into other threads.
>
> Could you update the status of this CF entry, and perhaps also on the stat
This thread is still in the commit fest, but I don't see any actual
proposed patch still pending. Most of the activity has moved into other
threads.
Could you update the status of this CF entry, and perhaps also on the
status of OpenSSL compatibility in general?
> On 26 Nov 2020, at 09:08, Michael Paquier wrote:
>
> On Tue, Sep 29, 2020 at 12:25:05PM +0200, Daniel Gustafsson wrote:
>> The attached adds config loading to pgcrypto for < 1.1.0 and a doc notice for
>> enabling the legacy provider in 3.0.0. This will require an alternative
>> output
>> file
On Tue, Sep 29, 2020 at 12:25:05PM +0200, Daniel Gustafsson wrote:
> The attached adds config loading to pgcrypto for < 1.1.0 and a doc notice for
> enabling the legacy provider in 3.0.0. This will require an alternative
> output
> file for non-legacy configs, but that should wait until 3.0.0 is
> On 22 Sep 2020, at 14:01, Daniel Gustafsson wrote:
>
>> On 22 Sep 2020, at 11:37, Peter Eisentraut
>> wrote:
>>
>> On 2020-09-18 16:11, Daniel Gustafsson wrote:
>>> Since we support ciphers that are now deprecated, we have no other choice
>>> than
>>> to load the legacy provider.
>>
>> Wel
> On 23 Sep 2020, at 10:19, Michael Paquier wrote:
>
> On Tue, Sep 22, 2020 at 02:01:18PM +0200, Daniel Gustafsson wrote:
>> Another option would be to follow OpenSSL's deprecations and mark these
>> ciphers
>> as deprecated such that we can remove them in case they indeed get removed
>> from
>
On Tue, Sep 22, 2020 at 02:01:18PM +0200, Daniel Gustafsson wrote:
> Another option would be to follow OpenSSL's deprecations and mark these
> ciphers
> as deprecated such that we can remove them in case they indeed get removed
> from
> libcypto. That would give users a heads-up that they should
On Mon, Sep 21, 2020 at 08:18:42PM +0200, Daniel Gustafsson wrote:
> I'm far from fluent in OpenSSL, but AFAICT it has to do with the new provider
> API. The default value for padding is unchanged, but it needs to be propaged
> into the provider to be set in the context where the old code picked i
> On 22 Sep 2020, at 11:37, Peter Eisentraut
> wrote:
>
> On 2020-09-18 16:11, Daniel Gustafsson wrote:
>> Since we support ciphers that are now deprecated, we have no other choice
>> than
>> to load the legacy provider.
>
> Well, we could just have deprecated ciphers fail, unless the user loa
On 2020-09-18 16:11, Daniel Gustafsson wrote:
Since we support ciphers that are now deprecated, we have no other choice than
to load the legacy provider.
Well, we could just have deprecated ciphers fail, unless the user loads
the legacy provider in the OS configuration. There might be an argu
> On 19 Sep 2020, at 04:11, Michael Paquier wrote:
> On Fri, Sep 18, 2020 at 04:11:13PM +0200, Daniel Gustafsson wrote:
>> The other problem was that the cipher context
>> padding must be explicitly set, whereas in previous versions relying on the
>> default worked fine. EVP_CIPHER_CTX_set_paddi
On Fri, Sep 18, 2020 at 04:11:13PM +0200, Daniel Gustafsson wrote:
> Since we support ciphers that are now deprecated, we have no other choice than
> to load the legacy provider.
Ah, thanks. I actually tried something similar to that when I had my
mind on it by loading the legacy providers, but m
> On 17 Aug 2020, at 06:12, Michael Paquier wrote:
> Leaving the problems with pgcrypto aside for now
Returning to this subject, I decided to take a stab at fixing pgcrypto since it
wasn't working.
Since we support ciphers that are now deprecated, we have no other choice than
to load the legacy
On Fri, May 29, 2020 at 12:16:47AM +0200, Daniel Gustafsson wrote:
> SSL_CTX_load_verify_locations and X509_STORE_load_locations are deprecated and
> replaced by individual calls to load files and directories. These are quite
> straightforward, and are implemented like how we handle the TLS protoc
On Sun, Jul 19, 2020 at 04:29:54PM +0200, Peter Eisentraut wrote:
> Good point. I have committed it with that adjustment. Also, I had the
> format of the version number wrong, so I changed that, too.
Thanks. I was not paying much attention to the format, but what you
have committed is in line w
On 2020-07-16 13:45, Michael Paquier wrote:
On Thu, Jul 16, 2020 at 10:58:58AM +0200, Peter Eisentraut wrote:
if test "$with_openssl" = yes ; then
dnl Order matters!
+ AC_DEFINE(OPENSSL_API_COMPAT, [10001],
+[Define to the OpenSSL API version in use. This avoids
deprecatio
On Thu, Jul 16, 2020 at 10:58:58AM +0200, Peter Eisentraut wrote:
> if test "$with_openssl" = yes ; then
>dnl Order matters!
> + AC_DEFINE(OPENSSL_API_COMPAT, [10001],
> +[Define to the OpenSSL API version in use. This avoids
>deprecation warnings from newer OpenSSL versions.]
On 2020-07-13 15:38, Tom Lane wrote:
Peter Eisentraut writes:
where would be a good place to define
OPENSSL_API_COMPAT?
Actually, it would be most formally correct to set it using AC_DEFINE in
configure.in, so that configure tests see it.
Yeah, very good point.
New patch done that way.
Peter Eisentraut writes:
>>> where would be a good place to define
>>> OPENSSL_API_COMPAT?
> Actually, it would be most formally correct to set it using AC_DEFINE in
> configure.in, so that configure tests see it.
Yeah, very good point.
regards, tom lane
On 2020-07-07 22:52, Daniel Gustafsson wrote:
where would be a good place to define
OPENSSL_API_COMPAT? The only place that's shared between frontend and
backend code is c.h. The attached patch does it that way.
pg_config_manual.h, perhaps?
I don't have a strong preference. When starting hac
On 2020-07-07 22:52, Daniel Gustafsson wrote:
Actually running the tests with the legacy provider loaded yields a fair number
of errors like these, and somewhere around there I ran out of time for now as
the CF started.
- decrypt
-
- Lets try a longer message
On 2020-07-08 16:51, Robert Haas wrote:
On Tue, Jul 7, 2020 at 1:46 PM Peter Eisentraut
wrote:
Trying to move this along, where would be a good place to define
OPENSSL_API_COMPAT? The only place that's shared between frontend and
backend code is c.h. The attached patch does it that way.
So,
On Tue, Jul 7, 2020 at 1:46 PM Peter Eisentraut
wrote:
> Trying to move this along, where would be a good place to define
> OPENSSL_API_COMPAT? The only place that's shared between frontend and
> backend code is c.h. The attached patch does it that way.
So, if we go this way, does that mean tha
> On 7 Jul 2020, at 19:53, Tom Lane wrote:
>
> Peter Eisentraut writes:
>> Trying to move this along,
Thanks, this has stalled a bit on my TODO.
>> where would be a good place to define
>> OPENSSL_API_COMPAT? The only place that's shared between frontend and
>> backend code is c.h. The att
Peter Eisentraut writes:
> Trying to move this along, where would be a good place to define
> OPENSSL_API_COMPAT? The only place that's shared between frontend and
> backend code is c.h. The attached patch does it that way.
pg_config_manual.h, perhaps?
regards, tom la
On 2020-05-30 11:29, Peter Eisentraut wrote:
My proposal would be to introduce OPENSSL_API_COMPAT=10001 into master
after the 13/14 branching, along with any other changes to make it
compile cleanly against OpenSSL 3.0.0. Once that has survived some
scrutiny from the buildfarm and also from folk
On 2020-05-30 11:29, Peter Eisentraut wrote:
I suggest to update the test data in PG13+, since we require OpenSSL
1.0.1 there. For the older branches, I would look into changing the
test driver setup so that it loads a custom openssl.cnf that loads the
legacy providers.
I have pushed your 0002
On Mon, Jun 01, 2020 at 10:44:17AM +0200, Peter Eisentraut wrote:
> Then we can stick a OPENSSL_API_COMPAT=908 into at least PG10, 11, and 12,
> and probably also into PG9.5 and 9.6 without harm.
FWIW, I am fine that for PG >= 10, and I don't think that it is worth
bothering with PG <= 9.6.
--
Mic
On Tue, Jun 02, 2020 at 02:45:11PM -0400, Andrew Dunstan wrote:
> Honestly, I think we've spent plenty of time on this already. I don't
> see a problem with each module having its own certificate(s) - that
> makes them more self-contained - nor any great need to have the targets
> named the same.
On 6/2/20 4:57 AM, Peter Eisentraut wrote:
> On 2020-06-01 15:23, Andrew Dunstan wrote:
>>
>> On 6/1/20 8:03 AM, Daniel Gustafsson wrote:
On 1 Jun 2020, at 13:58, Andrew Dunstan
wrote:
If you want I can add a rule for it to the Makefile, although who
knows
what commands
On 2020-06-01 15:23, Andrew Dunstan wrote:
On 6/1/20 8:03 AM, Daniel Gustafsson wrote:
On 1 Jun 2020, at 13:58, Andrew Dunstan wrote:
If you want I can add a rule for it to the Makefile, although who knows
what commands will actually apply when the certificate runs out?
Being able to easily r
Andrew Dunstan writes:
> On 6/1/20 8:03 AM, Daniel Gustafsson wrote:
>> +1 for adding it to the Makefile.
> OK, here's a patch.
Likewise +1 for having it in the makefile. But now you have two copies,
the other being in comments in the test script. The latter should go
away, as we surely won't
On 6/1/20 8:03 AM, Daniel Gustafsson wrote:
>> On 1 Jun 2020, at 13:58, Andrew Dunstan
>> wrote:
>> If you want I can add a rule for it to the Makefile, although who knows
>> what commands will actually apply when the certificate runs out?
> Being able to easily regenerate the testdata, regardle
> On 1 Jun 2020, at 13:58, Andrew Dunstan
> wrote:
> If you want I can add a rule for it to the Makefile, although who knows
> what commands will actually apply when the certificate runs out?
Being able to easily regenerate the testdata, regardless of expiration status,
has proven very helpful
On 6/1/20 4:33 AM, Peter Eisentraut wrote:
> On 2020-05-30 14:34, Andrew Dunstan wrote:
>>
>> On 5/28/20 6:16 PM, Daniel Gustafsson wrote:
>>>
>>> OpenSSL also deprecates DES keys in 3.0.0, which cause our password
>>> callback
>>> tests to fail with the cryptic error "fetch failed", as the test
> On 30 May 2020, at 11:29, Peter Eisentraut
> wrote:
>
> On 2020-05-29 14:45, Daniel Gustafsson wrote:
>>> I think we should set OPENSSL_API_COMPAT=10001, and move that along with
>>> whatever our oldest supported release is going forward. That declares our
>>> intention, it will silence the
On 2020-05-31 04:52, Michael Paquier wrote:
593d4e4 claims that we only support OpenSSL >= 0.9.8, meaning that
down to PG 10 we have this requirement, and that PG 9.6 and 9.5 should
be able to work with OpenSSL 0.9.7 and 0.9.6, but little effort has
been put in testing these.
Then we can stick
On 2020-05-30 14:34, Andrew Dunstan wrote:
On 5/28/20 6:16 PM, Daniel Gustafsson wrote:
OpenSSL also deprecates DES keys in 3.0.0, which cause our password callback
tests to fail with the cryptic error "fetch failed", as the test suite keys are
encrypted with DES. 0002 fixes this by changing
On Sat, May 30, 2020 at 11:29:11AM +0200, Peter Eisentraut wrote:
> I'm not sure. I don't have a good sense of what OpenSSL versions we claim
> to support in branches older than PG13. We made a conscious decision for
> 1.0.1 in PG13, but I seem to recall that that discussion also revealed that
>
On 5/28/20 6:16 PM, Daniel Gustafsson wrote:
>
> OpenSSL also deprecates DES keys in 3.0.0, which cause our password callback
> tests to fail with the cryptic error "fetch failed", as the test suite keys
> are
> encrypted with DES. 0002 fixes this by changing to AES256 (randomly chosen
> among
On 2020-05-29 14:45, Daniel Gustafsson wrote:
I think we should set OPENSSL_API_COMPAT=10001, and move that along with
whatever our oldest supported release is going forward. That declares our
intention, it will silence the deprecation warnings, and IIUC, if the
deprecated stuff actually gets
> On 29 May 2020, at 13:34, Peter Eisentraut
> wrote:
>
> On 2020-05-29 00:16, Daniel Gustafsson wrote:
>> Regarding the deprecations, we can either set preprocessor directives or use
>> compiler flags to silence the warning and do nothing (for now), or we could
>> update to the new API. We pro
On 2020-05-29 00:16, Daniel Gustafsson wrote:
Regarding the deprecations, we can either set preprocessor directives or use
compiler flags to silence the warning and do nothing (for now), or we could
update to the new API. We probably want to different things for master vs
back-branches, but as a
> On 29 May 2020, at 08:06, Laurenz Albe wrote:
>> Regarding the deprecations, we can either set preprocessor directives or use
>> compiler flags to silence the warning and do nothing (for now), or we could
>> update to the new API. We probably want to different things for master vs
>> back-bran
On Fri, 2020-05-29 at 00:16 +0200, Daniel Gustafsson wrote:
> Since OpenSSL is now releasing 3.0.0-alpha versions, I took a look at using it
> with postgres to see what awaits us. As it is now shipping in releases (with
> GA planned for Q4), users will probably soon start to test against it so I
>
ike we have to do the EVP rewrite there.
cheers ./daniel
0002-OpenSSL-3.0.0-compatibility-in-tests.patch
Description: Binary data
0001-Compatibility-with-OpenSSL-3.0.0.patch
Description: Binary data
79 matches
Mail list logo
