Opened 10 years ago

Closed 8 years ago

#46651 closed enhancement (wontfix)

openssl @1.0.1k_0: add variants

Reported by: mouse07410 (Mouse) Owned by: larryv (Lawrence Velázquez)
Priority: Normal Milestone:
Component: ports Version:
Keywords: Cc: neverpanic (Clemens Lang)
Port: openssl

Description

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. :-)

Attachments (2)

Portfile (3.8 KB) - added by mouse07410 (Mouse) 10 years ago.
Portfile with added variants for openssl-1.0.1k port
openssl-port.diff (1.2 KB) - added by mouse07410 (Mouse) 10 years ago.
Diff against the current (I hope :) Portfile for openssl-1.0.1k

Download all attachments as: .zip

Change History (14)

Changed 10 years ago by mouse07410 (Mouse)

Attachment: Portfile added

Portfile with added variants for openssl-1.0.1k port

comment:1 Changed 10 years ago by larryv (Lawrence Velázquez)

Owner: changed from macports-tickets@… to mww@…
Summary: Add variants to OpenSSL Portopenssl @1.0.1k_0: add variants
Version: 2.3.3

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.

comment:2 in reply to:  1 Changed 10 years ago by 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.

Last edited 10 years ago by mouse07410 (Mouse) (previous) (diff)

Changed 10 years ago by mouse07410 (Mouse)

Attachment: openssl-port.diff added

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

comment:3 Changed 10 years ago by mouse07410 (Mouse)

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

comment:4 Changed 10 years ago by jmroot (Joshua Root)

Cc: cal@… added; cal@… removed
Owner: changed from mww@… to larryv@…

comment:5 Changed 10 years ago by 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.

Last edited 10 years ago by mouse07410 (Mouse) (previous) (diff)

comment:6 Changed 10 years ago by 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.

comment:7 Changed 10 years ago by 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?

comment:8 Changed 10 years ago by neverpanic (Clemens Lang)

Yes, unfortunately that is the case.

comment:9 in reply to:  7 Changed 10 years ago by 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

comment:10 Changed 10 years ago by 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!

comment:11 in reply to:  10 Changed 10 years ago by 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.

comment:12 Changed 8 years ago by neverpanic (Clemens Lang)

Resolution: wontfix
Status: newclosed

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.
Note: See TracTickets for help on using tickets.