Re: SSL operation failed with code 1: error:0A000126:SSL routines
Isn't it a fix for this issue? https://github.com/php/php-src/issues/8369 On Thu, 19 May 2022, 21:17 Frederic Leclercq, wrote: > Hi all, > > Apologies for just popping in here, but since I installed ubuntu 22.04 LTS > I often come across the error > "file_get_contents(): SSL operation failed with code 1. OpenSSL Error > messages: > error:0A000126:SSL routines::unexpected eof while reading" > > It seems to occur mostly in PHP applications. It is often referred to an > OpenSSL 3 issue. > > I currently have this version up: > OpenSSL 3.0.2 15 Mar 2022 (Library: OpenSSL 3.0.2 15 Mar 2022) > built on: Thu May 5 08:04:52 2022 UTC > platform: debian-amd64 > options: bn(64,64) > compiler: gcc -fPIC -pthread -m64 -Wa,--noexecstack -Wall > -Wa,--noexecstack -g -O2 > -ffile-prefix-map=/build/openssl-Ke3YUO/openssl-3.0.2=. -flto=auto > -ffat-lto-objects -flto=auto -ffat-lto-objects -fstack-protector-strong > -Wformat -Werror=format-security -DOPENSSL_TLS_SECURITY_LEVEL=2 > -DOPENSSL_USE_NODELETE -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_BUILDING_OPENSSL > -DNDEBUG -Wdate-time -D_FORTIFY_SOURCE=2 > OPENSSLDIR: "/usr/lib/ssl" > ENGINESDIR: "/usr/lib/x86_64-linux-gnu/engines-3" > MODULESDIR: "/usr/lib/x86_64-linux-gnu/ossl-modules" > Seeding source: os-specific > CPUINFO: OPENSSL_ia32cap=0x7ed8320b078b:0x44219c91a9 > > Can anyone help me to solve this problem? > > Thanks in advance! > Fred. >
SSL operation failed with code 1: error:0A000126:SSL routines
Hi all, Apologies for just popping in here, but since I installed ubuntu 22.04 LTS I often come across the error "file_get_contents(): SSL operation failed with code 1. OpenSSL Error messages: error:0A000126:SSL routines::unexpected eof while reading" It seems to occur mostly in PHP applications. It is often referred to an OpenSSL 3 issue. I currently have this version up: OpenSSL 3.0.2 15 Mar 2022 (Library: OpenSSL 3.0.2 15 Mar 2022) built on: Thu May 5 08:04:52 2022 UTC platform: debian-amd64 options: bn(64,64) compiler: gcc -fPIC -pthread -m64 -Wa,--noexecstack -Wall -Wa,--noexecstack -g -O2 -ffile-prefix-map=/build/openssl-Ke3YUO/openssl-3.0.2=. -flto=auto -ffat-lto-objects -flto=auto -ffat-lto-objects -fstack-protector-strong -Wformat -Werror=format-security -DOPENSSL_TLS_SECURITY_LEVEL=2 -DOPENSSL_USE_NODELETE -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_BUILDING_OPENSSL -DNDEBUG -Wdate-time -D_FORTIFY_SOURCE=2 OPENSSLDIR: "/usr/lib/ssl" ENGINESDIR: "/usr/lib/x86_64-linux-gnu/engines-3" MODULESDIR: "/usr/lib/x86_64-linux-gnu/ossl-modules" Seeding source: os-specific CPUINFO: OPENSSL_ia32cap=0x7ed8320b078b:0x44219c91a9 Can anyone help me to solve this problem? Thanks in advance! Fred.
Re: [EXTERNAL] Keytool issue with version 3.0.2.
I may have a mixed Java environment. I will recheck on a clean VM when I get a few minutes. Regards Mark Hack On Thu, 2022-05-19 at 16:46 +0200, Djordje Gavrilovic wrote: > Hm, not working here. > > openjdk version "1.8.0_312" > > OpenJDK Runtime Environment (build > 1.8.0_312-8u312-b07-0ubuntu1-b07) > > OpenJDK 64-Bit Server VM (build 25.312-b07, mixed mode) > > > > Am I correct, the only thing you changed was leaving out the > -srcstoretype PKCS12 part? Also, you did not use -legacy option > on > a previous command? > > > On 19.5.22. 16:18, Mark Hack wrote: > > > > > > > > > > > > > I installed java 8 and it seems to work there on the latest > > versions as well > > > > > > > >java -version > > openjdk version "1.8.0_312" > > OpenJDK Runtime Environment (build > > 1.8.0_312-8u312-b07-0ubuntu1~20.04-b07) > > OpenJDK 64-Bit Server VM (build 25.312-b07, mixed mode) > > > > > > > > > > > > > > On Thu, 2022-05-19 at 16:02 +0200, Djordje Gavrilovic wrote: > > > > > Thank you both for your answers! So much! Both of them > > > very > > > helpful. We are stuck with openjdk8 right now...but it > > > is good > > > to know that later versions will work as expected. > > > > > > Thank you guys > > > > > > > > > On 19.5.22. 15:41, Mark Hack wrote: > > > > > > > > > > > > > > > > > Works for me and since the later versions of java > > > > accept > > > > both JKS and PKCS12 you do not have to specify the > > > > input > > > > store type. > > > > > > > > > > > > > > > > > > > > > > > > > > > >java --version > > > > openjdk 11.0.15 2022-04-19 > > > > OpenJDK Runtime Environment (build > > > > 11.0.15+10-Ubuntu-0ubuntu0.20.04.1) > > > > OpenJDK 64-Bit Server VM (build > > > > 11.0.15+10-Ubuntu-0ubuntu0.20.04.1, mixed mode, > > > > sharing) > > > > > > > > > > > > > > > > > > > > > > > > > > > > keytool -importkeystore -srckeystore > > > > bmstore.pkcs12.pem -srcstorepass changeit > > > > -destkeystore > > > > bmstore.pkcs8.x509.jks -deststorepass changeit > > > > Importing keystore bmstore.pkcs12.pem to > > > > bmstore.pkcs8.x509.jks... > > > > Entry for alias 1 successfully imported. > > > > Import command completed: 1 entries successfully > > > > imported, 0 entries failed or cancelled > > > > > > > > > > > > > > > > Warning: > > > > <1> uses the SHA1withRSA signature algorithm which > > > > is considered a security risk. This algorithm will > > > > be > > > > disabled in a future update. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Mark Hack > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Thu, 2022-05-19 at 12:13 +0200, Erwann Abalea via > > > > openssl-users wrote: > > > > > > > > > > > > > > Bonjour, > > > > > > > > > > > > > > > > > > > > OpenSSL 3 changed the default ciphers used to > > > > > protect the > > > > > private keys and certificates when creating a > > > > > PKCS#12, to > > > > > use something less aging. > > > > > > > > > > > > > > > > > > > > Try adding a "-legacy" when creating the > > > > > PKCS#12 file > > > > > with OpenSSL3 and see if keytool can read it. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Thu, May 19, 2022 at > > > > > 11:53 AM Djordje Gavrilovic < > > > > > gavrilovic...@gmail.com> > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > Hi guys, > > > > > > > > > > > > I have a following issue with migrating > > > > > > from version > > > > > > 1.1.1f to 3.0.2: > > > > > > > > > > > > > > > > > > > > > > > > I generate bmstore.pkcs12.pem file with the > > > > > > following > > > > > > commands: > > > > > > > > > > > > > > > > > > > > > > > > ``` > > > > > > > > > > > > > > > > > > > > > > > > openssl req -newkey rsa:2048 -sha1 -keyout > > > > > > bmstore.pkcs8.pem -nodes > > > > >
Re: [EXTERNAL] Keytool issue with version 3.0.2.
Hm, not working here. openjdk version "1.8.0_312" OpenJDK Runtime Environment (build 1.8.0_312-8u312-b07-0ubuntu1-b07) OpenJDK 64-Bit Server VM (build 25.312-b07, mixed mode) Am I correct, the only thing you changed was leaving out the -srcstoretype PKCS12 part? Also, you did not use -legacy option on a previous command? On 19.5.22. 16:18, Mark Hack wrote: I installed java 8 and it seems to work there on the latest versions as well java -version openjdk version "1.8.0_312" OpenJDK Runtime Environment (build 1.8.0_312-8u312-b07-0ubuntu1~20.04-b07) OpenJDK 64-Bit Server VM (build 25.312-b07, mixed mode) On Thu, 2022-05-19 at 16:02 +0200, Djordje Gavrilovic wrote: Thank you both for your answers! So much! Both of them very helpful. We are stuck with openjdk8 right now...but it is good to know that later versions will work as expected. Thank you guys On 19.5.22. 15:41, Mark Hack wrote: Works for me and since the later versions of java accept both JKS and PKCS12 you do not have to specify the input store type. * java --version* openjdk 11.0.15 2022-04-19 OpenJDK Runtime Environment (build 11.0.15+10-Ubuntu-0ubuntu0.20.04.1) OpenJDK 64-Bit Server VM (build 11.0.15+10-Ubuntu-0ubuntu0.20.04.1, mixed mode, sharing) *keytool -importkeystore -srckeystore bmstore.pkcs12.pem -srcstorepass changeit -destkeystore bmstore.pkcs8.x509.jks -deststorepass changeit* Importing keystore bmstore.pkcs12.pem to bmstore.pkcs8.x509.jks... Entry for alias 1 successfully imported. Import command completed: 1 entries successfully imported, 0 entries failed or cancelled Warning: <1> uses the SHA1withRSA signature algorithm which is considered a security risk. This algorithm will be disabled in a future update. Mark Hack On Thu, 2022-05-19 at 12:13 +0200, Erwann Abalea via openssl-users wrote: Bonjour, OpenSSL 3 changed the default ciphers used to protect the private keys and certificates when creating a PKCS#12, to use something less aging. Try adding a "-legacy" when creating the PKCS#12 file with OpenSSL3 and see if keytool can read it. On Thu, May 19, 2022 at 11:53 AM Djordje Gavrilovic wrote: Hi guys, I have a following issue with migrating from version 1.1.1f to 3.0.2: I generate bmstore.pkcs12.pem file with the following commands: ``` openssl req -newkey rsa:2048 -sha1 -keyout bmstore.pkcs8.pem -nodes -x509 -days 999 -out bmstore.x509.crt -subj "/C=DE/ST=Nsk/L=Nsk/O=BM/OU=BM/CN=AS" openssl pkcs12 -export -in bmstore.x509.crt -inkey bmstore.pkcs8.pem -out bmstore.pkcs12.pem -passin pass:changeit -passout pass:changeit ``` This file is genearted with different openssl versions differently. Both versions of the file are attached. Based on that file I generate: ``` keytool -importkeystore -srckeystore bmstore.pkcs12.pem -srcstoretype PKCS12 -srcstorepass changeit -destkeystore bmstore.pkcs8.x509.jks -deststorepass changeit ``` But keytool works only with the bmstore.pkcs12.pem generated with old version of openssl and creates bmstore.pkcs8.x509.jks The current version of openssl generates bmstore.pkcs12.pem in another format and keytool throws an exception: ``` Importing keystore bmstore.pkcs12.pem to bmstore.pkcs8.x509.jks... keytool error: java.io.IOException: keystore password was incorrect ```
Re: [EXTERNAL] Keytool issue with version 3.0.2.
I installed java 8 and it seems to work there on the latest versions as well java -versionopenjdk version "1.8.0_312"OpenJDK Runtime Environment (build 1.8.0_312-8u312-b07-0ubuntu1~20.04-b07)OpenJDK 64-Bit Server VM (build 25.312-b07, mixed mode) On Thu, 2022-05-19 at 16:02 +0200, Djordje Gavrilovic wrote: > Thank you both for your answers! So much! Both of them very > helpful. We are stuck with openjdk8 right now...but it is good > to > know that later versions will work as expected. > > Thank you guys > > > On 19.5.22. 15:41, Mark Hack wrote: > > > > > > > Works for me and since the later versions of java accept both > > JKS and PKCS12 you do not have to specify the input store > > type. > > > > > > > > > > > > > >java --version > > openjdk 11.0.15 2022-04-19 > > OpenJDK Runtime Environment (build > > 11.0.15+10-Ubuntu-0ubuntu0.20.04.1) > > OpenJDK 64-Bit Server VM (build > > 11.0.15+10-Ubuntu-0ubuntu0.20.04.1, mixed mode, sharing) > > > > > > > > > > > > > > keytool -importkeystore -srckeystore > > bmstore.pkcs12.pem -srcstorepass changeit -destkeystore > > bmstore.pkcs8.x509.jks -deststorepass changeit > > Importing keystore bmstore.pkcs12.pem to > > bmstore.pkcs8.x509.jks... > > Entry for alias 1 successfully imported. > > Import command completed: 1 entries successfully imported, 0 > > entries failed or cancelled > > > > > > > > Warning: > > <1> uses the SHA1withRSA signature algorithm which is > > considered a security risk. This algorithm will be disabled > > in a > > future update. > > > > > > > > > > > > > > Mark Hack > > > > > > > > > > > > > > On Thu, 2022-05-19 at 12:13 +0200, Erwann Abalea via > > openssl-users wrote: > > > > > > > > Bonjour, > > > > > > > > > > > > OpenSSL 3 changed the default ciphers used to protect > > > the > > > private keys and certificates when creating a PKCS#12, > > > to use > > > something less aging. > > > > > > > > > > > > Try adding a "-legacy" when creating the PKCS#12 file > > > with OpenSSL3 and see if keytool can read it. > > > > > > > > > > > > > > > > > > > > > > > > On Thu, May 19, 2022 at > > > 11:53 AM Djordje Gavrilovic > > > wrote: > > > > > > > > > > > > > Hi guys, > > > > > > > > I have a following issue with migrating from > > > > version 1.1.1f > > > > to 3.0.2: > > > > > > > > > > > > > > > > I generate bmstore.pkcs12.pem file with the > > > > following > > > > commands: > > > > > > > > > > > > > > > > ``` > > > > > > > > > > > > > > > > openssl req -newkey rsa:2048 -sha1 -keyout > > > > bmstore.pkcs8.pem > > > > -nodes > > > > > > > > -x509 -days 999 -out bmstore.x509.crt -subj > > > > > > > > "/C=DE/ST=Nsk/L=Nsk/O=BM/OU=BM/CN=AS" > > > > > > > > openssl pkcs12 -export -in bmstore.x509.crt -inkey > > > > bmstore.pkcs8.pem > > > > > > > > -out bmstore.pkcs12.pem -passin pass:changeit > > > > -passout > > > > pass:changeit > > > > > > > > ``` > > > > > > > > > > > > > > > > This file is genearted with different openssl > > > > versions > > > > differently. Both > > > > > > > > versions of the file are attached. > > > > > > > > > > > > > > > > Based on that file I generate: > > > > > > > > > > > > > > > > ``` > > > > > > > > keytool -importkeystore -srckeystore > > > > bmstore.pkcs12.pem > > > > -srcstoretype > > > > > > > > PKCS12 -srcstorepass changeit -destkeystore > > > > bmstore.pkcs8.x509.jks > > > > > > > > -deststorepass changeit > > > > > > > > ``` > > > > > > > > > > > > > > > > But keytool works only with the bmstore.pkcs12.pem > > > > generated > > > > with old > > > > > > > > version of openssl and creates > > > > bmstore.pkcs8.x509.jks > > > > > > > > > > > > > > > > The current version of openssl generates > > > > bmstore.pkcs12.pem > > > > in another > > > > > > > > format and keytool throws an exception: > > > > > > > > > > > > > > > > ``` > > > > > > > > Importing keystore bmstore.pkcs12.pem to > > > >
Re: [EXTERNAL] Keytool issue with version 3.0.2.
Thank you both for your answers! So much! Both of them very helpful. We are stuck with openjdk8 right now...but it is good to know that later versions will work as expected. Thank you guys On 19.5.22. 15:41, Mark Hack wrote: Works for me and since the later versions of java accept both JKS and PKCS12 you do not have to specify the input store type. * java --version* openjdk 11.0.15 2022-04-19 OpenJDK Runtime Environment (build 11.0.15+10-Ubuntu-0ubuntu0.20.04.1) OpenJDK 64-Bit Server VM (build 11.0.15+10-Ubuntu-0ubuntu0.20.04.1, mixed mode, sharing) *keytool -importkeystore -srckeystore bmstore.pkcs12.pem -srcstorepass changeit -destkeystore bmstore.pkcs8.x509.jks -deststorepass changeit* Importing keystore bmstore.pkcs12.pem to bmstore.pkcs8.x509.jks... Entry for alias 1 successfully imported. Import command completed: 1 entries successfully imported, 0 entries failed or cancelled Warning: <1> uses the SHA1withRSA signature algorithm which is considered a security risk. This algorithm will be disabled in a future update. Mark Hack On Thu, 2022-05-19 at 12:13 +0200, Erwann Abalea via openssl-users wrote: Bonjour, OpenSSL 3 changed the default ciphers used to protect the private keys and certificates when creating a PKCS#12, to use something less aging. Try adding a "-legacy" when creating the PKCS#12 file with OpenSSL3 and see if keytool can read it. On Thu, May 19, 2022 at 11:53 AM Djordje Gavrilovic wrote: Hi guys, I have a following issue with migrating from version 1.1.1f to 3.0.2: I generate bmstore.pkcs12.pem file with the following commands: ``` openssl req -newkey rsa:2048 -sha1 -keyout bmstore.pkcs8.pem -nodes -x509 -days 999 -out bmstore.x509.crt -subj "/C=DE/ST=Nsk/L=Nsk/O=BM/OU=BM/CN=AS" openssl pkcs12 -export -in bmstore.x509.crt -inkey bmstore.pkcs8.pem -out bmstore.pkcs12.pem -passin pass:changeit -passout pass:changeit ``` This file is genearted with different openssl versions differently. Both versions of the file are attached. Based on that file I generate: ``` keytool -importkeystore -srckeystore bmstore.pkcs12.pem -srcstoretype PKCS12 -srcstorepass changeit -destkeystore bmstore.pkcs8.x509.jks -deststorepass changeit ``` But keytool works only with the bmstore.pkcs12.pem generated with old version of openssl and creates bmstore.pkcs8.x509.jks The current version of openssl generates bmstore.pkcs12.pem in another format and keytool throws an exception: ``` Importing keystore bmstore.pkcs12.pem to bmstore.pkcs8.x509.jks... keytool error: java.io.IOException: keystore password was incorrect ```
Re: [EXTERNAL] Keytool issue with version 3.0.2.
Works for me and since the later versions of java accept both JKS and PKCS12 you do not have to specify the input store type. java --versionopenjdk 11.0.15 2022-04-19OpenJDK Runtime Environment (build 11.0.15+10-Ubuntu-0ubuntu0.20.04.1)OpenJDK 64-Bit Server VM (build 11.0.15+10-Ubuntu-0ubuntu0.20.04.1, mixed mode, sharing) keytool -importkeystore -srckeystore bmstore.pkcs12.pem -srcstorepass changeit -destkeystore bmstore.pkcs8.x509.jks -deststorepass changeitImporting keystore bmstore.pkcs12.pem to bmstore.pkcs8.x509.jks...Entry for alias 1 successfully imported.Import command completed: 1 entries successfully imported, 0 entries failed or cancelled Warning:<1> uses the SHA1withRSA signature algorithm which is considered a security risk. This algorithm will be disabled in a future update. Mark Hack On Thu, 2022-05-19 at 12:13 +0200, Erwann Abalea via openssl-users wrote: > Bonjour, > > OpenSSL 3 changed the default ciphers used to protect the private > keys and certificates when creating a PKCS#12, to use something less > aging. > Try adding a "-legacy" when creating the PKCS#12 file with OpenSSL3 > and see if keytool can read it. > > > > On Thu, May 19, 2022 at 11:53 AM Djordje Gavrilovic < > gavrilovic...@gmail.com> wrote: > > Hi guys, > > > > I have a following issue with migrating from version 1.1.1f to > > 3.0.2: > > > > > > > > I generate bmstore.pkcs12.pem file with the following commands: > > > > > > > > ``` > > > > > > > > openssl req -newkey rsa:2048 -sha1 -keyout bmstore.pkcs8.pem > > -nodes > > > > -x509 -days 999 -out bmstore.x509.crt -subj > > > > "/C=DE/ST=Nsk/L=Nsk/O=BM/OU=BM/CN=AS" > > > > openssl pkcs12 -export -in bmstore.x509.crt -inkey > > bmstore.pkcs8.pem > > > > -out bmstore.pkcs12.pem -passin pass:changeit -passout > > pass:changeit > > > > ``` > > > > > > > > This file is genearted with different openssl versions differently. > > Both > > > > versions of the file are attached. > > > > > > > > Based on that file I generate: > > > > > > > > ``` > > > > keytool -importkeystore -srckeystore bmstore.pkcs12.pem > > -srcstoretype > > > > PKCS12 -srcstorepass changeit -destkeystore bmstore.pkcs8.x509.jks > > > > -deststorepass changeit > > > > ``` > > > > > > > > But keytool works only with the bmstore.pkcs12.pem generated with > > old > > > > version of openssl and creates bmstore.pkcs8.x509.jks > > > > > > > > The current version of openssl generates bmstore.pkcs12.pem in > > another > > > > format and keytool throws an exception: > > > > > > > > ``` > > > > Importing keystore bmstore.pkcs12.pem to bmstore.pkcs8.x509.jks... > > > > keytool error: java.io.IOException: keystore password was incorrect > > > > > > > > ``` > > > >
OpenSSL is looking to hire a Business Operations Administrator
Please see the following blog post for details of the role: https://www.openssl.org/blog/blog/2022/05/18/hiring-business-operations-administrator/ Matt
Re: [EXTERNAL] Keytool issue with version 3.0.2.
Bonjour, OpenSSL 3 changed the default ciphers used to protect the private keys and certificates when creating a PKCS#12, to use something less aging. Try adding a "-legacy" when creating the PKCS#12 file with OpenSSL3 and see if keytool can read it. On Thu, May 19, 2022 at 11:53 AM Djordje Gavrilovic wrote: > Hi guys, > I have a following issue with migrating from version 1.1.1f to 3.0.2: > > I generate bmstore.pkcs12.pem file with the following commands: > > ``` > > openssl req -newkey rsa:2048 -sha1 -keyout bmstore.pkcs8.pem -nodes > -x509 -days 999 -out bmstore.x509.crt -subj > "/C=DE/ST=Nsk/L=Nsk/O=BM/OU=BM/CN=AS" > openssl pkcs12 -export -in bmstore.x509.crt -inkey bmstore.pkcs8.pem > -out bmstore.pkcs12.pem -passin pass:changeit -passout pass:changeit > ``` > > This file is genearted with different openssl versions differently. Both > versions of the file are attached. > > Based on that file I generate: > > ``` > keytool -importkeystore -srckeystore bmstore.pkcs12.pem -srcstoretype > PKCS12 -srcstorepass changeit -destkeystore bmstore.pkcs8.x509.jks > -deststorepass changeit > ``` > > But keytool works only with the bmstore.pkcs12.pem generated with old > version of openssl and creates bmstore.pkcs8.x509.jks > > The current version of openssl generates bmstore.pkcs12.pem in another > format and keytool throws an exception: > > ``` > Importing keystore bmstore.pkcs12.pem to bmstore.pkcs8.x509.jks... > keytool error: java.io.IOException: keystore password was incorrect > > ``` > -- Cordialement, Erwann Abalea.
Keytool issue with version 3.0.2
Hi guys, I have a following issue with migrating from version 1.1.1f to 3.0.2: I generate bmstore.pkcs12.pem file with the following commands: ``` openssl req -newkey rsa:2048 -sha1 -keyout bmstore.pkcs8.pem -nodes -x509 -days 999 -out bmstore.x509.crt -subj "/C=DE/ST=Nsk/L=Nsk/O=BM/OU=BM/CN=AS" openssl pkcs12 -export -in bmstore.x509.crt -inkey bmstore.pkcs8.pem -out bmstore.pkcs12.pem -passin pass:changeit -passout pass:changeit ``` This file is genearted with different openssl versions differently. Both versions of the file are attached. Based on that file I generate: ``` keytool -importkeystore -srckeystore bmstore.pkcs12.pem -srcstoretype PKCS12 -srcstorepass changeit -destkeystore bmstore.pkcs8.x509.jks -deststorepass changeit ``` But keytool works only with the bmstore.pkcs12.pem generated with old version of openssl and creates bmstore.pkcs8.x509.jks The current version of openssl generates bmstore.pkcs12.pem in another format and keytool throws an exception: ``` Importing keystore bmstore.pkcs12.pem to bmstore.pkcs8.x509.jks... keytool error: java.io.IOException: keystore password was incorrect ``` <>
Re: openssl 3.0.3 minor patches to build on SCO OpenServer 5.0.7
On Wed, 2022-05-18 at 16:37 -0500, Kevin R. Bulgrien wrote: > > From: "Matt Caswell" > > Subject: Re: openssl 1.1.1 minor patches to build on SCO OpenServer > > 5.0.7 > > > > Hi Kevin, > > > > The patch in s_socket.c is likely to be acceptable. It looks > > reasonable > > to me, it may well be useful on other systems and can probably be > > described as a bug fix. > > > > The other changes require the new OPENSSL_SYS_SCO5 define and are > > essentially adding support for a new platform into the codebase. > > > > We have a couple of policies which describe acceptable changes in > > this area. > > > > Our platform policy says: > > > > "Support for a new platform should only be added if it is being > > adopted > > as a primary, secondary or community platform." > > > > https://www.openssl.org/policies/platformpolicy.html > > > > Essentially this means that someone has to volunteer to be a > > community > > maintainer of the platform moving forwards, i.e. they are the > > contact > > point for any bug fixes/problems that may arise on that platform. > > You > > don't need to be a committer on the project to be a platform > > maintainer. > > Interestingly, openssl 1.1.1o already has support for this platform, > but > it is not up-to-date since I need these patches: With that on mind I'd say we could treat this as a bug fix. > > This is interesting, and I suppose subject to interpretation > differences. > My patches entirely involve configuration changes. I.e. They ONLY > affect > pre-processor directives. In my opinion, pre-processor directives > are > not code. I suppose this response means the project interprets code > as > source code files? If so, then a clarification of terms in the > documents > linked might be in order. We interpret any changes in the .c, .h, and similar files as source code changes. > > As far as a community maintainership goes, in my current employment > situation, > it is in my interest to build openssl releases as they come out. As > long as > maintainership is primarily related to build issues, I don't really > have a > problem with doing this. The main concern I would have is that I do > not have > an in-depth knowledge of the openssl code-base, so if maintainership > involves > code issues that pretty much any platform might encounter because the > code is > the same for them, I cannot claim to commensurate experience along > those lines. Yeah, this is mostly about build fixes. Of course if there is a run- time issue reported that affects only your platform we would have to cooperate on the fix there as well, but I would not expect many of these. -- Tomáš Mráz, OpenSSL