History log of /openbsd-src/lib/libcrypto/engine/engine.h (Results 1 – 25 of 44)
Revision Date Author Comments
# 1e091ee9 02-Mar-2024 tb <tb@openbsd.org>

Simplify engine.h

Garbage collect some more of this former horror show.

ok jsing


# 3e3c85d5 19-Nov-2023 tb <tb@openbsd.org>

Unifdef OPENSSL_NO_ENGINE in engine.h

Also rip out all the gross, useless comments. There's still too much
garbage in here...

ok jsing


# 24656ea8 04-Aug-2023 tb <tb@openbsd.org>

Move the ENGINE_new() prototype a line down


# dcdd2b67 28-Jul-2023 tb <tb@openbsd.org>

Excise ECDH_METHOD

Unlike ECDSA_METHOD, this has been unused forever but kind of needed to
stay for symmetry with ECDSA_METHOD. Now we can finally take it behind
the barn and remove its tendrils int

Excise ECDH_METHOD

Unlike ECDSA_METHOD, this has been unused forever but kind of needed to
stay for symmetry with ECDSA_METHOD. Now we can finally take it behind
the barn and remove its tendrils into ENGINE.

ok jsing

show more ...


# 29f44728 28-Jul-2023 tb <tb@openbsd.org>

Remove ECDSA_METHOD

After smtpd (in base) and libtls finally switched from ECDSA_METHOD to
EC_KEY_METHOD, much of the ECDSA_METHOD code was neutered. Remove the
remaining public API as well as numer

Remove ECDSA_METHOD

After smtpd (in base) and libtls finally switched from ECDSA_METHOD to
EC_KEY_METHOD, much of the ECDSA_METHOD code was neutered. Remove the
remaining public API as well as numerous tentacles into ENGINE.

ok jsing

show more ...


# 54359922 21-Jul-2023 tb <tb@openbsd.org>

Provide a bunch of always failing ENGINE API

This commit adds a few symbols under OPENSSL_NO_ENGINE. They will be used
after the main ENGINE code is disabled in the next bump.

The ecosystem is most

Provide a bunch of always failing ENGINE API

This commit adds a few symbols under OPENSSL_NO_ENGINE. They will be used
after the main ENGINE code is disabled in the next bump.

The ecosystem is mostly prepared for dealing with a libcrypto compiled
with OPENSSL_NO_ENGINE. There are a few stragglers like M2Crypto, dovecot
and the latest apr-util release (fixed in their development branch).

To avoid intrusive patching in these ports, we need to keep a bunch of
ENGINE symbols around despite adding OPENSSL_NO_ENGINE. This of course
meant patching some other ports, but that was way easier.

ok jsing

show more ...


# 83100f9b 18-Apr-2023 tb <tb@openbsd.org>

Move x509.h inclusion into alphabetical order


# 7e2b557a 18-Apr-2023 tb <tb@openbsd.org>

Bring includes into canonical order

Requested by jsing


# c6a6590f 18-Apr-2023 tb <tb@openbsd.org>

Move some includes out of OPENSSL_NO_DEPRECATED

Some headers were included conditionally on OPENSSL_NO_DEPRECATED in hopes
that eventually the mess of everything includes everything will magically
r

Move some includes out of OPENSSL_NO_DEPRECATED

Some headers were included conditionally on OPENSSL_NO_DEPRECATED in hopes
that eventually the mess of everything includes everything will magically
resolve itself. Of course everyone would end up building openssl with
OPENSSL_NO_DEPRECATED over time... Right.

Surprisingly, the ecosystem has come to rely on these implicit inclusions,
so about two dozen ports would fail to build because of this. Patching this
would be easy but really not worth the effort.

ok jsing

show more ...


# 71743258 26-Dec-2022 jmc <jmc@openbsd.org>

spelling fixes; from paul tagliamonte
i removed the arithmetics -> arithmetic changes, as i felt they
were not clearly correct

ok tb


# aeccd9ed 12-Jul-2022 kn <kn@openbsd.org>

Remove mkerr.pl remnants from LibreSSL

This script is not used at all and files are edited by hand instead.
Thus remove misleading comments incl. the obsolete script/config.

Feedback OK jsing tb


# 95bbafee 19-Jan-2019 tb <tb@openbsd.org>

Partial port of EC_KEY_METHOD from OpenSSL 1.1.
This commit adds init/free, support for signing, setting and
getting the method, engine support as well as extra data.

from markus


# 3938ed1e 11-Nov-2018 bcook <bcook@openbsd.org>

Add automatic threading initialization for libcrypto.

This implements automatic thread support initialization in libcrypto.
This does not remove any functions from the ABI, but does turn them into
n

Add automatic threading initialization for libcrypto.

This implements automatic thread support initialization in libcrypto.
This does not remove any functions from the ABI, but does turn them into
no-ops. Stub implementations of pthread_mutex_(init|lock|unlock) are
provided for ramdisks.

This does not implement the new OpenSSL 1.1 thread API internally,
keeping the original CRYTPO_lock / CRYPTO_add_lock functions for library
locking. For -portable, crypto_lock.c can be reimplemented with
OS-specific primitives as needed.

ok beck@, tb@, looks sane guenther@

show more ...


# e0b59b94 19-Jul-2015 doug <doug@openbsd.org>

Remove OpenSSL engine RSAX.

OpenSSL stopped building it last year and removed it this year.
Based on OpenSSL commit c436e05bdc7f49985a750df64122c960240b3ae1.

Also cranked major version in libcrypto

Remove OpenSSL engine RSAX.

OpenSSL stopped building it last year and removed it this year.
Based on OpenSSL commit c436e05bdc7f49985a750df64122c960240b3ae1.

Also cranked major version in libcrypto, libssl and libtls.

"fine with me" bcook@ miod@

show more ...


# 03a67d2e 18-Oct-2014 jsing <jsing@openbsd.org>

None of these need to include <openssl/rand.h>


# 556a7e84 22-Jun-2014 jsing <jsing@openbsd.org>

KNF.


# c3d6a26a 12-Jun-2014 deraadt <deraadt@openbsd.org>

tags as requested by miod and tedu


# 7a59c9a9 10-Jun-2014 deraadt <deraadt@openbsd.org>

Abandon the auto-ENGINE /dev/crypto interface. VIA 3des cbc receives
collateral damage.

The syncronous nature of this mechanism has hampered performance for
symmetric crypto relative to brute-force

Abandon the auto-ENGINE /dev/crypto interface. VIA 3des cbc receives
collateral damage.

The syncronous nature of this mechanism has hampered performance for
symmetric crypto relative to brute-force cpu. The assymetric crypto
support never really materialized in drivers.

So abandon the complexity.
ok tedu beck mikeb
some disagrement from djm but if he wants to test /dev/crypto ciphers
he should do it without this this gigantic API in the way

show more ...


# 1cdc2ead 02-Jun-2014 deraadt <deraadt@openbsd.org>

A few months back there was a big community fuss regarding direct-use
of the intel RDRAND instruction. Consensus was RDRAND should probably
only be used as an additional source of entropy in a mixer

A few months back there was a big community fuss regarding direct-use
of the intel RDRAND instruction. Consensus was RDRAND should probably
only be used as an additional source of entropy in a mixer.

Guess which library bends over backwards to provide easy access to
RDRAND? Yep. Guess which applications are using this support? Not
even one... but still, this is being placed as a trap for someone.

Send this support straight to the abyss.
ok kettenis

show more ...


# 1d21c530 22-May-2014 jsing <jsing@openbsd.org>

Expand the OPENSSL_{GLOBAL,EXPORT,IMPORT,EXTERN} macros - this rids the
libssl tree from all uses of these defines.

ok miod@


# d97b0cd3 15-Apr-2014 reyk <reyk@openbsd.org>

Remove the GOST engine: It is not compiled or used and depends on the
"dynamic engine" feature that is not enabled in our build. People who
need it can still pull it out of the Attic; if it is to ha

Remove the GOST engine: It is not compiled or used and depends on the
"dynamic engine" feature that is not enabled in our build. People who
need it can still pull it out of the Attic; if it is to have a Russian
engine just because it's a Russian engine.

OK deraadt@ beck@

show more ...


# c9e9c473 14-Apr-2014 reyk <reyk@openbsd.org>

Remove the GMP engine: It was an experimental engine using libgmp as
an alternative backend for BIGNUM calculations. It is PoC code that
is not enabled in OpenSSL and probably not used by anymore.

Remove the GMP engine: It was an experimental engine using libgmp as
an alternative backend for BIGNUM calculations. It is PoC code that
is not enabled in OpenSSL and probably not used by anymore.

ok deraadt@

show more ...


# d382f1d6 14-Apr-2014 reyk <reyk@openbsd.org>

Remove the CAPI engine: It is a backend for the Windows CryptoAPI and
could be maintained in an external package.

"it should probably go" beck@


# 65b775f7 14-Apr-2014 reyk <reyk@openbsd.org>

Remove the nuron engine. The static engine is not standalone and the
FPGA-based device is long obsolete.


# d19b5a2f 14-Apr-2014 reyk <reyk@openbsd.org>

Remove the nCipher CHIL engine. It is not standalone and depends on
external libraries that aren't covered by the same license.


12