I was compiling some 'C' code that uses openssl under Fedora 27 (version 1.1.0g-1). I made some needed changes (from the 1.0.2 version of my code) and things now compile o.k. again.
I then tried to compile with the option "OPENSSL_API_COMPAT=0x10100000L" which I understand causes the compiler to not include APIs deprecated in openssl version 1.1.
Now, my code won't compile and seems to not find the definitions of things like BN_bin2bn() and BN_free().
Looking at the headers, /usr/include/openssl/dh.h doesn't even include bn.h at all with this option set.
So, are the BN_xxxx functions now all deprecated in 1.1?
Looking at the openssl 1.1 documents in places like https://wiki.openssl.org/index.php/OpenSSL_1.1.0_Changes doesn't mention this being the case.
The description of BN_bin2bn() at https://www.openssl.org/docs/man1.1.0/crypto/BN_bin2bn.html doesn't indicate this as deprecated as far as I can see.
Am I missing something? If these functions are deprecated, I would like to know what I'm supposed to use instead (for dh.h things, etc.).
Thanks;
.....c:927:8: error: implicit declaration of function ‘BN_bin2bn’; did you mean ‘OBJ_nid2sn’? [-Werror=implicit-function-declaration]
p = BN_bin2bn(dh1024_p, sizeof dh1024_p, NULL);
^~~~~~~~~
The BN functions are still present and non-deprecated. Check out the lack of relevant #ifs preceding line 180 in https://github.com/openssl/openssl/blob/OpenSSL_1_1_0-stable/include/openssl/bn.h
Looks like they must've just done some header-refactoring to eliminate header coupling. In fact, in the dh header for 1.1 we now see
# if OPENSSL_API_COMPAT < 0x10100000L
# include <openssl/bn.h>
# endif
at line 20 in https://github.com/openssl/openssl/blob/OpenSSL_1_1_0-stable/include/openssl/dh.h. So moving forward they don't include the bignum header automatically. This sounds exactly like improving the header coupling.
Try explicitly adding #include <openssl/bn.h> after your include of dh.h.
Related
I'm doing some compile works recently.
After updated openssl1.1.1f to openssl1.1.1h, I met some compile errors for packages using the openssl headers "bio.h" and "evp.h".
That's because openssl1.1.1h add something like this:
/*
* name is cast to lose const, but might be better to route through a
* function so we can do it safely
*/
#ifdef CONST_STRICT
/*
* If you are wondering why this isn't defined, its because CONST_STRICT is
* purely a compile-time kludge to allow const to be checked.
*/
int BIO_read_filename(BIO *b, const char *name);
# else
# define BIO_read_filename(b,name) (int)BIO_ctrl(b,BIO_C_SET_FILENAME, \
BIO_CLOSE|BIO_FP_READ,(char *)(name))
# endif
If the CONST_STRICT marco is defined, you have to implement the api yourself otherwise you will get an undefined reference error during linkage phase.
I wonder what compile option I have to add to make the CONST_STRICT marco NOT defined?
Thanks in advance!
I miss-understood what the comment in the openssl header file means, thanks to Guillaume Petitjean who corrected me.
The error I got is due to other cause. One of my packages has an older version of openssl in it, and it installed it's header files after it's being built. In that version the api BIO_read_filename was not implemented by marco definition but in a source file. I modified the makefile of the package to not install the older openssl header file and the error are gone.
I am trying to switch my code to a new way of handling lexers in Scintilla.
This is what worked in previous versions of Scintilla, old ways:
scintilla_send_message(widget, SCI_SETLEXER, SCLEX_CPP, 0);
Since around version 4.4 I must do it new ways. From reading documentation I believe it is something like this:
ILexer5 *lexer = CreateLexer("cpp");
scintilla_send_message(widget, SCI_SETILEXER, 0, lexer);
But I am gettin ILexer5 is undefined and CreateLexer is undefined. I am tryng to find appropriate headers and static libs to add to my code and a compiler switch list. Please help.
My current GCC switches include this:
~/scintilla/bin/scintilla.a -DGTK -DSCI_LEXER -lstdc++ -I~/scintilla/include
Note I am using C not C++.
Lexilla.h is now in the lexilla repository.
As of February it has #ifdef __cplusplus guards, so it appears to support C as well.
If you still encounter issues, I'd suggest pasting the exact error message.
I'm trying to build a project in Xcode but I get the following errors Implicit declaration of function 'clear' is invalid in C99 and Conflicting types for 'clear'.
Here's the code:
//main.c
#include <stdio.h>
#include "tree.h"
int main(){
clear(); // Implicit declaration of function 'clear' is invalid in C99
return 0;
}
//tree.c
#include <stdio.h>
#include "tree.h"
void clear(){ ///Conflicting types for 'clear'
printf("Command clear.\n");
}
//tree.h
#include <stdio.h>
void clear(); ///Conflicting types for 'clear'
Why do I get these errors and warnings? I've tried to search for the solution on StackOverflow, but all the related answers where about the case when there were no #include of some sort.
'clear' is not a keyword in C so it's not the case, is it? (source: http://aboutc.weebly.com/keywords.html)
Related topics (do not answer my question although they are actually related):
Implicit declaration of function 'sum' is invalid in C99
Implicit declaration of function is invalid in C99
Thanks for any help.
UPDATE!
It turns out that changing the name of the clear funtcion to a cleark function solved the problem. Nevertheless it does not make any sense to me yet.
UPDATE 2!
I based my project on the command line tool template from Xcode 6.3 on Mac OS 10.10. Because of that Xcode has automatically added some libraries and flags to the project's compiler. What's the most important here is that the curses.h header has been added and this header already contains the clear() function.
Here's the Conflicting types for 'clear' error log:
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/include/curses.h:541:28: Previous declaration is here
I've tried to remove the -lcurses from the compiler's flags manually, but I couldn't locate such settings. Is there any another way to build the project? (All in all my goal is to be able to use the Xcode's debugger when the project expands)
UPDATE 3!
According to what Paul Griffiths discovered and published in the comment below the problem is following:
I can indeed replicate this problem with Xcode 6.3.1 with only the code presented. For some reason, stdio.h seems to be including curses.h (i.e. if you don't include stdio.h, this issue goes away), and I haven't been quickly able to find a way to stop it doing that. This seems to be problematic, since standard headers should not import random symbols into the global namespace without an easy and obvious way to turn it off.
Normally I run the C preprocessor to see what the compiler actually parses. However, following Xcode Preprocessor Output to examine the preprocessor output with Xcode does not achieve that - it is translating the #include to #import. Here is what the preprocessor view shows me:
// Preprocessed output for tree.c
// Generated at 9:24:57 PM on Friday, May 1, 2015
// Using Debug configuration, x86_64 architecture for curses-vs-stdio target of curses-vs-stdio project
# 1 "/Users/thomas/Desktop/curses-vs-stdio/curses-vs-stdio/tree.c"
# 1 "<built-in>" 1
# 1 "<built-in>" 3
# 322 "<built-in>" 3
# 1 "<command line>" 1
# 1 "<built-in>" 2
# 1 "/Users/thomas/Desktop/curses-vs-stdio/curses-vs-stdio/tree.c" 2
# 1 "/Users/thomas/Desktop/curses-vs-stdio/curses-vs-stdio/tree.h" 1
void clear(void);
#import Darwin.C.stdio; /* clang -E: implicit import for "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/include/stdio.h" */
# 5 "/Users/thomas/Desktop/curses-vs-stdio/curses-vs-stdio/tree.c" 2
void clear(void) {
printf("Command clear.\n");
}
Apparently the problem is Xcode's use of modules rather than stdio.h including curses.h. The "Darwin" module is where the problem lies.
In fact, if I disable modules (using the hint in Enable Clang Modules, Disable Auto Linking), the build problem goes away. This is
in Build Settings
section Apple LLVM 6.1 - Language - Modules
setting Enable Modules (C and Objective-C)
As a further hint to the problem, having rearranged the example slightly (putting the prototype before the include), I see a message complaining about overloading — but that is not C.
Perhaps Apple will fix this in the next release.
You are including "trie.h", not "tree.h".
But maybe that's just you being careless when posting the code...
I bet there is another function named clear () defined somewhere. Possibly in your version of stdio.h.
I wrote function that encrypts/decrypts a buffer (2 versions of the same function - first, with cryptopp, second - with openssl).
I would like to make something like this:
#if defined OPENSSL
run_aes_openssl(...);
#elif defined CRYPTOPP
run_aes_crytopp(...);
#else
error(...);
#end
Is it possible?
It's not quite that simple. In order to find that a macro is defined, you have to include the header that defines that macro. And C doesn't have anything like "include foo.h iff it exists"; it has to exist otherwise there is a compilation error.
Normally this would be sorted out by a script that you run before compilation. Your script checks locations like /usr/include, /usr/local/include, etc., to see if the OpenSSL headers are there; and then it outputs a Makefile which contains in the CFLAGS -DHAVE_OPENSSL. Then your code can check for that macro.
This is quite a bit of hullabaloo, to keep things simple you could require the user to manually edit a file , e.g. distribute your project with something called user_config.h that the user is supposed to edit before compiling, to specify where they put OpenSSL and so on.
There is a preset system called GNU Autoconf which contains a script that checks your system for everything under the sun. This has its advantages and disadvantages; it makes things easier for plebs downloading your source code, but it is bloaty and can be hard work for yourself.
How to check if openssl or cryptopp is installed and use the library that actually exists in the system (is installed)?
If your application was built on the system it is running, then the code you have shown is OK. Presumably, the build system will detect both OpenSSL and Crypto++. In the case both are available, it looks like your code will favor OpenSSL.
If you application is built elsewhere and needs to check at runtime, then you will need dlopen, dlsym, dlclose and friends.
In the case of runtime checking, its probably best to build a dispatch table and call through it. For example, you might have a table with function pointers to your internal run_aes_openssl, run_aes_crytopp, etc.
Upon startup, you populate the table based on the results of dlopen. If you find OpenSSL, then you populate your table with the OpenSSL gear. If you find Crypto++, then you populate your table with the Crypto++ gear.
C++ can be painful to use with dlopen and friends because of name mangling. Worse, the mangling differs between distributions and runtime library versions. For example, here's a function to generate a private RSA key:
RSA::PrivateKey key;
key.GenerateRandomWithKeySize(prng, 1024);
And here's the corresponding function names on Mac OS X. Debian and Red Hat will likely be different.
$ nm cryptopp-test.exe | grep -i GenerateRandom | grep -i RSA
00000001000c7d80 T __ZN8CryptoPP21InvertibleRSAFunction14GenerateRandomERNS_21RandomNumberGeneratorERKNS_14NameValuePairsE
00000001000c8eb0 T __ZThn120_N8CryptoPP21InvertibleRSAFunction14GenerateRandomERNS_21RandomNumberGeneratorERKNS_14NameValuePairsE
I am new to openssl, and I downloaded openssl-fips-2.0.1 codes from openssl, however, I was not able to trace to the definition of FIPS_mode_set() as stated in the documentation and security policy. I did find, however, fips_set_mode() in fips.c, but they are not referring to the same, am I right?
Where is the definition?
Please advise me.
FIPS_mode_set() code not found in openssl package
You have to know how to ask...
openssl-1.0.1f$ grep -R FIPS_mode_set *
apps/openssl.c: if (!FIPS_mode_set(1)) {
CHANGES: *) Functions FIPS_mode_set() and FIPS_mode() which call the underlying
crypto/cpt_err.c:{ERR_FUNC(CRYPTO_F_FIPS_MODE_SET), "FIPS_mode_set"},
crypto/evp/evp_cnf.c: if (!FIPS_mode() && !FIPS_mode_set(1))
crypto/crypto.h:int FIPS_mode_set(int r);
crypto/o_fips.c:int FIPS_mode_set(int r)
Binary file fips_premain_dso matches
ssl/ssltest.c: if(!FIPS_mode_set(1))
util/libeay.num:FIPS_mode_set 3253 EXIST::FUNCTION:
openssl-1.0.1f$
The declaration is in crypto/crypto.h and the definition is in crypto/o_fips.c. Here's from o_fips.c:
int FIPS_mode_set(int r)
{
OPENSSL_init();
#ifdef OPENSSL_FIPS
#ifndef FIPS_AUTH_USER_PASS
#define FIPS_AUTH_USER_PASS "Default FIPS Crypto User Password"
#endif
if (!FIPS_module_mode_set(r, FIPS_AUTH_USER_PASS))
return 0;
if (r)
RAND_set_rand_method(FIPS_rand_get_method());
else
RAND_set_rand_method(NULL);
return 1;
#else
if (r == 0)
return 1;
CRYPTOerr(CRYPTO_F_FIPS_MODE_SET, CRYPTO_R_FIPS_MODE_NOT_SUPPORTED);
return 0;
#endif
}
If you were looking for FIPS_mode_set to enter into "FIPS mode" with special setup or switch some algorithms, that does not happen at this step.
It happens earlier when linking. What happens under the hood is fipsld is you compiler, and it looks for an invocation of LD. If LD is not invoked, then fipsld just calls your regular compiler (probably /usr/bin/gcc). If it sees an invocation of LD, then it does three things.
First, it compiles fips_premin.c. Then it calls the real ld to perform the final link with all your object file and the fips_premain.o it produced. Finally, it calls incore to swap in the FIPS Object Module, calculate the signature over the relevant text and data (relevant means the FIPS code and data), and then embeds the signature in the executable.
The signature is generated with an HMAC, and the key is embedded in the executable. There's nothing special about it, and its constant across all executables throughout the world. Here's the key used: etaonrishdlcupfm.
If you are not taking special steps when build your executable, then you are probably missing some steps. Here are the steps to use fipsld and incore:
$ export CC=`find /usr/local -name fipsld`
$ echo $CC
/usr/local/ssl/fips-2.0/bin/fipsld
$ export FIPSLD_CC=`find /usr/bin -name gcc`
$ echo $FIPSLD_CC
/usr/bin/gcc
Now, do a standard config and make. Sometimes you have to do config, then adjust CC and FIPSLD_CC, and then run make because some config files choke on the arrangement. Sometimes you have to open a Makefile after config and change CC to /usr/local/ssl/fips-2.0/bin/fipsld. There's lots of ways to do it in an effort to work around particular packaging.
I downloaded openssl-fips-2.0.1 codes from openssl, however, I was not able to trace to the definition of FIPS_mode_set()
openssl-fips-NNN provides the FIPS validated cryptography if you build the FIPS Object Module according to the Security Policy. You can find the OpenSSL FIPS 1402- Security Policy at here.
If all you did was download and build openssl-fips-NNN, then you are probably not using FIPS validated cryptography. There's a procedure to follow, and that includes getting a "trusted" copy of the source code. You can download and verify a signature, but you need a FIPS validated signature checker, which creates a chicken-and-the-egg problem because you can't build it from sources. So the practical solution is to order the CD from the OpenSSL Foundation. Its bizarre, but its the truth. See, for example, the OpenSSL FIPS User Guide or the OpenSSL FIPS Security Policy, Appendix B, Controlled Distribution File Fingerprint.
Once you have the FIPS Object Module built and installed, you can build the FIPS Capable version of the library. The FIPS Capable OpenSSL will use the FIPS Object Module, if available. Think of it as a "pluggable" architecture.
The FIPS Capable version of the library is simply openssl-NNN, such as openssl-1.0.1e and openssl-1.0.1f. Its what you know and love.
You might also consider something like ctags as a source code browser to help you find things and jump around. See Exuberant Ctags on Sourceforge.
Please refer header file crypto.h. I am able to find its definition there at line 566 as follows:
int FIPS_mode_set(int r);
Documentation clearly mention that it is in header file <openssl/crypto.h>.
So, in your code, include openssl/crypto.h to include the definition of this function. If you face other problem, you can browse through questions of OpenSSL that may help you.
For linkage FIPS_mode_set() should be available from libcrypto (*.a for static linkage and *.so for run-time linkage).
libcrypto.a/.so comes with your distro's openssl's developer package, or as a result of bulding openssl-x.y.z yourself.
You find the sources for FIPS_mode_set() in the sources for openssl-x.y.z, in the file crypto/o_fips.c.