[openssl-dev] [libcrypto EVP] valgrind reports many memory leaks in wiki-example

[U.Mutlu]

Hi,
running the following example from the openssl wiki site under valgrind
gives many memory-leaks in the underlying library functions:
https://wiki.openssl.org/index.php/EVP_Symmetric_Encryption_and_Decryption

$ gcc -Wall -O2 test_encdec.c -lcrypto
$ valgrind --tool=memcheck --leak-check=full --show-leak-kinds=all 
--track-origins=yes -v ./a.out &>valgrind-output.txt


Attached is the valgrind-output. It says:
  34 not-freed blocks

Are these maybe false-positives? The leak summary in the output says this:
==9895== LEAK SUMMARY:
==9895==definitely lost: 0 bytes in 0 blocks
==9895==indirectly lost: 0 bytes in 0 blocks
==9895==  possibly lost: 0 bytes in 0 blocks
==9895==still reachable: 2,632 bytes in 34 blocks
==9895== suppressed: 0 bytes in 0 blocks

OS: Debian 8 amd64, using libs from the Debian repo:
libcrypto: 5.6.1-6+deb8u1
openssl: 1.0.1k-3+deb8u1

--
U.Mutlu


valgrind-output.txt.gz
Description: application/gzip
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [libcrypto EVP] valgrind reports many memory leaks in wiki-example

[U.Mutlu]

U.Mutlu wrote on 11/23/2015 06:32 AM:

Hi,
running the following example from the openssl wiki site under valgrind
gives many memory-leaks in the underlying library functions:
https://wiki.openssl.org/index.php/EVP_Symmetric_Encryption_and_Decryption

$ gcc -Wall -O2 test_encdec.c -lcrypto


Typo above: I rather had used the -ggdb switch:
$ gcc -Wall -ggdb test_encdec.c -lcrypto


$ valgrind --tool=memcheck --leak-check=full --show-leak-kinds=all
--track-origins=yes -v ./a.out &>valgrind-output.txt

Attached is the valgrind-output. It says:
   34 not-freed blocks

Are these maybe false-positives? The leak summary in the output says this:
==9895== LEAK SUMMARY:
==9895==definitely lost: 0 bytes in 0 blocks
==9895==indirectly lost: 0 bytes in 0 blocks
==9895==  possibly lost: 0 bytes in 0 blocks
==9895==still reachable: 2,632 bytes in 34 blocks
==9895== suppressed: 0 bytes in 0 blocks

OS: Debian 8 amd64, using libs from the Debian repo:
libcrypto: 5.6.1-6+deb8u1
openssl: 1.0.1k-3+deb8u1


--
U.Mutlu


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

Re: [openssl-dev] [openssl.org #4144] patch: Use '__sun' instead of 'sun' for strict ISO conforming, compiler/options

[Richard PALO via RT]

Le 22/11/15 17:26, Andy Polyakov via RT a écrit :
> 
> If you want distinguish Solaris, yes. But if you want to distinguish
> specifically SunOS 4, 'sun' is guaranteed to do the job. Because
> compiler that targets SunOS 4 *has to* have it. Either way, we seem to
> agree that *replacing* sun with __sun is not right thing to do in SunOS
> 4 context. One can argue for sun || __sun, or one can argue in favour of
> reverting. My vote goes for latter, because original conditions [in
> e_os.h] do work adequately. Well, one can argue that it works
> *incidentally*, but in such situation I usually reason that released
> software has certain "mass" and one should approach it more
> pragmatically. At the very least one shouldn't consider "strict ISO
> conformity" in broadest sense, but even answer question how does it
> affect platforms in specific supported configurations reflected in
> Configure.
> 

Not really looking to argue, but I don't believe this to be entirely
true.  That is, gcc 2.95 is certainly not the only compiler available
on SunOS 4... even today SunOS can install packages from, for a perfect
example, pkgsrc which provides gcc{2..5}.

Any gcc3 or higher *always* generates '__sun'. So does clang.
Sun/Solaris Studio do so as well. Compilers for the obsolete BSD-based SunOS 
also defined __sun (according to 
http://nadeausoftware.com/articles/2012/01/c_c_tip_how_use_compiler_predefined_macros_detect_operating_system)

On the other hand, I believe openssl 1.0 was released somewhere around 2010,
ten years after (love the group:-) the 2.95 release of gcc.  So I wonder which
compiler is really used in practice?

> As for reference to 'sun' not being defined with -ansi already in 2.95.
> At the same time it also says that it's basically counterproductive,
> because [once again] system headers require it. One should also keep in
> mind that standard compliance is never perfect, especially on older
> systems, and you're driven to make trade-offs. Like the one in question.
> 
> 

Well, I can't speak for the author of the above note on the gcc site,
but to extract a recent quote from a NetBSD and pkgsrc developer: 
"Programs should be written to standards, not gcc extensions."

In the meanwhile there is -std=c99 and more recently -std=c11 that have
been published with the similar strict requirements.

Finally, I would be happy add back the check for 'sun' as well as '__sun'
if deemed necessary.

cheers,
-- 
Richard PALO


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

[openssl-dev] [openssl.org #4153] [PATCH] Fix grammar errors in s_client.c

[Quanah Gibson-Mount via RT]

This patch fixes small grammar errors in s_client.c.




--Quanah

--

Quanah Gibson-Mount
Platform Architect
Zimbra, Inc.

Zimbra ::  the leader in open source messaging and collaboration

___
openssl-bugs-mod mailing list
openssl-bugs-...@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod

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

[openssl-dev] [openssl.org #4154] [PATCH] BIO mem read optimization

[Kirill Marinushkin via RT]

2 BIO_s_mem issues solved:
- BIO mem read without reallocation - reading by parts becomes faster;
- flag added to rewind read write BIO mem on reset.

OpenSSL self-test report:

OpenSSL version:  1.1.0-dev
Last change:  State machine rewrite. The state machine code has been ...
Options:  -march=pentium -Wa,--noexecstack no-deprecated
no-ec_nistp_64_gcc_128 no-gmp no-jpake no-md2 no-rc5 no-sctp no-shared
no-ssl-trace no-store no-unit-test no-zlib no-zlib-dynamic static-engine
OS (uname):   Linux kirill-Lenovo-B570e 3.13.0-68-generic #111-Ubuntu
SMP Fri Nov 6 18:18:09 UTC 2015 i686 i686 i686 GNU/Linux
OS (config):  i686-whatever-linux2
Target (default): linux-elf
Target:   linux-elf
Compiler: Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-linux-gnu/4.8/lto-wrapper
Target: i686-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
4.8.4-2ubuntu1~14.04'
--with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.8 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libmudflap
--enable-plugin --with-system-zlib --disable-browser-plugin
--enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-i386/jre
--enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-i386
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-i386
--with-arch-directory=i386 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-targets=all --enable-multiarch --disable-werror
--with-arch-32=i686 --with-multilib-list=m32,m64,mx32 --with-tune=generic
--enable-checking=release --build=i686-linux-gnu --host=i686-linux-gnu
--target=i686-linux-gnu
Thread model: posix
gcc version 4.8.4 (Ubuntu 4.8.4-2ubuntu1~14.04)

Test passed.

-- 
Best Regards,
Kirill Marinushkin

>From dd9e8382a6dcb4423377f4846cdf429d34ad8d29 Mon Sep 17 00:00:00 2001
From: Kirill Marinushkin 
Date: Sun, 22 Nov 2015 15:04:14 +0100
Subject: [PATCH] BIO mem read without reallocation; flag added to rewind read
 write BIO mem on reset

---
 crypto/bio/bss_mem.c | 97 +++-
 doc/crypto/BIO_s_mem.pod | 13 ++-
 include/openssl/bio.h| 11 +-
 3 files changed, 84 insertions(+), 37 deletions(-)

diff --git a/crypto/bio/bss_mem.c b/crypto/bio/bss_mem.c
index 485a8bf..2fc853a 100644
--- a/crypto/bio/bss_mem.c
+++ b/crypto/bio/bss_mem.c
@@ -61,6 +61,7 @@
 #include "internal/cryptlib.h"
 #include 
 
+
 static int mem_write(BIO *h, const char *buf, int num);
 static int mem_read(BIO *h, char *buf, int size);
 static int mem_puts(BIO *h, const char *str);
@@ -69,6 +70,8 @@ static long mem_ctrl(BIO *h, int cmd, long arg1, void *arg2);
 static int mem_new(BIO *h);
 static int secmem_new(BIO *h);
 static int mem_free(BIO *data);
+static int mem_buf_free(BIO *data, int free_all);
+static int mem_buf_sync(BIO *h);
 static BIO_METHOD mem_method = {
 BIO_TYPE_MEM,
 "memory buffer",
@@ -113,6 +116,7 @@ BIO *BIO_new_mem_buf(void *buf, int len)
 {
 BIO *ret;
 BUF_MEM *b;
+BIO_BUF_MEM *bb;
 size_t sz;
 
 if (buf == NULL) {
@@ -122,10 +126,12 @@ BIO *BIO_new_mem_buf(void *buf, int len)
 sz = (len < 0) ? strlen(buf) : (size_t)len;
 if ((ret = BIO_new(BIO_s_mem())) == NULL)
 return NULL;
-b = (BUF_MEM *)ret->ptr;
+bb = (BIO_BUF_MEM *)ret->ptr;
+b = bb->buf;
 b->data = buf;
 b->length = sz;
 b->max = sz;
+memcpy(bb->readp, bb->buf, sizeof(BUF_MEM));
 ret->flags |= BIO_FLAGS_MEM_RDONLY;
 /* Since this is static data retrying wont help */
 ret->num = 0;
@@ -134,14 +140,19 @@ BIO *BIO_new_mem_buf(void *buf, int len)
 
 static int mem_init(BIO *bi, unsigned long flags)
 {
-BUF_MEM *b;
+BIO_BUF_MEM *bb;
 
-if ((b = BUF_MEM_new_ex(flags)) == NULL)
+if ((bb = (BIO_BUF_MEM*)malloc(sizeof(BIO_BUF_MEM))) == NULL)
+	return(0);
+if ((bb->buf = BUF_MEM_new_ex(flags)) == NULL)
+return(0);
+if ((bb->readp = (BUF_MEM*)malloc(sizeof(BUF_MEM))) == NULL)
 return(0);
+memcpy(bb->readp, bb->buf, sizeof(BUF_MEM));
 bi->shutdown = 1;
 bi->init = 1;
 bi->num = -1;
-bi->ptr = (char *)b;
+bi->ptr = (char *)bb;
 return(1);
 }
 
@@ -157,37 +168,60 @@ static int secmem_new(BIO *bi)
 
 static int mem_free(BIO *a)
 {
+return (mem_buf_free(a, 1));
+}
+
+static int mem_buf_free(BIO *a, int free_all)
+{
 if (a == NULL)
 return (0);
 if (a->shutdown) {
 if ((a->init) && (a->ptr != NULL)) {
 BUF_MEM *b;
-b = (BUF_MEM *)a->ptr;
-if (a->flags & 

Re: [openssl-dev] [openssl.org #4151] [PATCH] Function pop_info in crypto/mem_dbg.c returns a dangling pointer

[Salz, Rich via RT]

We have another internal cleanup in-progress that will fix this in a different 
way.



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

Re: [openssl-dev] [openssl.org #4144] patch: Use '__sun' instead of 'sun' for strict ISO conforming, compiler/options

[Andy Polyakov via RT]

>> In other words I argue in favour of reverting suggested change in
>> 1.0.1/2. Because I can't find evidence that __sun is defined on said
>> platform.
>>
>>
>>
>>
> FWIW, the generally accepted and documented platform tests include:
>>  #ifdef __sun
>>  /* this is SunOS */
>>  #endif

I understand and appreciate this. But the point is that original
conditions are supposed to work on platform that predates the moment the
referred way became generally accepted. Once again, it either has to
work with old compiler, or support for old compiler has to be disclaimed
and code removed. Consider this. Do all SunOS 4 compilers define __sun?
No. Do all of them define sun? Yes, they have to, because system headers
depend on it. In worst case it probably should be sun || __sun, but sun
alone is sufficient. For SunOS 4 that is.



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

Re: [openssl-dev] [openssl.org #4144] patch: Use '__sun' instead of 'sun' for strict ISO conforming, compiler/options

[Andy Polyakov via RT]

> FWIW, the generally accepted and documented platform tests include:
>>  #ifdef __sun
>>  /* this is SunOS */
>>  #endif

By the way, was it *actually* tested on SunOS 4? And if so, when and
with which compiler? Is it possible that it simply was harmonized at
some point with "we have double-underscore everywhere, don't we"
rationale, without actual test on SunOS 4? And this way became kind of
an urban legend? Well, I'm not actually asserting that I myself have
possibility to test something on SunOS 4 now, but I have copy of system
headers and see what did gcc 2.95 define...


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

Re: [openssl-dev] [openssl.org #4144] patch: Use '__sun' instead of 'sun' for strict ISO conforming, compiler/options

[Richard PALO via RT]

Le 22/11/15 15:42, Andy Polyakov via RT a écrit :
>> FWIW, the generally accepted and documented platform tests include:
>>>  #ifdef __sun
>>>  /* this is SunOS */
>>>  #endif
> 
> By the way, was it *actually* tested on SunOS 4? And if so, when and
> with which compiler? Is it possible that it simply was harmonized at
> some point with "we have double-underscore everywhere, don't we"
> rationale, without actual test on SunOS 4? And this way became kind of
> an urban legend? Well, I'm not actually asserting that I myself have
> possibility to test something on SunOS 4 now, but I have copy of system
> headers and see what did gcc 2.95 define...
> 
> 
> 
> 
Well, I admit I only checked back to gcc3... I did notice the following though:
https://sourceforge.net/p/predef/wiki/OperatingSystems/
> #if defined(sun) || defined(__sun)
> # if defined(__SVR4) || defined(__svr4__)
> /* Solaris */
> # else
> /* SunOS */
> # endif
> #endif

that is, if supporting that far back is indeed a goal, then *both* should be 
checked. Naturally that should be acceptable to most anybody concerned.

cheers

-- 
Richard PALO


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

Re: [openssl-dev] [openssl.org #4144] patch: Use '__sun' instead of 'sun' for strict ISO conforming, compiler/options

[Richard PALO via RT]

Le 22/11/15 16:29, Richard PALO a écrit :
> Le 22/11/15 15:42, Andy Polyakov via RT a écrit :
>>> FWIW, the generally accepted and documented platform tests include:
  #ifdef __sun
  /* this is SunOS */
  #endif
>>
>> By the way, was it *actually* tested on SunOS 4? And if so, when and
>> with which compiler? Is it possible that it simply was harmonized at
>> some point with "we have double-underscore everywhere, don't we"
>> rationale, without actual test on SunOS 4? And this way became kind of
>> an urban legend? Well, I'm not actually asserting that I myself have
>> possibility to test something on SunOS 4 now, but I have copy of system
>> headers and see what did gcc 2.95 define...
>>
>>
>>
>>
> Well, I admit I only checked back to gcc3... I did notice the following 
> though:
> https://sourceforge.net/p/predef/wiki/OperatingSystems/
>> #if defined(sun) || defined(__sun)
>> # if defined(__SVR4) || defined(__svr4__)
>> /* Solaris */
>> # else
>> /* SunOS */
>> # endif
>> #endif
> 
> that is, if supporting that far back is indeed a goal, then *both* should be 
> checked. Naturally that should be acceptable to most anybody concerned.
> 
> cheers
> 


BTW from what I can see, 'sun' being not defined with '-ansi' was already 
documented in https://gcc.gnu.org/onlinedocs/gcc-2.95.3/cpp_1.html


-- 
Richard PALO


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

[openssl-dev] [openssl.org #4151] [PATCH] Function pop_info in crypto/mem_dbg.c returns a dangling pointer

[Pascal Cuoq via RT]

In crypto/mem_dbg.c, the type of static function pop_info() is to return an 
APP_INFO*.
This pointer can be a dangling pointer, as can be seen in the following link as 
long as one assumes that line 382 is reachable (it is).

https://github.com/openssl/openssl/blob/90945fa31a42dcf3beb90540c618e4d627c595ea/crypto/mem_dbg.c#L382-L386

Returning a dangling pointer from a function is not terribly good style. Using 
dangling pointers for anything is technically undefined behavior, so there is 
nothing in theory that a caller can do with the function's result that will not 
be illegal when a dangling pointer is returned.

(It is well-known that dereferencing dangling pointers is undefined behavior, 
but examples at http://blog.regehr.org/archives/767#comment-4717 and at 
http://trust-in-soft.com/dangling-pointer-indeterminate/ show that the behavior 
of a program the *only* fault of which is to compare a dangling pointer to 
something else can be surprising too).

The function pop_info() being static, no-one may use it outside mem_dbg.c and 
the callers inside mem_dbg.c do not dereference the returned pointer. They do 
use it in a comparison though, which should ideally be avoided because of the 
examples above.

The attached patch does three small things:

- change the type of the function to return an int: 1 if the pointer ret was 
non-null before being possibly freed, 0 otherwise, and adjust the two call 
sites correspondingly;
- add a one-line comment describing the behavior of the function;
- rename the local variable ret, the name of which no longer makes sense, into 
"current".

None of these three things should change the behavior in practice of OpenSSL. 
As compiled with current C compilers, the tests "pop_info() != NULL" evaluated 
to 1 when a dangling pointer was returned. These tests were replaced with 
"pop_info()" which now evaluates to 1 under the circumstances in which a 
dangling pointer was returned.





pop_info.patch
Description: Binary data
___
openssl-bugs-mod mailing list
openssl-bugs-...@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4144] patch: Use '__sun' instead of 'sun' for strict ISO conforming, compiler/options

[Andy Polyakov via RT]

>> I'd like to propose the attached patch to 1.0.2d which avoids problems
>> with strict ISO conforming compiler/options, which do not define 'sun' only
>> '__sun' as usual... such as gcc/clang -std=c99
>>
>> This affects the build itself, but also any user of openssl/opensslconf.h
> 
> I've commited only the part that applied to the master branch, but
> fixed that in all the branches.  Please let me know if you need
> other changes in the stable branches.

There is partial contradiction here. It's argued in terms of
contemporary compilers, while the code fragments in question, mostly
those in e_os.h target specific *legacy* platform which is unlikely to
have contemporary compiler. So that attempt to harmonize with recent
compiler one breaks things for old compiler. One can argue that it's
probably broken anyway, but it doesn't really make harmonization more
right, does it? If platform is broken, then support should be disclaimed
and correct approach would be to *remove* code. If support is not
disclaimed then correct approach would be to look at target system, not
what gcc/clang do on Linux. BTW, support for platform in question *is*
disclaimed in master, so that in master code should be removed. Even
that sys/filio.h thing, because default alternative works fine on Solaris.

Side note about "#if define (sun) /* Newer Sparc's */" "sun" denotes OS
vendor, not processor. So that it would be more appropriate to switch to
sparc || __sparc__.


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

Re: [openssl-dev] [openssl.org #4144] patch: Use '__sun' instead of 'sun' for strict ISO conforming, compiler/options

[Kurt Roeckx via RT]

On Tue, Nov 17, 2015 at 05:43:45PM +, Richard PALO via RT wrote:
> I'd like to propose the attached patch to 1.0.2d which avoids problems
> with strict ISO conforming compiler/options, which do not define 'sun' only
> '__sun' as usual... such as gcc/clang -std=c99
> 
> This affects the build itself, but also any user of openssl/opensslconf.h

I've commited only the part that applied to the master branch, but
fixed that in all the branches.  Please let me know if you need
other changes in the stable branches.


Kurt


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

Re: [openssl-dev] [openssl.org #4144] patch: Use '__sun' instead of 'sun' for strict ISO conforming, compiler/options

[Andy Polyakov via RT]

>>> I'd like to propose the attached patch to 1.0.2d which avoids problems
>>> with strict ISO conforming compiler/options, which do not define 'sun' only
>>> '__sun' as usual... such as gcc/clang -std=c99
>>>
>>> This affects the build itself, but also any user of openssl/opensslconf.h
>>
>> I've commited only the part that applied to the master branch, but
>> fixed that in all the branches.  Please let me know if you need
>> other changes in the stable branches.
> 
> ... If support [for SunOS 4] is not
> disclaimed then correct approach would be to look at target system, not
> what gcc/clang do on Linux.

In other words I argue in favour of reverting suggested change in
1.0.1/2. Because I can't find evidence that __sun is defined on said
platform.


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

[openssl-dev] Building Open

[Inge Henriksen]

Hi.


I believe that I've found some issues while to build OpenSSL v1.0.2b for 64-bit 
Intel compatible CPUs on Windows 10 using Visual Studio 2015.


There is a bug in the ms\do_win64a.bat OpenSSL batch file that causes some of 
the libraries to be built as 32-bit, to fix this you can do the following; open 
and edit ms\do_win64a.bat in notepad by typing the following in the command 
shell:

notepad ms\do_win64a.bat

Now you must make sure that the ms\do_win64a.bat contents matches the following 
and overwrite the file after you have made it so:



perl util\mkfiles.pl >MINFO
cmd /c "nasm -f win64 -v" >NUL 2>&1
if %errorlevel% neq 0 goto ml64

perl ms\uplink-x86_64.pl nasm > ms\uptable.asm
nasm -f win64 -o ms\uptable.obj ms\uptable.asm
goto proceed

:ml64
perl ms\uplink-x86_64.pl masm > ms\uptable.asm
ml64 -c -Foms\uptable.obj ms\uptable.asm

:proceed
perl util\mk1mf.pl VC-WIN64A >ms\nt.mak
perl util\mk1mf.pl dll VC-WIN64A >ms\ntdll.mak

perl util\mkdef.pl 64 libeay > ms\libeay32.def
perl util\mkdef.pl 64 ssleay > ms\ssleay32.def



With that everything builds and unit tests ran, but the output binaries are 
still named "32" even though they are 64-bit which is confusing.


Read more in my blog here:

https://ingehenriksen.wordpress.com/2015/11/22/building-openssl-1-0-2d-64-bit-on-windows-with-visual-studio-2015/


Thank you.


Kind regards,

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

Re: [openssl-dev] [openssl.org #4144] patch: Use '__sun' instead of 'sun' for strict ISO conforming, compiler/options

[Andy Polyakov via RT]

>>> FWIW, the generally accepted and documented platform tests include:
  #ifdef __sun
  /* this is SunOS */
  #endif
>>
>> By the way, was it *actually* tested on SunOS 4? And if so, when and
>> with which compiler? Is it possible that it simply was harmonized at
>> some point with "we have double-underscore everywhere, don't we"
>> rationale, without actual test on SunOS 4? And this way became kind of
>> an urban legend? Well, I'm not actually asserting that I myself have
>> possibility to test something on SunOS 4 now, but I have copy of system
>> headers and see what did gcc 2.95 define...
>>
>>
>>
>>
> Well, I admit I only checked back to gcc3... I did notice the following 
> though:
> https://sourceforge.net/p/predef/wiki/OperatingSystems/
>> #if defined(sun) || defined(__sun)
>> # if defined(__SVR4) || defined(__svr4__)
>> /* Solaris */
>> # else
>> /* SunOS */
>> # endif
>> #endif
> 
> that is, if supporting that far back is indeed a goal,

Irregardless whether or not goal is formulated like *this*, it's
definitely can be formulated at least as "keep even legacy platforms in
mind". I mean it's more about discipline.

> then *both* should be checked. Naturally that should be acceptable to most 
> anybody concerned.

If you want distinguish Solaris, yes. But if you want to distinguish
specifically SunOS 4, 'sun' is guaranteed to do the job. Because
compiler that targets SunOS 4 *has to* have it. Either way, we seem to
agree that *replacing* sun with __sun is not right thing to do in SunOS
4 context. One can argue for sun || __sun, or one can argue in favour of
reverting. My vote goes for latter, because original conditions [in
e_os.h] do work adequately. Well, one can argue that it works
*incidentally*, but in such situation I usually reason that released
software has certain "mass" and one should approach it more
pragmatically. At the very least one shouldn't consider "strict ISO
conformity" in broadest sense, but even answer question how does it
affect platforms in specific supported configurations reflected in
Configure.

As for reference to 'sun' not being defined with -ansi already in 2.95.
At the same time it also says that it's basically counterproductive,
because [once again] system headers require it. One should also keep in
mind that standard compliance is never perfect, especially on older
systems, and you're driven to make trade-offs. Like the one in question.


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

[openssl-dev] [openssl.org #4152] [PATCH] SRP code clean-up s_client and s_server

[Tianjie Mao via RT]

Hello,

SRP is a secure password authentication / key exchange protocol. When
the original SRP patches for OpenSSL were created by the EdelKey
project back in 2000s, the highest version of TLS standard remained
1.0. Some code, however, if left unchanged, would by default restrict
communications to TLSv1 while refusing to negotiate later versions of
security. It would also interfere with command line switches such as
-tls1_1 and -tls1_2. These lines were from old patches and need to be
cleaned up.

The following diff was made against OpenSSL_1_0_2-stable.

--- apps/s_server.c.orig 2015-11-23 03:36:01.445020272 +0800
+++ apps/s_server.c  2015-11-23 03:41:29.579617191 +0800
@@ -1424,12 +1424,10 @@
 if (--argc < 1)
 goto bad;
 srp_verifier_file = *(++argv);
-meth = TLSv1_server_method();
 } else if (strcmp(*argv, "-srpuserseed") == 0) {
 if (--argc < 1)
 goto bad;
 srpuserseed = *(++argv);
-meth = TLSv1_server_method();
 }
 #endif
 else if (strcmp(*argv, "-rev") == 0) {
--- apps/s_client.c.orig 2015-11-23 03:36:01.441020388 +0800
+++ apps/s_client.c  2015-11-23 04:01:58.272199415 +0800
@@ -922,25 +922,20 @@
 if (--argc < 1)
 goto bad;
 srp_arg.srplogin = *(++argv);
-meth = TLSv1_client_method();
 } else if (strcmp(*argv, "-srppass") == 0) {
 if (--argc < 1)
 goto bad;
 srppass = *(++argv);
-meth = TLSv1_client_method();
 } else if (strcmp(*argv, "-srp_strength") == 0) {
 if (--argc < 1)
 goto bad;
 srp_arg.strength = atoi(*(++argv));
 BIO_printf(bio_err, "SRP minimal length for N is %d\n",
srp_arg.strength);
-meth = TLSv1_client_method();
 } else if (strcmp(*argv, "-srp_lateuser") == 0) {
 srp_lateuser = 1;
-meth = TLSv1_client_method();
 } else if (strcmp(*argv, "-srp_moregroups") == 0) {
 srp_arg.amp = 1;
-meth = TLSv1_client_method();
 }
 #endif
 #ifndef OPENSSL_NO_SSL2
@@ -1101,7 +1096,6 @@
 if (--argc < 1)
 goto bad;
 servername = *(++argv);
-/* meth=TLSv1_client_method(); */
 }
 #endif
 #ifndef OPENSSL_NO_JPAKE

___
openssl-bugs-mod mailing list
openssl-bugs-...@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod

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

Re: [openssl-dev] Building Open

[Joey Yandle]

I believe that I've found some issues while to build OpenSSL v1.0.2b for
64-bit Intel compatible CPUs on Windows 10 using Visual Studio 2015.


It appears that you skipped a step that was listed in INSTALL.W64, 
specifically


  perl Configure VC-WIN64A

1.0.2* builds normally for me on amd64 if that step is not skipped.

You are correct that 64-bit binaries are improperly labeled with '32'. 
I do plan on fixing that at some point, though in the meantime it makes 
my life easier (my scripts can always assume the same library name).


cheers,

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