Give a unique name so it can be installed into a system dir

[blshkv]

Currently, this fork has no unique name and make install (in short) will overwrite the original openssl library. That means that any (mostly security) tools have to compile statically or provide precompile libraries of this fork and it gives a lot of complications.

There are two tools at least which switched to this fork, see https://github.com/rbsec/sslscan/issues/126 https://github.com/nabla-c0d3/sslyze/issues/116

So it would be good if you could rename this project to something like openssl-chacha or any other appropriate name, and fix it the all Makefiles

[PeterMosmans]

Hi @blshkv , thanks for the feedback. One can use --prefix and --openssldir to install it in different locations; see also https://wiki.openssl.org/index.php/Compilation_and_Installation#PREFIX_and_OPENSSLDIR

Would that work ?

I'm a bit hesitant to change the naming and would like to keep the fork as "vanilla" as possible.

[blshkv]

No, I dont think it can help. I was talking more about shared lib{crypto,ssl} libraries installed into /usr/lib/lib{crypto,ssl}.so-<version> . Additionally, sslscan/sslyze should be able to find this version using standard -lcrypto (defined in libcrypto.pc). Alternatively, you can probably define a unique <version>?

[drwetter]

Hi Peter,

if I may add my 2 cents: What makes it difficult for me is that github seems to assume unique "names". It's harder for me to submit a patch to vanilla openssl if I have a fork from your branch with the same "name". I put that in quotes as I renamed my fork from your branch already but e.g. when I edit with a browser something in the official repo I am working on my fork of your fork.

That's quite confusing but I am still in a learning curve wrt git, who's not ;) ....

[PeterMosmans]

Hi @drwetter that sounds like something different: naming of the repository / fork :wink: To prevent naming issues in git, I created a new branch, 1.0.2-chacha. @blshkv asks to rename/renumber the binary and its libraries.

@drwetter do you think testssl.sh / you will run into issues if I would change the versioning for the binary and its libraries ? So the binary would still be named openssl, but the version number would become e.g. 1.0.2-chacha ? See also @blshkv 's suggestion

[drwetter]

On 06/30/2017 12:49 AM, Peter Mosmans wrote:

Hi @drwetter https://github.com/drwetter that sounds like something different: naming of the repository / fork 😉

yes, after writing my comment and before I went to bed I realized that it was some completely different (..) ;-)

To prevent naming issues in git, I created a new /branch/, |1.0.2-chacha|. @blshkv https://github.com/blshkv asks to rename/renumber the /binary/ and its libraries.

@drwetter https://github.com/drwetter do you think testssl.sh / you will run into issues if I would change the /versioning/ for the binary and its libraries ? So the binary would still be named openssl, but the version number would become e.g. |1.0.2-chacha| ? See also @blshkv https://github.com/blshkv 's suggestion

Thx for asking, Peter. Not at all. The binaries testssl.sh is using an I am providing (Linux and FreeBSD) are statically linked.

I can't tell for sure how it is for MacOS X. Inspecting the Mac OS X binary under FreeBSD however give me the impression it is also statically linked.

Cheers! Dirk

[blshkv]

I think ideally, it would be good to have a new -lcrypto-chacha name so it could be installed as a system library and it would be possible to patch other tools

[blshkv]

yet another tool requires this fork: https://github.com/mozilla/cipherscan

[PeterMosmans]

Hi @blshkv - Thanks for the update :wink: - This is still on my TODO list, to research the implications further (and, depending the results, implement this).

Thanks for your patience, cheers.

Peter