1.0.2: configure no-cms -> make failure about openssl HOT 12 CLOSED

@pasin You need to add paths of where to find stdio.h etc. For my Android builds I do:

(cd openssl && mv Makefile Makefile.dep && sed -e 's/\-mandroid//g' Makefile.dep > Makefile) || exit 1
DEPFLAGS="$(grep DEPFLAG= Makefile | head -1 | cut -f2 -d=)"
$MAKE -C "openssl" DEPFLAG="$DEPFLAGS -I$temp_dir/sysroot/usr/include -I$temp_dir/sysroot/usr/include/linux -I$temp_dir/include/c++/4.9/tr1 -I$temp_dir/include/c++/4.9" depend || exit 1
(cd openssl && mv Makefile.dep Makefile) || exit 1

The configuration step adds -mandroid to CFLAGS and makedepend interprets it as -m which produces many warnings.

from openssl.

Thanks for reporting this. I was just about to the same.

from openssl.

The same problem is in rsa_ameth.c

from openssl.

Further problem in dh_kdf.c

from openssl.

Why do you need no-cms? I just checked and "make test" has never passed with no-cms in any 1.0.2, 1.0.1 or 1.0.0 release (they do work in 0.9.8). Since 1.0.0 was released in 2010 this does not suggest very wide use. I am tempted to remove it completely.

from openssl.

Rather than taking bait into an unproductive argument:

1. If an option is present, it should work, or it's not an option.
2. There does not appear to be a comprehensive enumeration of all possible
   configure options in the documentation. If there were, more people would
   a) understand there are optional features and b) attempt to use or exclude
   them. I made a partial, informal list here from various sources, that has
   not been vetted 100%: https://gist.github.com/8247726
3. New features should not be enabled by default in a first production
   release, but there should be time given for people to try them out. Some
   of the recent security failures seem to be attributable to this sort of
   anti-pattern.
4. There should be some sort of configure email pingback script (that can
   be optionally disabled) that reports back which configure options,
   compilers and OSes are used (minus paths) to gather statistics on what's
   being used or what is not. That way, you're not arguing with people and
   they're not arguing with you, because there would be concrete numbers to
   which to point.

We are currently using OpenSSL for production TLS termination that is
compiled as part of our custom-compiled nginx. We also happen to have an
internal staging environment with LibreSSL that is nearly pilotable because
there are too many unnecessary features in OpenSSL that we just have no use
for (DES, CMS, DTLS, on and on), hence for the production side would rather
compile out OpenSSL features to lower the attack surface.

For the record, no-des (reported on RT long ago) and several other no-
options do not work either.

from openssl.

With regards to "0" I agree, and that was kind of the point of my question. Faced with an option that doesn't work (and never has in 1.0.2) I have two possible courses of action: fix it, or remove it. I'm trying to figure out which is the correct course. On the one hand if people have a real need for it, I don't want to remove it. On the other hand, in my opinion, we have far too many options (and that is why some of them break). They complicate the code and many of them are not useful. I'd like to get rid of those ones altogether. Rich Salz has done quite a bit of work in this area.

With regards to "1" I also agree. That would be great - although I 'd put that in the category of "we need to make the documentation better". There are a whole load of other examples where that is true - its on our roadmap to address, but its going to take time to get there.

With regards to "2" I just don't agree. Sorry.

"3" is an interesting idea and those kind of stats would be really useful. Not sure how practical it is though.

from openssl.

OK, I'm giving up on no-cms. Please remove the option, as it is not working anymore.

from openssl.

Why not move cms to an email- or utility-focused subproject?  It was the subject of CVE-2010-0742 and it's extra baggage and risk in our usage.

2: Just as you wouldn't deploy new code to 100k's of servers all at once without testing, but would used exponential deployment to allow for a m "canary in the coalmine" to give a chance to rollback should their be a problem without bringing down the entire site.  Not doing so gradually is a risky process similar also to "big design upfront" that could easily be mitigated by having a beta period rather than jumping straight from PoC to production.  Introduction of new features increases attack surface and there has been a pattern of spectacular failures related to this pattern that is readily obvious from the content of CVEs.  Adoption of new features that offer advantages could be useful, but the current way risk is managed seems to need work.

3: One doesn't know what one doesn't measure.  For example, how many users deploy rc4, dtls, sctp or X.  Analytics of deployments are a nonfunctional requirement, just a decision support tool to help guide discussions based on something more than debate.  (Yes, some features are important and orthogonal to popularity in some enterprise and core internet use-cases.)  Another example of going beyond features was when Garrett Smith undertook a thoughtful survey (Why the Cool Kids Don't Use Erlang) to attempt to collate their community's sentiment into qualitative buckets.

1. Get rid of, or extract out to subprojects, features that aren't used much (3. can help guide this) or that have a history of CVEs.  Feature creep and large LOC = increasing attack surface, makes the job of attackers that much easier.  Every LOC has a support cost and a risk associated with it, so minimizing to necessary and sufficient features is one part of holistic methodology.   Anything extra that seems important to some folks but not others might be better elsewhere, rather than continually expanding without regular "spring cleanings."  Once said great amount work is done, a tighter codebase will be easier to maintain and CVEs should drop in frequency and users qualitatively safer.

These and other improvements could effectively minimize the value of other forks, and gain net positive respect by undertaking adjustments demonstrated by greater community leadership. Might encourage more donations too, who knows.

HTH

from openssl.

One voice among many adding my tuppence.

Nominally, I agree with the #0 - build options should work. Although I definitely shy away from pointing any fingers since maintaining a codebase is daunting (plus I'm a coder too!). Thus, having a computer do some work on our behalf would be nice. And an automated build script to cycle through toggling on/off cipher options would be quite handy as a nightly smoke test. This could be augmented to handle inter-dependencies. For instance, if disable XX then YY, which uses it, should also be disabled.

Meanwhile, I have a use case for various no-XXX compile options.

I build a custom libcurl/openssl for my own use with client apps and server side. In my circumstance, I [ruthlessly] forego various curl protocols and openssl ciphers - nearly all. Namely I pretty much disable everything except those I actually want and use (plus dependencies). Including disabling error messages content with "no-err" unless I'm actually debugging communication issues.

For client apps, this minimizes the size footprint. My minimalist libcurl is easily less than half the size than default builds (and more like one-third the size). For IOS/AOS mobile apps size reduction is significant. For Osx/Win apps it's being a "nice neighbor" for app install size.

For server side it adds additional security in that, fundamentally, it culls out "weak and unused (for me)" ciphers so they aren't even available as a fallback as well as omitting curl protocol support so they aren't even present for possible future exploits.

That said ... today I'm attempting to compile from mainline tips. Yes, bleeding edge. But switching to 'stable' branch (eg, 1.0.2) 1) exhibits same compile issues and 2) isn't that far behind the master tip revision anyway.

As of the moment, I have the following:

• curl ~7.45 dev https://github.com/bagder/curl @e30763c72eed43630befccf0018e4801b620d6f3
• openssl commit https://github.com/openssl/openssl @8cf2782399c449ecf91f2d292f483e7999a40f6d

Resulting in the following compile errors:

no-srp:

````
In file included from bn_srp.c:3:0:
../../include/openssl/srp.h:66:4: error: #error SRP is disabled.
 #  error SRP is disabled.
    ^
make[2]: *** [bn_srp.o] Error 1
make[2]: *** Waiting for unfinished jobs....
make[1]: *** [subdirs] Error 1
make: *** [build_crypto] Error 1
````

enable-ec:
Technically, this is a counter example to discussion about no-XXX. However, when enabled then I get following error. It appears 'ec' is enabled by default and a dependency of 'evp' which, in turn, is a dependency of a bunch of others. So not sure how this one slipped through nightly. (But possibly it's a side-effect of my 'minimalist' configuration settings.)

````
pmeth_lib.c:92:6: error: 'ec_pkey_meth' undeclared here (not in a function)
     &ec_pkey_meth,
      ^
make[2]: *** [pmeth_lib.o] Error 1
make[2]: *** Waiting for unfinished jobs....
make[1]: *** [subdirs] Error 1
make: *** [build_crypto] Error 1
````

Perhaps a "HowTo" readme doc would be useful for openssl developers. Something along the lines of a general "typical case" checklist of the various items to add, #define, etc. when incorporating a new no-XXX / enable-XXX feature.

Along the same lines, cipher inter-dependencies is a 'fun' topic in its own right. (But beyond the scope of this discussion)

from openssl.

This might not related to the issue per se. I have tried to build 1.0.2d on OSX with the same configuration parameters (with no-cms) as above, but I have seen some errors during make depend (I installed makedepend as my mac didn't have it). Below are some examples:

$ make depend
making depend in crypto...
makedepend: warning:  cannot open "x86_64"
makedepend: warning:  cryptlib.c (reading cryptlib.h, line 62): cannot find include file "stdlib.h"
    not in ./stdlib.h
    not in ../stdlib.h
    not in ../include/stdlib.h
    not in /usr/include/stdlib.h
makedepend: warning:  cryptlib.c (reading cryptlib.h, line 63): cannot find include file "string.h"
    not in ./string.h
    not in ../string.h
    not in ../include/string.h
    not in /usr/include/string.h
makedepend: warning:  cryptlib.c (reading ../e_os.h, line 468): cannot find include file "unistd.h"
    not in ./unistd.h
    not in ../unistd.h
    not in ../include/unistd.h
    not in /usr/include/unistd.h
makedepend: warning:  cryptlib.c (reading ../e_os.h, line 473): cannot find include file "sys/types.h"
    not in ./sys/types.h
    not in ../sys/types.h
    not in ../include/sys/types.h
    not in /usr/include/sys/types.h
makedepend: warning:  cryptlib.c (reading ../include/openssl/crypto.h, line 120): cannot find include file "stdlib.h"
    not in ./stdlib.h
    not in ../stdlib.h
    not in ../include/stdlib.h
    not in /usr/include/stdlib.h
makedepend: warning:  cryptlib.c (reading ../include/openssl/crypto.h, line 125): cannot find include file "stdio.h"
    not in ./stdio.h
    not in ../stdio.h
    not in ../include/stdio.h
    not in /usr/include/stdio.h
...

@steakknife or anyone here, have you seen any of these issues when running make depend?

from openssl.

no-cms will be fixed by #1269, so tracking this issue through that now. Closing.

from openssl.