Supply Darwin binaries + install documentation

[drwetter]

It would be awesome if somebody could contribute OS X binaries from @PeterMosmans OpenSSL fork and also document the installation (sorry, I am a Mac n00b)

[drwetter]

Anybody?

[jpluimers]

What would be needed to do this? I've a Mac and would be willing to setup a build environment, but I've not done much *nix build stuff for like 20+ years or so.

[drwetter]

I can't tell what's required on Darwin, maybe others do

[drwetter]

See commit 370bcc3. Thx @jvehent.

I am leaving it open as it's 10.2b from @PeterMosmans .

[jpluimers]

It would result in both an i386 and x64 binary. Is that OK with you?
Proposed build script is at https://gist.github.com/jpluimers/f4de3937630b87753133

[drwetter]

Am 18. Juli 2015 19:19:37 MESZ, schrieb Jeroen Wiert Pluimers [email protected]:

It would result in both an i386 and x64 binary. Is that OK with you?
Proposed build script is at
https://gist.github.com/jpluimers/f4de3937630b87753133

---

Reply to this email directly or view it on GitHub:
#127 (comment)

Sure, much appreciated. Go ahead pls

[PeterMosmans]

@jpluimers , I would add more build flags to make sure that zlib, ssl2, ssl3 and more ciphers are added, eg for the 64 bit version:

no-shared zlib enable-ec_nistp_64_gcc_128 enable-idea enable-md2 enable-rc5 enable-rfc3779 enable-ssl2 enable-ssl3 enable-gost experimental-jpake enable-static-engine

Please send pull requests if you make any Apple-specific changes to the openssl repository, which would benefit all users.

Thanks,

Peter

[drwetter]

Am 19. Juli 2015 10:56:36 MESZ, schrieb Peter Mosmans [email protected]:

@jpluimers , I would add more build flags to make sure that zlib, ssl2,
ssl3 and more ciphers are added, eg for the 64 bit version:

no-shared zlib enable-ec_nistp_64_gcc_128 enable-idea enable-md2
enable-rc5 enable-rfc3779 enable-ssl2 enable-ssl3 enable-gost
experimental-jpake enable-static-engine

Please send pull requests if you make any Apple-specific changes to the
openssl repository, which would benefit all users.

Thanks,

Peter

---

Reply to this email directly or view it on GitHub:
#127 (comment)

See also https://github.com/drwetter/testssl.sh/blob/master/openssl-bins/openssl-1.0.2-chacha.pm/Readme.md. and https://github.com/drwetter/testssl.sh/blob/master/openssl-bins/make-openssl.sh.

-DOPENSSL_BUILD_DATE is useful informational info.

Cheers, Dirk

[jpluimers]

Thanks guys. I'll try to get as close to the openssl ciphers -V output of the binary that is currently included.

[jpluimers]

@PeterMosmans

I'm stuck. Your parameters make ./Configure ask me to do a make depend, but that fails:

RetinaMBPro1TB:openssl jeroenp$ make depend
making depend in crypto...
../util/domd: line 30: makedepend: command not found
mv: Makefile.new: No such file or directory
make[1]: *** [local_depend] Error 127
make: *** [depend] Error 1

[PeterMosmans]

Have you issued the following commands from the 1.0.2-chacha branch ?

make dclean; make clean
./Configure darwin64-x86_64-cc no-shared enable-static-engine enable-ec_nistp_64_gcc_128 enable-gost enable-idea enable-md2 enable-rc5 enable-rfc3779 enable-ssl-trace enable-ssl2 enable-ssl3 enable-zlib experimental-jpake no-zlib-dynamic && make depend && make && make report

[jpluimers]

Yup, I am:

RetinaMBPro1TB:openssl jeroenp$ git branch
* 1.0.2-chacha

Your steps give me this:

...
Since you've disabled or enabled at least one algorithm, you need to do
the following before building:

    make depend

Configured for darwin64-x86_64-cc.
making depend in crypto...
../util/domd: line 30: makedepend: command not found
mv: Makefile.new: No such file or directory
make[1]: *** [local_depend] Error 127
make: *** [depend] Error 1

I adapted my script to include your steps: https://gist.github.com/jpluimers/f4de3937630b87753133

pushd /tmp
git clone https://github.com/PeterMosmans/openssl
cd openssl

make dclean
make clean 
./Configure darwin64-x86_64-cc no-shared enable-static-engine enable-ec_nistp_64_gcc_128 enable-gost enable-idea enable-md2 enable-rc5 enable-rfc3779 enable-ss
make depend
make
make report
popd

The full output is at https://gist.github.com/jpluimers/47b2fd6131d675002009

[PeterMosmans]

Hmm, it looks like there's something wrong with the Makefile..
Building the binary should be pretty straightforward, and Configure should create a correct makefile. Could you upload your ./Makefile ?
and could you try to run

make dclean
make clean

after running ./Configure ?

Does your /tmp partition has different permissions than your regular partitions (eg. /home ) ?
Do you get the same results with the vanilla repo (https://github.com/openssl/openssl ) ?
Thanks!

[drwetter]

in util/domd: line 30 $MAKEDEPEND is called. Not that I understood the make files good enough but if Peter's make dclean didn't do I would just try

MAKEDEPEND="make depend" ./Configure

[drwetter]

@PeterMosmans : How many ciphers do you have with your configure option?

I did a comparison of your suggestion with how I built (https://github.com/drwetter/testssl.sh/tree/master/openssl-bins/openssl-1.0.2-chacha.pm) and I supply in addition

enable-rc2 enable-cms enable-mdc2 enable-ec enable-ec2m enable-ecdh enable-ecdsa enable-seed enable-camellia -DOPENSSL_USE_BUILD_DATE

Probably some are redundant because it's the default any way like enable-ecdh enable-ecdsa . But how about rc2 or camelia?

I also find -DOPENSSL_USE_BUILD_DATE quite useful as otherwise openssl version -a returns: built on: reproducible build, date unspecified. The built on is parsed by testssl.sh as it helps me to tell which binary was used.

OTOH I am missing enable-ssl3 and enable-ssl-trace. Not that the first mattered yet but I guess it will soon.

Thx, Dirk

[PeterMosmans]

From the Configure file:

 "ec_nistp_64_gcc_128" => "default",
         "gmp"        => "default",
         "jpake"          => "experimental",
         "libunbound"     => "experimental",
         "md2"            => "default",
         "rc5"            => "default",
         "rfc3779"    => "default",
         "sctp"       => "default",
         "shared"         => "default",
         "ssl-trace"      => "default",
         "store"      => "experimental",
         "unit-test"      => "default",
         "zlib"           => "default",
         "zlib-dynamic"   => "default"

As in: these are enabled by default. It's always better to explicitly enable them, as you never know if the defaults will change..
I propose to include a generic build script in the 1.0.2-chacha fork, to simplify building the openssl binary with all ciphers enabled, @drwetter ?

[drwetter]

Am 07/20/2015 um 12:29 PM schrieb Peter Mosmans:

From the Configure file:

|"ec_nistp_64_gcc_128" => "default", "gmp" => "default", "jpake" => "experimental", "libunbound" => "experimental", "md2" => "default", "rc5" => "default", "rfc3779" => "default", "sctp" => "default", "shared" => "default", "ssl-trace" => "default", "store" => "experimental", "unit-test" => "default", "zlib" => "default", "zlib-dynamic" => "default" |

As in: these are enabled by default.

that seems to be only partly correct. I missed completely the new option ssl-trace. (thx
for the hint btw!: that is a really good thing). My Configure lists that, my resulting Makefile
OTOH listed no-ssl-trace.

It's always better to explicitly enable them, as you never know if the defaults will change..

definitely!

I propose to include a generic build script in the 1.0.2-chacha fork, to simplify building the openssl binary with all ciphers enabled, @drwetter https://github.com/drwetter ?

sure. Feel from to help yourself from https://github.com/drwetter/testssl.sh/blob/master/openssl-bins/make-openssl.sh .

Outcome is 179 ciphers plus the four GOST ciphers via engine. MIT Kerberos gives 14 ciphers on top of
it.

Cheers, Dirk

[jpluimers]

Neither

MAKEDEPEND="make depend" ./Configure

nor running these after ./Configure solved the issue:

make dclean
make clean
make depend

making depend in crypto...
../util/domd: line 30: makedepend: command not found
mv: Makefile.new: No such file or directory
make[1]: *** [local_depend] Error 127
make: *** [depend] Error 1

The permissions for /tmp/openssl are these:

drwxr-xr-x  61 jeroenp         wheel     2074 Jul 21 07:00 openssl

It seems that makedepend is not available on OS X as of version 10.7.4: osx - makedepend missing? - Stack Overflow

I'm not yet good enough at building Mac OS X or Linux stuff, so I need some help (especially since the Stack Overflow thread mentions bash aliases not working with makefiles) on how to get that working in makefiles.

I quit writing makefiles 25 years ago in favour of batch files and later PowerShell as I could not get my head around makefiles. The current openssl makefiles are too intimidating and non-DRY to just dig into it:

RetinaMBPro1TB:openssl jeroenp$ grep -nr makedepend .
./crypto/Makefile:12:MAKEDEPPROG=   makedepend
./crypto/Makefile.save:12:MAKEDEPPROG=  makedepend
./crypto/srp/Makefile:10:MAKEDEPPROG=   makedepend
./crypto/ts/Makefile:13:MAKEDEPPROG=    makedepend
./demos/tunala/Makefile:36:# Extra dependencies, should really use makedepend
./Makefile:75:MAKEDEPPROG=makedepend
./Makefile.org:73:MAKEDEPPROG=makedepend
./util/domd:2:# Do a makedepend, only leave out the standard headers
./util/domd:12:if [ "$MAKEDEPEND" = "" ]; then MAKEDEPEND=makedepend; fi

[PeterMosmans]

I'd love to help out, as I think it will be beneficial for everybody to have OS X binaries containing full cipher support. Especially now that it proves less-than straightforward.After taking another look at your build output it looks as if the binary is build successfully after all ? Even the ChaCha20 and Poly1305 tests succeed ?
Could you post the whole testlog output (that's created with make test) ?

Thanks for all your efforts,

Peter

(I'm trying to bring a OSX + openssl specialist into this discussion...)

[jpluimers]

@PeterMosmans what time zone are you in? If you are anywhere near to around UTC+2, as I think it will be faster doing a screen sharing session so I can show you a couple of things.

Adding make dclean and make clean after ./Configure ... will lead to make fail: https://gist.github.com/jpluimers/651b97e5ab4429a9814a.

I'll try to get it building, testing and reporting again, then let you know the results. Hopefully with as many ciphers configured as you mentioned in the thread above.

[DomT4]

You need a tool called makedepend, which you can grab here: http://xorg.freedesktop.org/releases/individual/util/makedepend-1.0.5.tar.bz2

You need to install that and stick it in the $PATH somewhere. It hasn't been default on OS X for a few years now. You may need to install xproto and xorg-macros for makedepend to install. If you do:

http://xorg.freedesktop.org/releases/individual/proto/xproto-7.0.25.tar.bz2
http://xorg.freedesktop.org/releases/individual/util/util-macros-1.18.0.tar.bz2

If you use Homebrew, just brew install makedepend.

The script provided here further up doesn't seem to fully work though:

OpenSSL self-test report:

OpenSSL version:  1.0.2-chacha
Last change:      Alternate chains certificate forgery...
Options:          enable-static-engine enable-ec_nistp_64_gcc_128 enable-gost enable-idea enable-md2 enable-rc5 enable-rfc3779 enable-ssl-trace enable-ssl2 enable-ssl3 enable-zlib experimental-jpake no-gmp no-krb5 no-libunbound no-sctp no-shared no-store no-unit-test no-zlib-dynamic static-engine
OS (uname):       Darwin Dominyks-MacBook-Pro.local 14.5.0 Darwin Kernel Version 14.5.0: Thu Jul  9 22:56:16 PDT 2015; root:xnu-2782.40.6~1/RELEASE_X86_64 x86_64
OS (config):      i686-apple-darwinDarwin Kernel Version 14.5.0: Thu Jul 9 22:56:16 PDT 2015; root:xnu-2782.40.6~1/RELEASE_X86_64
Target (default): darwin-i386-cc
Target:           darwin64-x86_64-cc
Compiler:         Apple LLVM version 6.1.0 (clang-602.0.53) (based on LLVM 3.6.0svn)
Target: x86_64-apple-darwin14.5.0
Thread model: posix

#include uses headers from different OpenSSL version!

Please ask your system administrator/vendor for more information.
[Problems with your operating system setup should not be reported
to the OpenSSL project.]

I suspect it's picking up on the headers in /usr/include and getting itself confused.

[DomT4]

This may be useful as a reference. I've had a working Homebrew script for Peter's OpenSSL for a while.

This seems to work:

perl ./Configure no-shared enable-static-engine enable-gost enable-idea enable-md2 enable-rc5 enable-rfc3779 enable-ssl-trace enable-ssl2 enable-ssl3 enable-zlib experimental-jpake no-zlib-dynamic darwin64-x86_64-cc enable-ec_nistp_64_gcc_128
make depend
make
make test

OpenSSL self-test report:

OpenSSL version:  1.0.2-chacha
Last change:      Alternate chains certificate forgery...
Options:          enable-static-engine enable-ec_nistp_64_gcc_128 enable-gost enable-idea enable-md2 enable-rc5 enable-rfc3779 enable-ssl-trace enable-ssl2 enable-ssl3 enable-zlib experimental-jpake enable-ec_nistp_64_gcc_128 no-gmp no-krb5 no-libunbound no-sctp no-shared no-store no-unit-test no-zlib-dynamic static-engine
OS (uname):       Darwin Dominyks-MacBook-Pro.local 14.5.0 Darwin Kernel Version 14.5.0: Thu Jul  9 22:56:16 PDT 2015; root:xnu-2782.40.6~1/RELEASE_X86_64 x86_64
OS (config):      i686-apple-darwinDarwin Kernel Version 14.5.0: Thu Jul 9 22:56:16 PDT 2015; root:xnu-2782.40.6~1/RELEASE_X86_64
Target (default): darwin-i386-cc
Target:           darwin64-x86_64-cc
Compiler:         Apple LLVM version 6.1.0 (clang-602.0.53) (based on LLVM 3.6.0svn)
Target: x86_64-apple-darwin14.5.0
Thread model: posix

Test passed.

I'd urge not including SSLv2 though. SSLv2 is essentially the safety equivalent of yelling your private details out of an open window these days, and SSLv3 isn't much better. The standard OpenSSL shipped by Apple supports SSLv2, but none of Debian or Ubuntu or Homebrew do.

[PeterMosmans]

@DomT4 (the OSX + openssl specialist 😄 ) : A big thanks for chiming in. (In)secure protocols like sslv2 and ciphers are actually encouraged, as the main reason for this fork is testing all these ciphers.

Thanks once again!

Peter

[drwetter]

Am 07/21/2015 um 09:33 PM schrieb Dominyk Tiller:

This may be useful as a reference
https://github.com/DomT4/homebrew-crypto/blob/master/Formula/mosmans-openssl.rb. I've had a
working Homebrew script for Peter's OpenSSL for a while.

This seems to work:

|perl ./Configure no-shared enable-static-engine enable-ec_nistp_64_gcc_128 enable-gost
enable-idea enable-md2 enable-rc5 enable-rfc3779 enable-ssl-trace enable-ssl2 enable-ssl3
enable-zlib experimental-jpake no-zlib-dynamic darwin64-x86_64-cc enable-ec_nistp_64_gcc_128
make depend make make test |

I'd urge not including SSLv2 though. SSLv2 is essentially the safety equivalent of yelling your
private details out of an open window these days, and SSLv3 isn't much better. The standard
OpenSSL shipped by Apple supports SSLv2, but none of Debian or Ubuntu or Homebrew do.

from
https://github.com/drwetter/testssl.sh/blob/master/openssl-bins/openssl-1.0.2-chacha.pm/Readme.md

"The precompiled binaries provided here have extended support for everything which is normally
not configured to be compiled (40+56 Bit, export/ANON ciphers, weak DH ciphers, SSLv2 etc.) --
all the dirty features needed for testing. OTOH the binaries also come with extended support
for new / advanced cipher suites and/or features which are not (yet?) in the official branch.

[..]

Never use these binaries for anything other than testing"

Cheers, Dirk

[DomT4]

(the OSX + openssl specialist 😄 ) : A big thanks for chiming in.

Specialist is probably a little kind, a mix of Homebrew maintaining and screwing around on OS X mostly 😉. Happy to help where I can though.

(In)secure protocols like sslv2 and ciphers are actually encouraged, as the main reason for this fork is testing all these ciphers.

Fair enough!

[jpluimers]

@DomT4 I'd rather invest time in getting rid of the makedepend dependency on OS X and only require XCode to be present. My motivation is that openssl should build well on an OS X system that is as much stock as possible.

As gcc has been mentioned as an alternative since more than a decade (see http://cnds.eecs.jacobs-university.de/courses/eecslab1-2003/solution2.pdf) I want to invest time and effort into using that as an alternative on OS X for openssl.

Sometimes you just have to do things "the right way". To me, striking a balance between "stock", OSS project requirements, availability of tooling in the OSS world and making stuff really cross platform is the right way.

If that means I really have to dig into makefiles, I'm going to do that (despite what I mentioned above about my aversion against them), but I can use some help and it will take some time.

[PeterMosmans]

@jpluimers : Apparently changing the link MAKEDEPPROG in the generated Makefile in the root (after running Configure) to the following will work:

MAKEDEPPROG=$(CC) -M 

After which you should be able to run

make depend

and the rest of the build steps.

See http://openssl.6102.n7.nabble.com/OpenSSL-1-0-1c-Mac-OS-X-no-XXX-and-missing-make-depend-td42920.html for more information.

[jpluimers]

OK. Will try that. Probably during the weekend. It's a bit really busy as one of our team members is unavailable, so we need to redistribute work.

[jpluimers]

@PeterMosmans I did some Perl learning, instrumentation and came up with the following diff to create a correct Makefile when makedepend does not exist: https://gist.github.com/jpluimers/878c04d189d6274d7bb1

Now make depend fails: https://gist.github.com/jpluimers/fc96fcfd4c0b2d2bf1ef

Small extract of failure:

RetinaMBPro1TB:openssl jeroenp$ make depend
making depend in crypto...
clang: error: no such file or directory: '-DZLIB'
...
clang: error: no such file or directory: '--'
mv: Makefile.new: No such file or directory
make[1]: *** [local_depend] Error 1
make: *** [depend] Error 1

I'm going to dig that, but could use some help. If you're on Skype (search for me) or Hangouts (via https://plus.google.com/+JeroenPluimers), please drop me a there.

Oh, I started a blog post because of the modifications too. A preliminary version with comment possibilities is here: http://wiert.me/?p=28747&shareadraft=55b3de750384d

[jpluimers]

@PeterMosmans fixed that too. See my updated blog. Summary: util/domd only stripped stuff clang would not recognized if that was executed as gcc, not as cc.

This now works after a .Configure:

make depend
make
make test

What is the .Configure set of parameters to make the cypher list fully complete?

When building with that complete list succeeds, then I can run the build tomorrow, send you a pull request for the openssl change, and @drwetter a pull request or the x64 and x86 binary.

Edit: cipher list and make test results: https://gist.github.com/jpluimers/5382b4c6d4923415b48f

[PeterMosmans]

Sounds like you have a busy weekend @jpluimers :) You could try these settings for the maximum number of ciphers:

 no-shared enable-static-engine zlib enable-camellia enable-cms enable-ec enable-ec2m enable-ecdh enable-ecdsa enable-ec_nistp_64_gcc_128 enable-gost enable-idea enable-md2 enable-mdc2 enable-rc2 enable-rc5 enable-rfc3779 enable-seed enable-ssl-trace enable-ssl2 enable-ssl3  experimental-jpake no-zlib-dynamic

Note that you need the zlib-devel package (zlib headers) to compile.
Good luck and thanks for all your work so far!

Peter

[jpluimers]

It looks like I broke the tests for both x86 and x64. Anyone knows that the below means?

testing SSLv3 cipher list order: ....failed 300ff03 vs. 300cc13

[drwetter]

yes, was discussed elsewhere @PeterMosmans. and me, see PeterMosmans/openssl#26 .

0xff03 is one of the two additional gost ciphers which are compiled in via " -DTEMP_GOST_TLS".
0xcc13 is ECDHE-RSA-CHACHA20-POLY1305.

The test exec ./ssltest -test_cipherlist`` is somewhat broken. I have tested the binaries ok.
If you care about this error you could disable that test and look whether the rest of the tests ok.

[jpluimers]

I care, so I adapted the SSL cipher list tests in ssl/ssltest.c so they continue and produce good descriptions (they listed testing TLSv1 cipher list order tree times, two of which are now TLSv1.1 and TLSv1.2.
The tests now lists these for both x86 and x64:

testing SSLv2 cipher list order: .........ok
testing SSLv3 cipher list order: ....failed 300ff03 vs. 300cc13
..............................................................................................................................................................................ok
testing TLSv1 cipher list order: ....failed 300ff03 vs. 300cc13
..............................................................................................................................................................................ok
testing TLSv1.1 cipher list order: ....failed 300ff03 vs. 300cc13
.............................................................................................................................................................................. ok
testing TLSv1.2 cipher list order: ....failed 300ff03 vs. 300cc13
.............................................................................................................................................................................. ok

Now it gets much further, but fails on this:

x86 failure:

Testing DHE-RSA-CHACHA20-POLY1305
Available compression methods:
  1: zlib compression
ERROR in SERVER
2692846060:error:1408A0C1:SSL routines:ssl3_get_client_hello:no shared cipher:s3_srvr.c:1420:
TLSv1.2, cipher (NONE) (NONE)
1 handshakes of 256 bytes done
Failed DHE-RSA-CHACHA20-POLY1305

x64 failure:

Testing DHE-RSA-CHACHA20-POLY1305
Available compression methods:
  1: zlib compression
ERROR in SERVER
140735238714208:error:1408A0C1:SSL routines:ssl3_get_client_hello:no shared cipher:s3_srvr.c:1420:
TLSv1.2, cipher (NONE) (NONE)
1 handshakes of 256 bytes done
Failed DHE-RSA-CHACHA20-POLY1305

Is that actually OK?

[PeterMosmans]

@jpluimers , any chance to drop by today in https://gitter.im/drwetter/testssl.sh ?

[jpluimers]

Removing the flag -DTEMP_GOST_TLS solves both

testing [SSLv3|TLSv1|TLSv1.1|TLSv1.2] cipher list order: ....failed 300ff03 vs. 300cc13

and

...error:1408A0C1:SSL routines:ssl3_get_client_hello:no shared cipher:s3_srvr.c:1420:

Working to get more ciphers running with the ./Configure parameters.

[drwetter]

Am 07/27/2015 um 11:08 AM schrieb Jeroen Wiert Pluimers:

Removing the flag |-DTEMP_GOST_TLS| solves both

|testing [SSLv3|TLSv1|TLSv1.1|TLSv1.2] cipher list order: ....failed 300ff03 vs. 300cc13 |

and
...error:1408A0C1:SSL routines:ssl3_get_client_hello:no shared cipher:s3_srvr.c:1420:

Working to get more ciphers running with the |./Configure| parameters.

I wouldn't say "solve" as it removes two GOST ciphers.

To be honest: I quite didn't understand what ./ssltest is doing there, see
issue in Peter's fork (or previous mail). But it seems borken to me.

@peter: Is that known upstream?

Cheers, Dirk

[jpluimers]

@drwetter the GOST ciphers not only broke the cipher list. What I'm aiming now is a build for both x86 and x64 with as much common ciphers and which passes the built-in tests. After that we can work our way to see which cipher breaks what and try to solve that. My gut says I'm close. But during the week I don't have much time.

[PeterMosmans]

@drwetter , I sent the GOST issue upstream last year (I will look for the RT number), but it was rejected as it's not officially supported (anymore).

[PeterMosmans]

For what's it worth, here's the ticket from July 2014: https://rt.openssl.org/Ticket/Display.html?id=3430

[jpluimers]

New build script: https://gist.github.com/jpluimers/f4de3937630b87753133
Sometimes it doesn't produce a good x64 binary on the first try, but the second try always produce good binaries. I will create a pull request for them.

[jpluimers]

I originally had this, as my binaries are named after the ./Configure parameters:

bin/openssl.darwin-i386-cc
bin/openssl.darwin64-x86_64-cc

But then I saw the binaries are not named that way:

bin/openssl.Darwin.i386
bin/openssl.Darwin.x86_64

Why is that?

I'll make a pull request with the last two names.

(BTW: found the errors in my script, resolved them, built, tested).

[jpluimers]

BTW: what about the naming of the files? I think it would make more sense naming them after the ./Configure parameters used.

Note that somewhere on my TODO list is to figure out about this -DTEMP_GOST_TLS parameter and fixing the test cases so they don't break but only warn if this define is there.

[drwetter]

first the important thing: Thx for all your work!

The naming scheme is depended where we come from. ;-) The testssl.sh logic is to look in several paths with several names. The naming scheme openssl.Darwin.x86_64 stems from a line in the code openssl.$(uname).$(uname -m). The configure naming scheme is hard to implement.

BTW: does openssl.Darwin.i386 work or is openssl.Darwin.i686 the right thing then?

WRT to -DTEMP_GOST_TLS I like also to find a solution. But lets postpone this discussion first.

[jpluimers]

Ah, the uname thing. Not sure about the extension for 32-bit mode: I just wanted is for regression testing to you can manually compare the two manually.

On my machine:

$ uname --help
uname: illegal option -- -
usage: uname [-amnprsv]
$ uname -a
Darwin RetinaMBPro1TB.local 13.4.0 Darwin Kernel Version 13.4.0: Wed Mar 18 16:20:14 PDT 2015; root:xnu-2422.115.14~1/RELEASE_X86_64 x86_64
$ uname -m
x86_64
$ uname -n
RetinaMBPro1TB.local
$ uname -p
i386
$ uname -r
13.4.0
$ uname -s
Darwin
$ uname -v
Darwin Kernel Version 13.4.0: Wed Mar 18 16:20:14 PDT 2015; root:xnu-2422.115.14~1/RELEASE_X86_64

[drwetter]

@jpluimers @ALL : What does uname -m return for the 32 bit platform?

I am afraid otherwise your 32 bit build is not being picked up by testssl.sh .

[jpluimers]

Found it: on older equipment, it returns i386. See http://apple.stackexchange.com/questions/1111/why-does-uname-m-says-i386-even-if-im-on-macbook-pro-on-intel-core-2-duo

[drwetter]

good, thx!

[jpluimers]

@PeterMosmans what would be the best to keep me informed when to deliver new binaries after your sources get updated?

[PeterMosmans]

Shall I send you an email on your github address after an important update/official release ?

[drwetter]

PS: As far as testssl.sh is concerned I am more on the conservative side, so I am happy if I have a stable binaries which is proven to do its job.

OTOH I seem to miss what good things you have done @PeterMosmans wrt to changes.

[jpluimers]

@PeterMosmans yes please, or if I can watch it through RSS that would be even better.
BTW: Is this a relevant patch for you? https://twitter.com/jperkin/status/632116341709893632