Add crypto variants to openssl & use system zlib

[michaelld (Michael Dickens)]

OpenSSL 1.0.0a allows for extensions for md2, kerberos, and others as well as moves to using system (MacPorts) provided zlib. I'm attaching a patch to the current (1.0.0a, epoch 1, revision 0) Portfile to allow these changes. The default install isn't changed, and in my testing openssl works just before with or without the variants (the variants are plugin extensions and headers, and do not impact the application).

[michaelld (Michael Dickens)]

Portfile diff for openssl 1.0.0a to allow for crypto variants

[jmroot (Joshua Root)]

What problem do you see with zlib currently? Openssl is already dynamically linked to MP's zlib for me. I seem to remember someone changed zlib to zlib-dynamic in the past and it did not have the desired effect. Also, why is the 'make depend' necessary?

It would be good to make the variant descriptions more descriptive as well; the ones for md2 and rc5 especially don't convey any more information than you get from the variant name. MD2 is a hash function with severe security problems, let the user know that.

[michaelld (Michael Dickens)]

I've now tried out all of the 'zlib' variants, and I think leaving that flag alone is best -- though I don't find harm in changing it. Everything seems to work just fine either way, but with the zlib-dynamic none of the libraries or executables seem to require zlib at all -- but they all seem to work. With just 'zlib' I see the dependency as expected, so I'm not sure what's going on there. Leaving it alone is probably best.

The "make depend" is required if any of the defaults are changed. Or, rather, when running 'configure' if I change from the defaults then a line is printed out at the end to that effect & I believe it. It's a pretty simple thing to do either way. I would guess that compiling works anyway, but doing this command before building helps speed compiling up a bit.

As for the variants, I'm open to suggestions as to what should or not be included; there are other cypers/extensions that I didn't add since I -really- had no idea what they were (I've at least heard of those I added). As I was reading through the configure script (itself, and it's help), I saw these as options that weren't being implemented & thought "why not?" ... hence a quick change to the Portfile to see if they work, and they do. So, why not include them in some capacity & let the user decide. As to the variant descriptions, yes, they could be better. Please feel free to change them; or, I can make a quick change here & replace the current patchfile.

[michaelld (Michael Dickens)]

2nd try at openssl Portfile diff

[michaelld (Michael Dickens)]

I've reverted to 'zlib'. I went over 'Configure' again & added all of its options as new variants. I also looked up what all the variants mean & added that info to their description. After a 'destroot' I was looking at the library dependencies of the libraries, executables, and engines, and noticed that the last incorrect referred to themselves without a full path. So, I've added a "post-destroot" to correct those paths; no idea if it's truly necessary, but it works. Anyway, give this new file a look over & see what you think.

BTW> What started all of this was working on ticket #25652: for some reason this 'qca-ossl' release does not check to see whether openssl has md2 enabled or not. Which got me wondering why it wasn't enable or at least a variant. Which lead me to parsing through the Configure script. Which lead to the listing of default and experimental options as I've now included in this latest Portfile diff.

[jmroot (Joshua Root)]

MD2 used to be enabled by default, but that was changed because it's quite practical for an attacker to spoof some root certificates if you trust MD2-based signatures. So that's why some software assumes it is available instead of checking.

[michaelld (Michael Dickens)]

The release of 'qca-ossl' is so old, what you say certainly could be possible. Interestingly, the KDE folks have corrected that issue in a yet-to-be-released version of 'qca-ossl'; see ​http://websvn.kde.org/?view=revision&revision=1111902 .

[michaelld (Michael Dickens)]

3rd portfile diff: openssl doesn't work with heimdal yet, but there are apparently plans for future compatibility. So, commenting out those sections in the hope checking when of future updates become available, and then everything will be in easily place when that happens. Or, just remove those commented out line & forgetaboutit.

[michaelld (Michael Dickens)]

3rd try at openssl Portfile diff

[michaelld (Michael Dickens)]

Heimdal can be built to use openssl's crypto routines, so the Heimdal variant should just be removed entirely from these changes (beyond the fact that openssl doesn't support that version of krb5 yet).

Do you think this overall change is worth discussing further and/or are you ready to have it checked in (I can do it easily)? I do not see this change as being "harmful", and nor does it upset the default behavior for this port.

[michaelld (Michael Dickens)]

I've posted one last Portfile diff w/o the issues I found 7 weeks ago, which (1) does not change the default install; (2) allows options provided by configure to be accessible via the Portfile; and (3) lets the user decide to use any of those options if desired, no matter how secure or insecure they are. You (all) can decide what to do with it.

[michaelld (Michael Dickens)]

4th try at openssl Portfile diff

[michaelld (Michael Dickens)]

So it turns out that since we're building OpenSSL straight up (not time and again from the same source code area), we don't need to "make depend"; hence the port makedepend is not required for these changes. I've updated the 4th Portfile revision to reflect this change. OpenSSL now compiles as universal with these changes (the "make depend" for some reason broke during +universal install).

[ryandesign (Ryan Carsten Schmidt)]

Don't need to use "exec ls" to get a list of files; try using fs-traverse or glob, depending on whether you want to be recursive or not.

[jul_bsd@…]

is this ticket still relevant? last patch seems good, no?

[michaelld (Michael Dickens)]

"Is this ticket still relevant?" -> I think having these variants in place would offer options for some folks who might want them. None of the suggested variants are currently in place (as of 1.0.1g). That said, this ticket is 3+ years old, and if the port owner has not yet integrated these variants (either via the provided patch or by his/her own determination), then I think there's little need to continue to have the ticket open.

"last patch seems good, no?" -> Yes, I think so. But, again, if the port owner does not then there's little I care to do about it. I have enough in my queue already, and these are not important variants for me at this time (as they were back then).

Hence, I'm closing this ticket as "won't fix". If somebody else wants them added, then please reopen the ticket and chime in on the conversation.

[cooljeanius (Eric Gallager)]

Cc Me!