Short, Todd via RT | 26 May 17:51 2015
Picon

Re: [openssl.org #3722] Patch to add -preserve_dates option to x509 app

Hello All,

We have an updated patch for this. Github link:

https://github.com/akamai/openssl/commit/e3909f5dc3ce841515cbe925a0d5138664a0c41c


--
-Todd Short
// “One if by land, two if by sea, three if by the Internet."

On Feb 27, 2015, at 3:14 PM, Short, Todd via RT <rt <at> openssl.org> wrote:

Hello OpenSSL Org:

This is a change that Akamai has made to its implementation of OpenSSL.

Version: master branch
Description: Add -preserve_dates option to x509 app

If -preserve_dates is passed to the x509 app, any changes to the certificate will not change the validity dates.

Github link:
https://github.com/akamai/openssl/commit/b11e6b59e802f9fab0675126018529db7f2259e0

And attachment.

Thank you.
--
-Todd Short
// tshort <at> akamai.com<mailto:tshort <at> akamai.com>
// “One if by land, two if by sea, three if by the Internet."

<0007-Add-preserve-dates-to-x509-app.patch>
_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
(Continue reading)

Lei Zhang via RT | 26 May 16:35 2015
Picon

Re: [openssl.org #3843] OpenSSL 1.0.1* and below: incorrect use of _lrotl()


> On May 26, 2015, at 4:57 PM, Andy Polyakov <appro <at> openssl.org> wrote:
> 
>>>> And linux-x86_64 won't work here, since it uses some instructions not supported by MIC. 
>>> 
>>> But all x86_64 modules feature run-time switch, when processor
>>> capabilities are detected [with cpuid] and code that can't be executed
>>> on any particular processor won't execute. Or do you mean that fails to
>>> *compile* it with -mmic? Or do you mean that cpuid doesn't work on mic?
>>> But I recall that there is cpuid...
>> 
>> It fails to compile with -mmic:
>> x86_64cpuid.s:165: Error: `pxor' is not supported on `k1om'
> 
> I see, thanks. In other words, as it turns out my suggestion about
> run-time switch does not apply in this case, because minimum of SSE2 is
> actually *assumed* for x86_64 platform. And this doesn't hold true for
> Knights Corner. But it does hold true for Knights Landing, doesn't it?

Yes, Knights Landing supposedly implements AVX512, which is backward compatible with older SIMD instructions.

> I see no point in attempting to accommodate assembler support for Knights
> Corner (too rare processor) and would appreciate if you could confirm if
> following works with 1.0.2:
> 
> ./Configure linux-x86_64-icc no-asm -mmic

Yes, it works. 

Solar, should I update JtR's READ-MIC to switch back to using OpenSSL? BTW, I'm not sure if switching
(Continue reading)

Matt Caswell via RT | 26 May 11:57 2015
Picon

[openssl.org #3862] Patch: Compiler messages on OpenVMS

On Mon May 25 22:02:21 2015, zinser <at> zinser.no-ip.info wrote:
> Hello,
>
> I've just build OpenSSL 1.0.2a on
>
> OpenVMS 8.3 (Alpha)
> HP C V 7.3
>
> The build (and test) went very smooth, with just three minor
> complaints by the
> compiler:
>
> Compiling The BIO Library Files. (LIBRARY,LIB)
> bio_lib.c
> bio_cb.c
> ...
> bss_dgram.c
>
> if (timeleft.tv_sec < 0) {
> ............^
> %CC-I-QUESTCOMPARE, In this statement, the unsigned expression
> "timeleft.tv_sec" is being compared with a relational operator to a
> constant
> whose v
> alue is not greater than zero. This might not be what you intended.
> at line number 313 in file PUBLIC$ROOT:
> [UTIL.LIBS.OPENSSL102.CRYPTO.BIO]BSS_DGRAM.C;1
>
> ...
> Building The SYS$DISK:[-.ALPHA.EXE.SSL]SSL_LIBSSL32.OLB Library.
(Continue reading)

rt@openssl.org via RT | 26 May 10:57 2015
Picon

Re: [openssl.org #3843] OpenSSL 1.0.1* and below: incorrect use of _lrotl()

>>> And linux-x86_64 won't work here, since it uses some instructions not supported by MIC. 
>>
>> But all x86_64 modules feature run-time switch, when processor
>> capabilities are detected [with cpuid] and code that can't be executed
>> on any particular processor won't execute. Or do you mean that fails to
>> *compile* it with -mmic? Or do you mean that cpuid doesn't work on mic?
>> But I recall that there is cpuid...
> 
> It fails to compile with -mmic:
> x86_64cpuid.s:165: Error: `pxor' is not supported on `k1om'

I see, thanks. In other words, as it turns out my suggestion about
run-time switch does not apply in this case, because minimum of SSE2 is
actually *assumed* for x86_64 platform. And this doesn't hold true for
Knights Corner. But it does hold true for Knights Landing, doesn't it? I
see no point in attempting to accommodate assembler support for Knights
Corner (too rare processor) and would appreciate if you could confirm if
following works with 1.0.2:

./Configure linux-x86_64-icc no-asm -mmic

BTW, _lrotl fix is applied to 1.0.1, but not earlier versions, which are
open for security fixes only.

_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Lei Zhang via RT | 26 May 03:14 2015
Picon

Re: [openssl.org #3843] OpenSSL 1.0.1* and below: incorrect use of _lrotl()


> On May 26, 2015, at 12:01 AM, Andy Polyakov <appro <at> openssl.org> wrote:
> 
>>>> Yes, I added a new target "linux-mic" into Configure, which is slightly modified from "linux-generic64".
>>>> 
>>>> From the original patch:
>>>> 
>>>> (...)
>>>> "linux-generic64","gcc:-DTERMIO -O3 -Wall::-D_REENTRANT::-ldl:SIXTY_FOUR_BIT_LONG
RC4_CHAR RC4_CHUNK DES_INT DES_UNROLL BF_PTR:${no_asm}:dlfcn:linux-shared:-fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
>>>> +"linux-mic","icc:-mmic -DTERMIO -O3 -Wall::-D_REENTRANT::-ldl:SIXTY_FOUR_BIT_LONG
RC4_CHAR RC4_CHUNK DES_INT DES_UNROLL BF_PTR:${no_asm}:dlfcn:linux-shared:-fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
>>>> (...)
>>> 
>>> But what prevents you from 'env CC=icc ./Configure linux-generic64
>>> -mmic'? Or same with linux-x86_64? Can you confirm if './Configure
>>> linux-x86_64-icc -mmic' works in 1.0.2?
>> 
>> 'CC="icc -mmic" ./Configure shared linux-generic64' works in 1.0.0. It's better than modifying
Configure. I just didn't think of it. 
>> 
>> But it doesn't work in 1.0.2, getting some link error:
>> ../libcrypto.so: undefined reference to `rc4_md5_enc'
> 
> Yes, similar issue was reported in another context and it will be
> resolved. Meanwhile could you pass explicit no-asm to confirm that it's
> in *general* viable option for you.
> 
>> And linux-x86_64 won't work here, since it uses some instructions not supported by MIC. 
> 
(Continue reading)

Rich Salz via RT | 26 May 01:15 2015
Picon

[openssl.org #3861] [patch] Fix memory leak in req

commit cf89a80e25b79ae0e6004e4a2509bf656fb59168
Author: Hanno B<C3><B6>ck <hanno <at> hboeck.de>
Date: Mon May 25 16:18:07 2015 -0400

RT3861: Mem/bio leak in req command

The "out" variable is used for both key and csr. Close it after
writing the first one so it can be re-used when writing the other.

Signed-off-by: Rich Salz <rsalz <at> openssl.org>
Reviewed-by: Tim Hudson <tjh <at> openssl.org>

_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Picon

[openssl.org #3862] Patch: Compiler messages on OpenVMS

Hello,

I've just build OpenSSL 1.0.2a on

OpenVMS 8.3 (Alpha)
HP C V 7.3

The build (and test) went very smooth, with just three minor complaints by the 
compiler:

 Compiling The BIO Library Files. (LIBRARY,LIB)
        bio_lib.c
        bio_cb.c
        ...
        bss_dgram.c

        if (timeleft.tv_sec < 0) {
............^
%CC-I-QUESTCOMPARE, In this statement, the unsigned expression 
"timeleft.tv_sec" is being compared with a relational operator to a constant 
whose v
alue is not greater than zero.  This might not be what you intended.
at line number 313 in file PUBLIC$ROOT:
[UTIL.LIBS.OPENSSL102.CRYPTO.BIO]BSS_DGRAM.C;1

...
Building The SYS$DISK:[-.ALPHA.EXE.SSL]SSL_LIBSSL32.OLB Library.
        s2_meth.c
        s2_srvr.c
        ...
(Continue reading)

Hanno Boeck via RT | 25 May 22:02 2015
Picon

[openssl.org #3861] [patch] Fix memory leak in req

The code in apps/req.c will use the variable out for both the key and
the csr outfile.

This causes a memory leak because if both a private key and a csr is
written the variable is re-used without freeing it.

See attached patch. (This could also be fixed by using a different var
for both files, could be considered more consistent, but I decided to
use a less invasive patch that just needs to add a single line.)

Please apply patch.

--

-- 
Hanno Böck
http://hboeck.de/

mail/jabber: hanno <at> hboeck.de
GPG: BBB51E42

_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Dmitry Belyavsky | 25 May 21:40 2015
Picon

GOST89 cipher control command

Hello Openssl team,

GOST89 cipher algorithm seems to be the only cipher algorithm supporting more than one sets of S-boxes.

Current implementation of the GOST89 cipher provided by the ccgost engine does not allow to specify usage of particular S-boxes for a particular EVP_CIPHER_CTX instance. If I understand correctly, the only way to do it is to specify a ctrl-command and implement it in the engine.

Is it OK to reuse EVP_CTRL_INIT ctrl command for this purpose or it will be better to add a special value for this?

Thank you!

--
SY, Dmitry Belyavsky
_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Andy Polyakov via RT | 25 May 18:02 2015
Picon

Re: [openssl.org #3843] OpenSSL 1.0.1* and below: incorrect use of _lrotl()

>>> Yes, I added a new target "linux-mic" into Configure, which is slightly modified from "linux-generic64".
>>>
>>> From the original patch:
>>>
>>> (...)
>>> "linux-generic64","gcc:-DTERMIO -O3 -Wall::-D_REENTRANT::-ldl:SIXTY_FOUR_BIT_LONG RC4_CHAR
RC4_CHUNK DES_INT DES_UNROLL BF_PTR:${no_asm}:dlfcn:linux-shared:-fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
>>> +"linux-mic","icc:-mmic -DTERMIO -O3 -Wall::-D_REENTRANT::-ldl:SIXTY_FOUR_BIT_LONG RC4_CHAR
RC4_CHUNK DES_INT DES_UNROLL BF_PTR:${no_asm}:dlfcn:linux-shared:-fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
>>> (...)
>>
>> But what prevents you from 'env CC=icc ./Configure linux-generic64
>> -mmic'? Or same with linux-x86_64? Can you confirm if './Configure
>> linux-x86_64-icc -mmic' works in 1.0.2?
> 
> 'CC="icc -mmic" ./Configure shared linux-generic64' works in 1.0.0. It's better than modifying
Configure. I just didn't think of it. 
> 
> But it doesn't work in 1.0.2, getting some link error:
> ../libcrypto.so: undefined reference to `rc4_md5_enc'

Yes, similar issue was reported in another context and it will be
resolved. Meanwhile could you pass explicit no-asm to confirm that it's
in *general* viable option for you.

> And linux-x86_64 won't work here, since it uses some instructions not supported by MIC. 

But all x86_64 modules feature run-time switch, when processor
capabilities are detected [with cpuid] and code that can't be executed
on any particular processor won't execute. Or do you mean that fails to
*compile* it with -mmic? Or do you mean that cpuid doesn't work on mic?
But I recall that there is cpuid...

_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Andy Polyakov via RT | 25 May 17:53 2015
Picon

Re: [openssl.org #3773] [PATCH] Configure support for OCTEON boards

Hi,

> This patch adds Cavium Networks' OCTEON target to Configure file. The diff  is taken against
OpenSSL-1.0.2a release.

Well, objective is not to collect as many exotic config lines as
possible, but rather more generic ones that we are ready to support and
make them flexible enough to be reusable in more specific contexts. For
example in this case what prevents you from using

./Configure linux-generic32
--cross-compile-prefix=mips64-octeon-linux-gnu- -mabi=n32

and

./Configure linux-generic64 --cross-compile-prefix=mips64-octeon-linux-gnu-

Or better yet

./Configure linux-mips64 --cross-compile-prefix=misp4-octeon-linux-gnu-

and

./Configure linux64-mips64 --cross-compile-prefix=misp4-octeon-linux-gnu-

and take advantage of assembly support?

_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


Gmane