openssl @1.0.1k_0: add variants

[mouse07410 (Mouse)]

It would be nice if Macports OpenSSL could be installed with JPAKE support, linked against GMP library (port), etc.

My attached Portfile provides these as variants (one can build with, or without them):

• gmp - adds GMP port as dependency, and links openssl & its libraries against libgmp
• jpake - enables experimental JPAKE support
• deprecated - enables RC5 and MD2 algorithms

I've tested my Portfile on my Macs (all running Mac OS X 10.9.5), and all of my ports including openssl are build with clang from Xcode-6.1.1 (the current).

I hope you can incorporate my Portfile into OpenSSL port.

Thanks!

P.S. Copyright is of course whatever Macports/OpenSSL requires. Use it at will, just don't hold me accountable for anything. :-)

[mouse07410 (Mouse)]

Portfile with added variants for openssl-1.0.1k port

[larryv (Lawrence Velázquez)]

The portfile you attached is basically illegible. As per ​The Guide, please attach a diff against the current portfile instead.

What benefit does linking against GMP provide, and are there good reasons why a user might not want this? Same question for enabling the deprecated algorithms.

[mouse07410 (Mouse)]

Replying to larryv@…:

The portfile you attached is basically illegible.

My fault. Though I did run "port lint --nitpick openssl", and everything was fine:

$ port lint --nitpick openssl
--->  Verifying Portfile for openssl
--->  0 errors and 0 warnings found.

As per ​The Guide, please attach a diff against the current portfile instead.

Attaching file "openssl-port.diff". Hope it is fine now.

What benefit does linking against GMP provide, and are there good reasons why a user might not want this?

The benefits would be getting better performance on big number crunching (such as in RSA algorithm) provided by GMP library. The reason not to want this IMHO would be lack of performance gain - if on a given platform OpenSSL native BN (bignum) implementation outperforms GMP.

Same question for enabling the deprecated algorithms.

One benefit would be ability to use those older algorithms when there's a need if there's a need (plus algorithm freaks that just want to be able to use whatever there is whenever they want it :). A reason not to want it would be if the user does not have a need for those algorithms - in which case it would be safer to avoid carrying around the weaker code altogether, lest by chance somebody misconfigures it and results in a "production-level" communication under-protected.

Please don't hesitate to ask more, especially if my explanations are less than crisp.

[mouse07410 (Mouse)]

Diff against the current (I hope :) Portfile for openssl-1.0.1k

[mouse07410 (Mouse)]

Any comment? Is this patch acceptable now? Does it need anything from me at this point?

[mouse07410 (Mouse)]

A semi-related question. Since my patches haven't been accepted yet - I've been forced to maintain a "shadow" openssl port:

...
# For proper functionality of various resources (port groups, mirror
# sites, etc.), the primary MacPorts source must always be tagged
# "[default]", even if switched from the default "rsync://" URL.

file:///Users/ur20980/ports
rsync://rsync.macports.org/release/tarballs/ports.tar [default]

The problem with that of course is that whenever the "main" openssl port gets an upgrade - it is not propagated to mine.

My question is: is it possible to somehow get the benefits of both approaches - receive the regular port updates, and yet have my own patches applied automatically? It would really save me a lot of pain.

P.S. Needless to say, my question applies to openssl-1.0.2a, as 1.0.1k has been obsoleted for a while now.

[neverpanic (Clemens Lang)]

You can use a subversion checkout instead of the normal ports tree. That way changes get merged automatically and your local changes don't get overwritten on sync. Obviously, that comes with the occasional merge conflict you'll have to fix manually. wiki:howto/SyncingWithSVN has more info.

[mouse07410 (Mouse)]

I see. One shortcoming of the SVN approach seems to be that I cannot limit it to just one port? It is either the entire Macports tree, or nothing?

[neverpanic (Clemens Lang)]

Yes, unfortunately that is the case.

[pixilla (Bradley Giesbrecht)]

Replying to uri@…:

I see. One shortcoming of the SVN approach seems to be that I cannot limit it to just one port? It is either the entire Macports tree, or nothing?

You can perform an empty svn checkout and update the depth with the desired paths:

svn co --depth empty http://svn.macports.org/repository/macports/trunk
svn update --set-depth empty trunk/dports
svn update --set-depth empty trunk/dports/devel
svn update --set-depth infinity trunk/dports/devel/openssl

[mouse07410 (Mouse)]

My apologies - I'm not sure I completely understand.

My goal (ideal) is to be able to have Macports deal with all its ports "normally", i.e. having

sudo port selfupdate && sudo port upgrade outdated

work as before. For one port - openssl - I want it to both track the main port and to apply my specific patch (at least until I can convince Dr. Henson that supporting a quirk of Apple Certificate Assistant is a good thing :). It looks like the only way to have the openssl port accommodate my patch is using SVN to pull it in.

How (if at all) can I accomplish the above - have all (most :) of the Macports-served ports maintained normally, but this one port going through SVN?

Thanks!

[larryv (Lawrence Velázquez)]

Replying to uri@…:

My goal (ideal) is to be able to have Macports deal with all its ports "normally", i.e. having

sudo port selfupdate && sudo port upgrade outdated

work as before.

This is getting off-topic for this ticket. Please ask for further help on this matter on macports-users.

[neverpanic (Clemens Lang)]

attachment:openssl-port.diff​ references a patch-null-absent.diff patchfile that you haven't attached.

Additionally:

• JPAKE support has been removed upstream
• GMP support has been removed upstream
• I don't want to provide an option to support outdated algorithms for the same reason we're not providing a variant to re-enable SSLv3.