Fix bug where i2c_ASN1_INTEGER mishandles zero if it is marked as
negative.
Thanks to Huzaifa Sidhpurwala <huzaifas@redhat.com> and
Hanno Böck <hanno@hboeck.de> for reporting this issue.
Reviewed-by: Rich Salz <rsalz@openssl.org>
It should have freed them when != NULL, not when == NULL.
Reviewed-by: Kurt Roeckx <kurt@roeckx.be>
Reviewed-by: Viktor Dukhovni <openssl-users@dukhovni.org>
While *pval is usually a pointer in rare circumstances it can be a long
value. One some platforms (e.g. WIN64) where
sizeof(long) < sizeof(ASN1_VALUE *) this will write past the field.
*pval is initialised correctly in the rest of ASN1_item_ex_new so setting it
to NULL is unecessary anyway.
Thanks to Julien Kauffmann for reporting this issue.
Reviewed-by: Richard Levitte <levitte@openssl.org>
The macros BSWAP4 and BSWAP8 have statetemnt expressions
implementations that use local variable names that shadow variables
outside the macro call, generating warnings like this
e_aes_cbc_hmac_sha1.c:263:14: warning: declaration shadows a local variable
[-Wshadow]
seqnum = BSWAP8(blocks[0].q[0]);
^
../modes/modes_lcl.h:41:29: note: expanded from macro 'BSWAP8'
^
e_aes_cbc_hmac_sha1.c:223:12: note: previous declaration is here
size_t ret = 0;
^
Have clang be quiet by modifying the macro variable names slightly
(suffixing them with an underscore).
Reviewed-by: Rich Salz <rsalz@openssl.org>
ebcdic.c:284:7: warning: ISO C requires a translation unit to contain at least one
declaration [-Wempty-translation-unit]
^
1 warning generated.
Reviewed-by: Rich Salz <rsalz@openssl.org>
ARM has optimized Cortex-A5x pipeline to favour pairs of complementary
AES instructions. While modified code improves performance of post-r0p0
Cortex-A53 performance by >40% (for CBC decrypt and CTR), it hurts
original r0p0. We favour later revisions, because one can't prevent
future from coming. Improvement on post-r0p0 Cortex-A57 exceeds 50%,
while new code is not slower on r0p0, or Apple A7 for that matter.
[Update even SHA results for latest Cortex-A53.]
Reviewed-by: Richard Levitte <levitte@openssl.org>
This engine is for VMS only, and isn't really part of the core OpenSSL
but rather a side project of its own that just happens to have tagged
along for a long time. The reasons why it has remained within the
OpenSSL source are long lost in history, and there not being any real
reason for it to remain here, it's time for it to move out.
This side project will appear as a project in its own right, the
location of which will be announced later on.
Reviewed-by: Tim Hudson <tjh@openssl.org>
Rewrite ASN1_TYPE_set_int_octetstring and ASN1_TYPE_get_int_octetstring
to use the new ASN.1 code instead of the old macros.
Reviewed-by: Rich Salz <rsalz@openssl.org>
With no more symlinks, there's no need for those variables, or the links
target. This also goes for all install: and uninstall: targets that do
nothing but copy $(EXHEADER) files, since that's now taken care of by the
top Makefile.
Also, removed METHTEST from test/Makefile. It looks like an old test that's
forgotten...
Reviewed-by: Rich Salz <rsalz@openssl.org>
Rather than making include/openssl/foo.h a symlink to
crypto/foo/foo.h, this change moves the file to include/openssl/foo.h
once and for all.
Likewise, move crypto/foo/footest.c to test/footest.c, instead of
symlinking it there.
Originally-by: Geoff Thorpe <geoff@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
RFC5915 requires the use of the I2OSP primitive as defined in RFC3447
for storing an EC Private Key. This converts the private key into an
OCTETSTRING and retains any leading zeros. This commit ensures that those
leading zeros are present if required.
Reviewed-by: Andy Polyakov <appro@openssl.org>
Update code to use ASN1_TYPE_pack_sequence and ASN1_TYPE_unpack_sequence
instead of performing the same operation manually.
Reviewed-by: Rich Salz <rsalz@openssl.org>
Add new functions ASN1_TYPE_pack_sequence and ASN1_TYPE_unpack_sequence:
these encode and decode ASN.1 SEQUENCE using an ASN1_TYPE structure.
Update ordinals.
Reviewed-by: Rich Salz <rsalz@openssl.org>
The FAQ says this:
After the release of OpenSSL 1.0.0 the versioning scheme changed. Letter
releases (e.g. 1.0.1a) can only contain bug and security fixes and no
new features. Minor releases change the last number (e.g. 1.0.2) and
can contain new features that retain binary compatibility. Changes to
the middle number are considered major releases and neither source nor
binary compatibility is guaranteed.
With such a scheme (and with the thinking that it's nice if the shared
library version stays on track with the OpenSSL version), it's rather
futile to keep the minor release number in the shared library version.
The deed already done with OpenSSL 1.0.x can't be changed, but with
1.x.y, x=1 and on, 1.x as shared library version is sufficient.
Reviewed-by: Kurt Roeckx <kurt@openssl.org>
Remove partially implemented d2i_X509_PKEY and i2d_X509_PKEY: nothing
uses them and they don't work properly. Update ordinals.
Reviewed-by: Kurt Roeckx <kurt@openssl.org>
EVP_.*free; this gets:
EVP_CIPHER_CTX_free EVP_PKEY_CTX_free EVP_PKEY_asn1_free
EVP_PKEY_asn1_set_free EVP_PKEY_free EVP_PKEY_free_it
EVP_PKEY_meth_free; and also EVP_CIPHER_CTX_cleanup
Reviewed-by: Kurt Roeckx <kurt@openssl.org>
Remove the combine option. This was used for compatibility with some
non standard behaviour in ancient versions of OpenSSL: specifically
the X509_ATTRIBUTE and DSAPublicKey handling. Since these have now
been revised it is no longer needed.
Reviewed-by: Richard Levitte <levitte@openssl.org>
DSA public keys could exist in two forms: a single Integer type or a
SEQUENCE containing the parameters and public key with a field called
"write_params" deciding which form to use. These forms are non standard
and were only used by functions containing "DSAPublicKey" in the name.
Simplify code to only use the parameter form and encode the public key
component directly in the DSA public key method.
Reviewed-by: Richard Levitte <levitte@openssl.org>
The X509_ATTRIBUTE structure includes a hack to tolerate malformed
attributes that encode as the type instead of SET OF type. This form
is never created by OpenSSL and shouldn't be needed any more.
Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
