summaryrefslogtreecommitdiff
path: root/src/lib/libcrypto/crypto (follow)
Commit message (Collapse)AuthorAgeFilesLines
...
* We do not need a separate file for two compatibility wrapper functions.jsing2014-04-271-2/+2
| | | | ok miod@
* Make libssl and libcrypto compile with -Werrorbeck2014-04-231-2/+2
| | | | ok miod@
* Chop off more SSLv2 tentacles and start fixing and noting y2038 issues.guenther2014-04-201-1/+1
| | | | | | | APIs that pass times as longs will have to change at some point... Bump major on both libcrypto and libssl. ok tedu@
* Do not ask the user to pass either -DB_ENDIAN or -DL_ENDIAN to the compiler,miod2014-04-181-11/+1
| | | | | | | but rather figure out the endianness from <machine/endian.h> automagically; help from guenther@ ok jca@ guenther@ beck@ and the rest of the `Buena SSL rampage club'
* first round of static config. ok miodtedu2014-04-1813-559/+0
|
* Put back i2d_ASN1_SET() and d2i_ASN1_SET() from the NO_ASN1_OLD prune, as theremiod2014-04-181-1/+2
| | | | | | | are still some 3rd-party code using it, and fixing them is not trivial. As an excuse gift, the memory leaks on failure in resurrected a_set.c have been fixed.
* we need to cranktedu2014-04-181-1/+1
|
* another round of chemo for the RAND code to provide clarity.tedu2014-04-181-3/+2
| | | | ok deraadt
* egd support is too dangerous to leave where somebody might find it.tedu2014-04-181-2/+2
| | | | ok deraadt.
* Use !defined() rather than empty().miod2014-04-171-2/+2
|
* -Walltedu2014-04-171-1/+3
|
* Ok, there was a need for OPENSSL_cleanse() instead of bzero() to preventmiod2014-04-171-2/+2
| | | | | | | | | | | supposedly smart compilers from optimizing memory cleanups away. Understood. Ok, in case of an hypothetically super smart compiler, OPENSSL_cleanse() had to be convoluted enough for the compiler not to recognize that this was actually bzero() in disguise. Understood. But then why there had been optimized assembler versions of OPENSSL_cleanse() is beyond me. Did someone not trust the C obfuscation?
* Move the machine-specific parts of the libcrypto Makefile to per-arch makefilemiod2014-04-173-104/+124
| | | | | | fragments, to ease maintainance, and see through the fog of bugs. "looks good" deraadt@
* Fully kill FIPS API. Forcible certification conflicts with the goals of atedu2014-04-171-2/+2
| | | | | | free software project. ok beck deraadt Ports calling FIPS_mode_set(1): mongodb
* No need to define ANSI_SOURCE and NO_ERR. TERMIOS kept until ui/ui_openssl.cmiod2014-04-161-2/+2
| | | | gets a second trim.
* No need to build with -DOPENSSL_NO_CAPIENG and -DOPENSSL_NO_HW_xxx for allmiod2014-04-161-10/+1
| | | | now removed engines.
* Remove DES_read_password and DES_read_2passwords which are `modern' flavoursmiod2014-04-161-2/+1
| | | | | | of des_old.h routines, acting as wrappers about the OpenSSL UI API. Nothing should use these functions directly. Riding the recent libcrypto major bump (in a `des' car).
* Your operating system memory allocation functions are your friend. If theybeck2014-04-161-2/+2
| | | | | | | | are not please fix your operating system. Replace mem.c with an API-compatible wrapper that just calls the system functions and does not allow a one word modification of a variable in a running shared library to turn on memory debug functions that expose things that should not be seen. ok tedu@
* don't even pretend to build md2, seed, or jpaketedu2014-04-151-17/+3
| | | | ok beck deraadt
* The more you remove Chtulhu^WVMS tentacles, the more there aremiod2014-04-1513-26/+0
|
* 12 years ago, old_des.h was used to provide compatibility with libdes.tedu2014-04-151-3/+2
| | | | | | | | | | | | The man page says "Compatibility des_ functions are provided for a short while" and indeed even the original commit message says "The compatibility functions will be removed in some future release, at the latest in version 1.0." So here we are, a short while later. Now I've only been an OpenBSD developer for 11 years, one year less than this header has existed, but in that brief time, I've learned a thing or two about deleting obsolete code. It doesn't delete itself. And worse, people will continue using it until you force them onto a better path.
* Crank major for libcrypto and libssl; more symbol removals to occur during themiod2014-04-151-2/+2
| | | | | next few moments, don't rush your update. Requested by deraadt@
* The NO_ASN1_OLD define was introduced in 0.9.7, 8 years ago, to allow formiod2014-04-151-2/+2
| | | | | | | | | | obsolete (and mostly internal) routines to be compiled out. We don't expect any reasonable software to stick to these interfaces, so better clean up the view and unifdef -DNO_ASN1_OLD. The astute reader will notice the existence of NO_OLD_ASN1 which serves a similar purpose, but is more entangled. Its time will come, soon.
* Just like every web browser expands until it can read mail, every modularmiod2014-04-151-3/+3
| | | | | | | | | | | | | | | library expands until it has its own dlfcn wrapper, and libcrypto is no exception. Remove the non-dlfcn DSO methods. This causes public DSO_METHOD_{beos,dl,vms,win32} to disappear (major bump coming soon). Note that portable software ought to use DSO_METHOD_openssl instead of picking the backend directly (which makes one wonder why the backends are exposed, as it is unlikely that more than one can work on your system). ok beck@ deraadt@
* remove FIPS mode support. people who require FIPS can buy something thattedu2014-04-151-3/+3
| | | | | meets their needs, but dumping it in here only penalizes the rest of us. ok beck deraadt
* Send the rotIBM stream cipher (ebcdic) to Valhalla to party for eternitybeck2014-04-151-3/+2
| | | | | with the bearded ones... some API's that nobody should be using will dissapear with this commit.
* As we now remove it permanently, we no longer need NO_WINDOWS_BRAINDEATHbeck2014-04-151-2/+2
| | | | | as a build time option... ok deraadt@ miod@
* Replace the old OpenSSL PRNG by direct use of arc4random_buf(), keeping themiod2014-04-151-2/+2
| | | | | | | | | | | | | | | | | | | | | existing RAND interfaces unchanged. All interfaces allowing external feed or seed of the RNG (either from a file or a local entropy gathering daemon) are kept for ABI compatibility, but are no longer do anything. While the OpenSSL PRNG was required 15+ years ago when many systems lacked proper entropy collection, things have evolved and one can reasonably assume it is better to use the kernel (system global) entropy pool rather than trying to build one's own and having to compensate for thread scheduling... <RANT> Whoever thought that RAND_screen(), feeding the PRNG with the contents of the local workstation's display, under Win32, was a smart idea, ought to be banned from security programming. </RANT> ok beck@ deraadt@ tedu@
* revert 1.2 and define OPENSSL_NO_EC_NISTP_64_GCC_128 again, it has a downsidesthen2014-04-141-0/+3
| | | | (breaks ssh ecdsa keys)
* Don't bother compiling files which end up containingmiod2014-04-141-2/+2
| | | | | | #if OPENSSL_SYS_NOTYOURS <whole file> #endif
* Cope with the removal of openssl/symhacks.hderaadt2014-04-131-2/+1
|
* Don't edit on cvs. 23.1 as intended.miod2014-04-131-2/+2
|
* Do not install e_os.h, it is not an external header and should not be usedmiod2014-04-131-2/+1
| | | | by anything in userland.
* Move undocumented internal OPENSSL_DIR interface from libcrypto to libssl,miod2014-04-131-2/+2
| | | | | | so that libssl no longer need to access the non-external headers of libcrypto to build. No library bump, riding upon the recent update.
* Crank libcrypto minor (addition of BN_consttime_swap and CRYPTO_memcmp)miod2014-04-131-1/+1
| | | | and libssl major (ssl_check_clienthello_tlsext split into two functions)
* No longer define OPENSSL_NO_EC_NISTP_64_GCC_128 on amd64; requested by djmmiod2014-04-131-3/+0
|
* Move build machinery for libcrypto from libssl/crypto to libcrypto, as wellmiod2014-04-1116-0/+4553
as configuration files; split manpages and .pc files between libcrypto and libssl. No functional change, only there to make engineering easier, and libcrypto sources are still found in libssl/src/crypto at the moment. ok reyk@, also discussed with deraadt@ beck@ and the usual crypto suspects.