| ef742f1823504e4166f678d2651cccf16e711b1e |
|
18-Aug-2016 |
David Benjamin <davidben@google.com> |
Make NativeBN's error-handling more robust.
Functions in OpenSSL/BoringSSL return some result that signals success
or failure. NativeBN was using throwExceptionIfNecessary which is almost
the same, except:
- If BoringSSL has a failure path that forgets to push an exception, it
would break. Ideally this wouldn't happen, but there may be cases.
- If some other BoringSSL consumer forgets to clear the error queue on
failure, it would appear as if a NativeBN operation failed.
Instead, consider the result code as the source of truth and change
throwExceptionIfNecessary to throwException. Also remove some unused
BN_GENCB parameters from JNI functions and tidy error paths up with
early returns.
Bug: 30917411
Change-Id: I6f73f67d559e5f02f62ed0d7e63b8ae3bf1e56be
Test: run cts -c org.apache.harmony.tests.java.math.BigIntegerTest
|
| 33fc9556dfda6298fcd7c119f68a7375e13cbed9 |
|
28-Dec-2015 |
Richard Uhler <ruhler@google.com> |
Introduce NativeAllocationRegistry API.
The NativeAllocationRegistry API provides a way to associate native
allocations with Java objects. The native allocations will
automatically be freed when the correspondong Java object becomes
unreachable.
Use NativeAllocationRegistry for BigInt.
Bug: 23130675
Change-Id: If89dc03f0668afdecf1086280d16d2803e07a62a
|
| 66e740b765384686ce87003608412e940ab5d489 |
|
24-Apr-2013 |
Elliott Hughes <enh@google.com> |
Simplify NativeBN error handling.
Change-Id: I150459cf71da6a3232c281d82c1ef7cbf1b2a2bc
|
| a125dded8ab0490d05e2fa9ec2e821ef1ae6facd |
|
23-Apr-2013 |
Elliott Hughes <enh@google.com> |
64-bit fixes for BigInteger.
I fear this is just the start for this code. There seem to be a lot
of assumptions about the types used by OpenSSL that may not hold for
a 64-bit build.
Change-Id: I05c276ff06adc66c1e7878196ce1afd5fba290d9
|
| 9229d47c1288e25ead3a2dc27fac8a4a2ee932a3 |
|
07-Mar-2011 |
Elliott Hughes <enh@google.com> |
Kill many of the stl_style_names in Java.
Change-Id: I4473a6efc74a49dd3b480a48d4c697fc773e08f8
|
| 12cd1f00c2fa1a7f37bf644cecdf7588bdc0b0a9 |
|
23-Jun-2010 |
Brian Carlstrom <bdc@google.com> |
Remove libcore's dependency on bouncycastle
external/bouncycastle
- Change to be the primary build for bouncycastle sources (as opposed to part of libcore)
- Moved OpenSSLMessageDigest from libcore to OpenSSLDigest
It uses NativeCrypto API from core, but implements a bouncycastle specific interface
- restored registration of bouncycastle MessageDigests for SHA-1, SHA-256, MD5
OpenSSLProvider versions take precedence, but explicit provider of "BC" allows choice
- enabled native versions of SHA-384 and SHA-512
- pruned MD4 implementation
frameworks/base
- frameworks and CoreTests modules now depend on bouncycastle
- update preloades classes for NativeBN package change
- moved CryptoTest to libcore
libcore
- core now builds without bouncycastle sources
- core-tests, core-tests-support, core-tests-supportlib now depend on bouncycastle
- removed libcore/openssl directory, moving NativeBN to java/math
- minor cleanup of Provider, Security, Services style while working on ProviderTest
- added new OpenSSLProvider registered as first provider to have
priority over the others to ensure our native implementations are used
- moved BouncyCastle to have priority as a provider over Harmony
- JarVerifier and JarUtils now implicitly use OpenSSLMessageDigest
- Cleanedup OpenSSLSignature, implementation needs to be finished to move to OpenSSLProvider
- To avoid using PEMWriter from BouncyCastle, NativeCrypto now takes binary encoded certs and keys
This is more efficient as well avoiding the base64 decode/encode of the binary data
- removed SHA-224 to match the RI
packages/apps/CertInstaller
- CertificateInstaller module now depends on bouncycastle
this is the only app to depend on bouncycastle
system/core
- updated BOOTCLASSPATH
Change-Id: I6205366b12baec4331b4a76e2c85d8324bf64b2c
|