The ITUGLIB team is currently involved in build/test of OpenSSL 1.1.1p and 3.0.4. As of now, we are having a lot of success with 3.0.4 and it should show up on the website some time tomorrow. The 1.1.1p build, however, has issues and is failing a number of tests including hard-looping/stack corruption of anything relating to the BN subset of cryptographic algorithms. I am looking into the cause but are not currently expecting that this patch will be made available or recommended. More to come...

On Tuesday, June 21, 2022 at 9:58:49 p.m. UTC-4, Randall wrote:
> The ITUGLIB team is currently involved in build/test of OpenSSL 1.1.1p and 3.0.4. As of now, we are having a lot of success with 3.0.4 and it should show up on the website some time tomorrow. The 1.1.1p build, however, has issues and is failing a number of tests including hard-looping/stack corruption of anything relating to the BN subset of cryptographic algorithms. I am looking into the cause but are not currently expecting that this patch will be made available or recommended. More to come...

It turns out that the test suite does not like running without verbose mode.. At this point, only the ecparam test is failing, which is the same as 1.1..1o, so things are looking better. I will update when the test cycles are all done and packages available.

On Wednesday, June 22, 2022 at 2:42:27 p.m. UTC-4, Randall wrote:
> On Tuesday, June 21, 2022 at 9:58:49 p.m. UTC-4, Randall wrote:
> > The ITUGLIB team is currently involved in build/test of OpenSSL 1.1.1p and 3.0.4. As of now, we are having a lot of success with 3.0.4 and it should show up on the website some time tomorrow. The 1.1.1p build, however, has issues and is failing a number of tests including hard-looping/stack corruption of anything relating to the BN subset of cryptographic algorithms. I am looking into the cause but are not currently expecting that this patch will be made available or recommended. More to come...
> It turns out that the test suite does not like running without verbose mode. At this point, only the ecparam test is failing, which is the same as 1..1.1o, so things are looking better. I will update when the test cycles are all done and packages available.

I am trying a new build technique for 1.1. Instead of running each build it its own job, all builds will run in one pipeline. This should significantly improve checkout speed, which is the bottleneck on our J-series machine. The L-series OSSNS process is significantly faster but even with that, checkout is still the rate-limiting step for OpenSSL builds. There are over 20000 files in the repository, so that is a big checkout. More to come. We probably will push the L-series builds to the ITUGLIB website as soon as they are ready.

On Monday, June 27, 2022 at 11:33:56 a.m. UTC-4, Randall wrote:
> On Wednesday, June 22, 2022 at 2:42:27 p.m. UTC-4, Randall wrote:
> > On Tuesday, June 21, 2022 at 9:58:49 p.m. UTC-4, Randall wrote:
> > > The ITUGLIB team is currently involved in build/test of OpenSSL 1.1.1p and 3.0.4. As of now, we are having a lot of success with 3.0.4 and it should show up on the website some time tomorrow. The 1.1.1p build, however, has issues and is failing a number of tests including hard-looping/stack corruption of anything relating to the BN subset of cryptographic algorithms. I am looking into the cause but are not currently expecting that this patch will be made available or recommended. More to come...
> > It turns out that the test suite does not like running without verbose mode. At this point, only the ecparam test is failing, which is the same as 1.1.1o, so things are looking better. I will update when the test cycles are all done and packages available.
> I am trying a new build technique for 1.1. Instead of running each build it its own job, all builds will run in one pipeline. This should significantly improve checkout speed, which is the bottleneck on our J-series machine.. The L-series OSSNS process is significantly faster but even with that, checkout is still the rate-limiting step for OpenSSL builds. There are over 20000 files in the repository, so that is a big checkout. More to come. We probably will push the L-series builds to the ITUGLIB website as soon as they are ready.

We are currently having some heating/cooling issues and as a result the ITUGLIB website might not be available temporarily. If you urgently need to build OpenSSL 3.0.4, please clone it from https://github.com/openssl/openssl.git or download the tarball from https://www.openssl.org/source/. For OpenSSL 1.1.1p, clone from https://github.com/ituglib/openssl.git and use the ituglib_release branch or OpenSSL_1_1_1p_NSK tag. Running ./Configure should give you the appropriate build, but the normal builds for J-series are ./Configure nonstop-nse, and for L-series ./Configure nonstop-nsx_64, then run make. You need to have /usr/coreutils/bin in your PATH. The build will use the c99 compiler in OSS, so you will need that too. There should not be any other prerequisites - if you find any, please let us know here.

Regards,
Randall Becker
On behalf of the ITUGLIB Technical Committee

On 6/27/2022 3:13 PM, Randall wrote:
> On Monday, June 27, 2022 at 11:33:56 a.m. UTC-4, Randall wrote:
>> On Wednesday, June 22, 2022 at 2:42:27 p.m. UTC-4, Randall wrote:
>>> On Tuesday, June 21, 2022 at 9:58:49 p.m. UTC-4, Randall wrote:
>>>> The ITUGLIB team is currently involved in build/test of OpenSSL 1.1.1p and 3.0.4. As of now, we are having a lot of success with 3.0.4 and it should show up on the website some time tomorrow. The 1.1.1p build, however, has issues and is failing a number of tests including hard-looping/stack corruption of anything relating to the BN subset of cryptographic algorithms. I am looking into the cause but are not currently expecting that this patch will be made available or recommended. More to come...
>>> It turns out that the test suite does not like running without verbose mode. At this point, only the ecparam test is failing, which is the same as 1.1.1o, so things are looking better. I will update when the test cycles are all done and packages available.
>> I am trying a new build technique for 1.1. Instead of running each build it its own job, all builds will run in one pipeline. This should significantly improve checkout speed, which is the bottleneck on our J-series machine. The L-series OSSNS process is significantly faster but even with that, checkout is still the rate-limiting step for OpenSSL builds. There are over 20000 files in the repository, so that is a big checkout. More to come. We probably will push the L-series builds to the ITUGLIB website as soon as they are ready.
>
> We are currently having some heating/cooling issues and as a result the ITUGLIB website might not be available temporarily. If you urgently need to build OpenSSL 3.0.4, please clone it from https://github.com/openssl/openssl.git or download the tarball from https://www.openssl.org/source/. For OpenSSL 1.1.1p, clone from https://github.com/ituglib/openssl.git and use the ituglib_release branch or OpenSSL_1_1_1p_NSK tag. Running ./Configure should give you the appropriate build, but the normal builds for J-series are ./Configure nonstop-nse, and for L-series ./Configure nonstop-nsx_64, then run make. You need to have /usr/coreutils/bin in your PATH. The build will use the c99 compiler in OSS, so you will need that too. There should not be any other prerequisites - if you find any, please let us know here.

Is it even worth it to deal with 3.0.4, since 3.0.5 is coming out to fix
a data corruption issue (that could lead to remote execution)?

Granted, the issue is with code that uses AVX512, and I'm not sure that
the L-Series release does use AVX512 (haven't looked recently).

On Tuesday, June 28, 2022 at 11:55:45 a.m. UTC-4, red floyd wrote:
> On 6/27/2022 3:13 PM, Randall wrote:
> > On Monday, June 27, 2022 at 11:33:56 a.m. UTC-4, Randall wrote:
> >> On Wednesday, June 22, 2022 at 2:42:27 p.m. UTC-4, Randall wrote:
> >>> On Tuesday, June 21, 2022 at 9:58:49 p.m. UTC-4, Randall wrote:
> >>>> The ITUGLIB team is currently involved in build/test of OpenSSL 1.1.1p and 3.0.4. As of now, we are having a lot of success with 3.0.4 and it should show up on the website some time tomorrow. The 1.1.1p build, however, has issues and is failing a number of tests including hard-looping/stack corruption of anything relating to the BN subset of cryptographic algorithms.. I am looking into the cause but are not currently expecting that this patch will be made available or recommended. More to come...
> >>> It turns out that the test suite does not like running without verbose mode. At this point, only the ecparam test is failing, which is the same as 1.1.1o, so things are looking better. I will update when the test cycles are all done and packages available.
> >> I am trying a new build technique for 1.1. Instead of running each build it its own job, all builds will run in one pipeline. This should significantly improve checkout speed, which is the bottleneck on our J-series machine. The L-series OSSNS process is significantly faster but even with that, checkout is still the rate-limiting step for OpenSSL builds. There are over 20000 files in the repository, so that is a big checkout. More to come. We probably will push the L-series builds to the ITUGLIB website as soon as they are ready.
> >
> > We are currently having some heating/cooling issues and as a result the ITUGLIB website might not be available temporarily. If you urgently need to build OpenSSL 3.0.4, please clone it from https://github.com/openssl/openssl.git or download the tarball from https://www.openssl.org/source/. For OpenSSL 1.1.1p, clone from https://github.com/ituglib/openssl.git and use the ituglib_release branch or OpenSSL_1_1_1p_NSK tag. Running ./Configure should give you the appropriate build, but the normal builds for J-series are ../Configure nonstop-nse, and for L-series ./Configure nonstop-nsx_64, then run make. You need to have /usr/coreutils/bin in your PATH. The build will use the c99 compiler in OSS, so you will need that too. There should not be any other prerequisites - if you find any, please let us know here.
> Is it even worth it to deal with 3.0.4, since 3.0.5 is coming out to fix
> a data corruption issue (that could lead to remote execution)?
>
> Granted, the issue is with code that uses AVX512, and I'm not sure that
> the L-Series release does use AVX512 (haven't looked recently).

I don't have a date on 3.0.5 as of yet. 3.0.3 was skipped due to compile problems. Your choice really.
Regards,
Randall

On Tuesday, June 28, 2022 at 3:17:06 p.m. UTC-4, Randall wrote:
> On Tuesday, June 28, 2022 at 11:55:45 a.m. UTC-4, red floyd wrote:
> > On 6/27/2022 3:13 PM, Randall wrote:
> > > On Monday, June 27, 2022 at 11:33:56 a.m. UTC-4, Randall wrote:
> > >> On Wednesday, June 22, 2022 at 2:42:27 p.m. UTC-4, Randall wrote:
> > >>> On Tuesday, June 21, 2022 at 9:58:49 p.m. UTC-4, Randall wrote:
> > >>>> The ITUGLIB team is currently involved in build/test of OpenSSL 1.1.1p and 3.0.4. As of now, we are having a lot of success with 3.0.4 and it should show up on the website some time tomorrow. The 1.1.1p build, however, has issues and is failing a number of tests including hard-looping/stack corruption of anything relating to the BN subset of cryptographic algorithms. I am looking into the cause but are not currently expecting that this patch will be made available or recommended. More to come...
> > >>> It turns out that the test suite does not like running without verbose mode. At this point, only the ecparam test is failing, which is the same as 1.1.1o, so things are looking better. I will update when the test cycles are all done and packages available.
> > >> I am trying a new build technique for 1.1. Instead of running each build it its own job, all builds will run in one pipeline. This should significantly improve checkout speed, which is the bottleneck on our J-series machine. The L-series OSSNS process is significantly faster but even with that, checkout is still the rate-limiting step for OpenSSL builds. There are over 20000 files in the repository, so that is a big checkout. More to come. We probably will push the L-series builds to the ITUGLIB website as soon as they are ready.
> > >
> > > We are currently having some heating/cooling issues and as a result the ITUGLIB website might not be available temporarily. If you urgently need to build OpenSSL 3.0.4, please clone it from https://github.com/openssl/openssl.git or download the tarball from https://www.openssl.org/source/. For OpenSSL 1.1.1p, clone from https://github.com/ituglib/openssl.git and use the ituglib_release branch or OpenSSL_1_1_1p_NSK tag. Running ./Configure should give you the appropriate build, but the normal builds for J-series are ./Configure nonstop-nse, and for L-series ./Configure nonstop-nsx_64, then run make. You need to have /usr/coreutils/bin in your PATH. The build will use the c99 compiler in OSS, so you will need that too. There should not be any other prerequisites - if you find any, please let us know here.
> > Is it even worth it to deal with 3.0.4, since 3.0.5 is coming out to fix
> > a data corruption issue (that could lead to remote execution)?
> >
> > Granted, the issue is with code that uses AVX512, and I'm not sure that
> > the L-Series release does use AVX512 (haven't looked recently).
> I don't have a date on 3.0.5 as of yet. 3.0.3 was skipped due to compile problems. Your choice really.
> Regards,
> Randall

Hi All,

FYI: The 3.0.4 and 1.1.1p releases for OpenSSL on L-series are now on the ITUGLIB website. J-series to follow in the next few days.

Regards,
Randall

On Tuesday, June 28, 2022 at 11:05:30 p.m. UTC-4, Randall wrote:
> On Tuesday, June 28, 2022 at 3:17:06 p.m. UTC-4, Randall wrote:
> > On Tuesday, June 28, 2022 at 11:55:45 a.m. UTC-4, red floyd wrote:
> > > On 6/27/2022 3:13 PM, Randall wrote:
> > > > On Monday, June 27, 2022 at 11:33:56 a.m. UTC-4, Randall wrote:
> > > >> On Wednesday, June 22, 2022 at 2:42:27 p.m. UTC-4, Randall wrote:
> > > >>> On Tuesday, June 21, 2022 at 9:58:49 p.m. UTC-4, Randall wrote:
> > > >>>> The ITUGLIB team is currently involved in build/test of OpenSSL 1.1.1p and 3.0.4. As of now, we are having a lot of success with 3.0.4 and it should show up on the website some time tomorrow. The 1.1.1p build, however, has issues and is failing a number of tests including hard-looping/stack corruption of anything relating to the BN subset of cryptographic algorithms. I am looking into the cause but are not currently expecting that this patch will be made available or recommended. More to come...
> > > >>> It turns out that the test suite does not like running without verbose mode. At this point, only the ecparam test is failing, which is the same as 1.1.1o, so things are looking better. I will update when the test cycles are all done and packages available.
> > > >> I am trying a new build technique for 1.1. Instead of running each build it its own job, all builds will run in one pipeline. This should significantly improve checkout speed, which is the bottleneck on our J-series machine. The L-series OSSNS process is significantly faster but even with that, checkout is still the rate-limiting step for OpenSSL builds. There are over 20000 files in the repository, so that is a big checkout. More to come. We probably will push the L-series builds to the ITUGLIB website as soon as they are ready.
> > > >
> > > > We are currently having some heating/cooling issues and as a result the ITUGLIB website might not be available temporarily. If you urgently need to build OpenSSL 3.0.4, please clone it from https://github.com/openssl/openssl.git or download the tarball from https://www.openssl.org/source/. For OpenSSL 1.1.1p, clone from https://github.com/ituglib/openssl.git and use the ituglib_release branch or OpenSSL_1_1_1p_NSK tag. Running ./Configure should give you the appropriate build, but the normal builds for J-series are ./Configure nonstop-nse, and for L-series ./Configure nonstop-nsx_64, then run make. You need to have /usr/coreutils/bin in your PATH. The build will use the c99 compiler in OSS, so you will need that too. There should not be any other prerequisites - if you find any, please let us know here.
> > > Is it even worth it to deal with 3.0.4, since 3.0.5 is coming out to fix
> > > a data corruption issue (that could lead to remote execution)?
> > >
> > > Granted, the issue is with code that uses AVX512, and I'm not sure that
> > > the L-Series release does use AVX512 (haven't looked recently).
> > I don't have a date on 3.0.5 as of yet. 3.0.3 was skipped due to compile problems. Your choice really.
> > Regards,
> > Randall
> Hi All,
>
> FYI: The 3.0.4 and 1.1.1p releases for OpenSSL on L-series are now on the ITUGLIB website. J-series to follow in the next few days.
>
> Regards,
> Randall

3.0.4 unthreaded 32 and 64 bit for J-series are now on the ITUGLIB website. We are still having technical issues, so other builds are temporarily on hold, but you can do them yourselves if urgently needed.

Regards,
Randall

On Tuesday, June 28, 2022 at 11:55:45 a.m. UTC-4, red floyd wrote:
> On 6/27/2022 3:13 PM, Randall wrote:
> > On Monday, June 27, 2022 at 11:33:56 a.m. UTC-4, Randall wrote:
> >> On Wednesday, June 22, 2022 at 2:42:27 p.m. UTC-4, Randall wrote:
> >>> On Tuesday, June 21, 2022 at 9:58:49 p.m. UTC-4, Randall wrote:
> >>>> The ITUGLIB team is currently involved in build/test of OpenSSL 1.1.1p and 3.0.4. As of now, we are having a lot of success with 3.0.4 and it should show up on the website some time tomorrow. The 1.1.1p build, however, has issues and is failing a number of tests including hard-looping/stack corruption of anything relating to the BN subset of cryptographic algorithms.. I am looking into the cause but are not currently expecting that this patch will be made available or recommended. More to come...
> >>> It turns out that the test suite does not like running without verbose mode. At this point, only the ecparam test is failing, which is the same as 1.1.1o, so things are looking better. I will update when the test cycles are all done and packages available.
> >> I am trying a new build technique for 1.1. Instead of running each build it its own job, all builds will run in one pipeline. This should significantly improve checkout speed, which is the bottleneck on our J-series machine. The L-series OSSNS process is significantly faster but even with that, checkout is still the rate-limiting step for OpenSSL builds. There are over 20000 files in the repository, so that is a big checkout. More to come. We probably will push the L-series builds to the ITUGLIB website as soon as they are ready.
> >
> > We are currently having some heating/cooling issues and as a result the ITUGLIB website might not be available temporarily. If you urgently need to build OpenSSL 3.0.4, please clone it from https://github.com/openssl/openssl.git or download the tarball from https://www.openssl.org/source/. For OpenSSL 1.1.1p, clone from https://github.com/ituglib/openssl.git and use the ituglib_release branch or OpenSSL_1_1_1p_NSK tag. Running ./Configure should give you the appropriate build, but the normal builds for J-series are ../Configure nonstop-nse, and for L-series ./Configure nonstop-nsx_64, then run make. You need to have /usr/coreutils/bin in your PATH. The build will use the c99 compiler in OSS, so you will need that too. There should not be any other prerequisites - if you find any, please let us know here.
> Is it even worth it to deal with 3.0.4, since 3.0.5 is coming out to fix
> a data corruption issue (that could lead to remote execution)?
>
> Granted, the issue is with code that uses AVX512, and I'm not sure that
> the L-Series release does use AVX512 (haven't looked recently).

3.0.5 and 1.1.1

On Tuesday, June 28, 2022 at 11:55:45 a.m. UTC-4, red floyd wrote:
> On 6/27/2022 3:13 PM, Randall wrote:
> > On Monday, June 27, 2022 at 11:33:56 a.m. UTC-4, Randall wrote:
> >> On Wednesday, June 22, 2022 at 2:42:27 p.m. UTC-4, Randall wrote:
> >>> On Tuesday, June 21, 2022 at 9:58:49 p.m. UTC-4, Randall wrote:
> >>>> The ITUGLIB team is currently involved in build/test of OpenSSL 1.1.1p and 3.0.4. As of now, we are having a lot of success with 3.0.4 and it should show up on the website some time tomorrow. The 1.1.1p build, however, has issues and is failing a number of tests including hard-looping/stack corruption of anything relating to the BN subset of cryptographic algorithms.. I am looking into the cause but are not currently expecting that this patch will be made available or recommended. More to come...
> >>> It turns out that the test suite does not like running without verbose mode. At this point, only the ecparam test is failing, which is the same as 1.1.1o, so things are looking better. I will update when the test cycles are all done and packages available.
> >> I am trying a new build technique for 1.1. Instead of running each build it its own job, all builds will run in one pipeline. This should significantly improve checkout speed, which is the bottleneck on our J-series machine. The L-series OSSNS process is significantly faster but even with that, checkout is still the rate-limiting step for OpenSSL builds. There are over 20000 files in the repository, so that is a big checkout. More to come. We probably will push the L-series builds to the ITUGLIB website as soon as they are ready.
> >
> > We are currently having some heating/cooling issues and as a result the ITUGLIB website might not be available temporarily. If you urgently need to build OpenSSL 3.0.4, please clone it from https://github.com/openssl/openssl.git or download the tarball from https://www.openssl.org/source/. For OpenSSL 1.1.1p, clone from https://github.com/ituglib/openssl.git and use the ituglib_release branch or OpenSSL_1_1_1p_NSK tag. Running ./Configure should give you the appropriate build, but the normal builds for J-series are ../Configure nonstop-nse, and for L-series ./Configure nonstop-nsx_64, then run make. You need to have /usr/coreutils/bin in your PATH. The build will use the c99 compiler in OSS, so you will need that too. There should not be any other prerequisites - if you find any, please let us know here.
> Is it even worth it to deal with 3.0.4, since 3.0.5 is coming out to fix
> a data corruption issue (that could lead to remote execution)?
>
> Granted, the issue is with code that uses AVX512, and I'm not sure that
> the L-Series release does use AVX512 (haven't looked recently).

Just an FYI: 3.0.5 and 1.1.1q are in the pipeline now, so if you waited, you might have made a good decision.
R.