| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Added a test to verify none of the removed algorithms can't actually be
retrieved, since commenting out upstream code is error prone.
KeyFactory.RSA is still deprecated and not removed since it is in use by
verity.
Bug: 67761667
Test: cts -m CtsLibcoreTestCases
Test: cts -m CtsLibcoreOkHttpTestCases
Test: cts -m CtsLibcoreWycheproofBCTestCases
Test: cts -m CtsLibcoreWycheproofConscryptTestCases
Change-Id: I983b5eeae19eca4404d68ea94765e80a85c35df7
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Revert "Remove deprecated BouncyCastle algorithms"
Revert "Remove deprecated BouncyCastle algorithms"
Revert submission 1299358-remove_bc_algos
Reason for revert: broke higkey-userdebug
Bug: 155693016
Reverted Changes:
I98adb4d2f:Load default KeyFactory instead of BC's implementa...
I5256fe1c7:Remove deprecated BouncyCastle algorithms
I0437de742:Remove deprecated BouncyCastle algorithms
Ie9e0cfa02:Remove deprecated BouncyCastle algorithms
Change-Id: I86d770df93ad7440ca7c774e118c709ad50d35e7
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Added a test to verify none of the removed algorithms can't actually be
retrieved, since commenting out upstream code is error prone.
Leaving BC deprecation in place since there are more overlapping
implementations (with Conscrypt) that we might want to remove.
Bug: 67761667
Test: cts -m CtsLibcoreTestCases
Test: cts -m CtsLibcoreOkHttpTestCases
Test: cts -m CtsLibcoreWycheproofBCTestCases
Test: cts -m CtsLibcoreWycheproofConscryptTestCases
Change-Id: Ie9e0cfa02ed14061a8d500b7412199d401a690df
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Preparation for splitting core-tests-support into two parts, one that
depends only on core_current and can be used outside libcore and one
that can depend on core-all directly.
Deletes a lot of classes that are no longer used. Some of the classes
were only used by external/conscrypt tests and it has its own copies of
them. Some of them were copied over from harmony and are not used in
libcore tests. Some of them have been extracted into
external/mockwebserver.
Moves some classes that are only used internally by a couple of luni
tests to am appropriate luni/src/test/java directory to reduce the
number of split packages.
Tightens up visibility in a couple of classes.
Removes some unused members from a couple of classes:
* support/src/test/java/libcore/java/security/StandardNames.java
* support/src/test/java/libcore/javax/net/ssl/SSLConfigurationAsserts.java
Bug: 117547194
Test: make checkbuild && \
atest CtsKeystoreTestCases CtsNetTestCases conscrypt-tests \
FrameworksCoreTests KeyChainTests time_zone_distro-tests \
CtsLibcoreTestCases
Change-Id: I8b258e66911ece69d4eaefef56810e17dddb2583
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- We forgot to update SharedSecrets from upstreaam to initialize
javaIOFileDescriptorAccess, or we didn't have a proper way to
replace the method Unsafe.ensureClassInitialized.
- Upstream ensures that the field javaIOFileDescriptorAccess is not null
by calling Unsafe.ensureClassInitialized(FileDescriptor.class).
But Unsafe.ensureClassInitialized isn't supported in Android. Use
Class.forName to initialize the FileDescriptor class.
Bug: 80495283
Test: Cherrypicked this CL onto the branch where the problem was occurring.
"./test/testrunner/testrunner.py --host -b --t 071-dexfile-map-clean --64"
The test fails before the change and is passing now.
Test: cts-tradefed run cts-dev -m CtsLibcoreTestCases -t libcore.sun.misc.SharedSecretsTest
Change-Id: I77aec40f9a82416666b3c57fdde7c642aa0f419e
|
| |
|
|
|
|
|
|
|
| |
Detected by Errorprone.
Bug: 73797534
Test: m javac-check RUN_ERROR_PRONE=true
Test: atest PKCS9AttributeTest
Change-Id: I3634069a8dc89299bef32ddc90d14892f883f13a
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The integration of OpenJDK 9 javac into the Android build system
requires non-libcore code to live in non-libcore packages, as
long as that code isn't considered part of the same module as
libcore at javac time.
This CL moves libcore test related classes out of such
packages; since libcore tests could already only test
public (as opposed to package private APIs), no change
other than the package name and imports is necessary.
Because many libcore tests already live below a top-level
package "libcore" (eg., the tests for java.util are in
libcore.java.util), this CL likewise prepends "libcore."
to the package names of affected classes. For classes
relating to libcore.* packages, this results in a package
name of the form "libcore.libcore.*".
Alternative considered but not pursued:
To compile the test classes without moving the out of a libcore
package, javac would need to consider them to be in the same
module as libcore. This would likely be possible via
javac --patch-module, but this has not been explored in detail
because:
- Most luni tests are already in a toplevel package libcore.*,
so this CL makes the test structure more consistent.
- Use of --patch-module would likely cause problems when running
tests under a runtime that implements the OpenJDK 9 module
system; for example, --patch-module cannot add exported
packages to the module, so any new packages added in tests
(such as the libcore.* packages of most existing luni tests)
would not be visible at test runtime.
- Having tests in different packages from code under tests makes
it more obvious (including to IDEs in which the code might be
edited as a single project) that these tests cannot access
package-private identifiers in the code under test.
Test: Treehugger
Test: "make cts" with EXPERIMENTAL_USE_OPENJDK9=true
passes with additional changes present locally
that have not yet been exported as CLs.
Test: CtsLibcoreTestCases
Bug: 68224249
Bug: 68932217 (tracks potential follow-up work)
Change-Id: Ib6b8e6f3bc87093bc219d2108e601163c6e334cd
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The first step in deprecating the BC implementations of algorithms that
are also provided by Conscrypt. This checks whether the app's target
API level is greater than a given threshold (currently O, but subject
to change later) and disallows access to those algorithms when true.
This limit only applies to requests from the system-created BC provider.
Apps can install their own provider, in which case they get the
implementations they requested.
This doesn't yet implement the deprecation for Cipher instances, since
the transformation scheme makes that more complicated.
The ultimate removal of these algorithms, once a sufficient deprecation
period has elapsed, is tracked in b/67761667.
Bug: 67626877
Test: cts -m CtsLibcoreTestCases
Test: cts -m CtsLibcoreOkHttpTestCases
Test: cts -m CtsLibcoreWycheproofBCTestCases
Test: cts -m CtsLibcoreWycheproofConscryptTestCases
Change-Id: I48f07226e66873a65859121af32028c1547952ac
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before this CL, that package was based on OpenJDK7u40. This CL
integrates the upstream changes up to 8u121-b13.
The following changes are noteworthy;
Bug fixes:
JarURLConnection: minor fix (no test added)
FtpURLConnection: fix for NPE when attempting to log in
with null password. A regression test is added.
Logic changes or reimplementations:
DefaultProxySelector: Changes around NoProxy hosts logic
- represent nphosts as Pattern rather than RegexpPool
- extract utility methods relating to that Pattern
- NoProxy configuration for SOCKS (defaults to no proxy for localhost addresses)
- No test was added for the SOCKS changes, since SOCKS proxy
logic overall is not currently covered by tests (bug 35867657).
IPAddressUtil: Reimplementation of textToNumericFormatV4()
- An Android change to the old version of that method was
replaced with a new change on top of the new implementation.
- The test that was added passes both before and after this CL.
New upstream code that is not used on Android and commented out:
URLUtil: Android doesn't support SecurityMAnager, so Permissions code
is unused.
Bug: 38027507
Test: CtsLibcoreTestCases
(cherry picked from commit a6d00d975886ca644d3e29c217cf4e8e0cf3b975)
Change-Id: I88ecfb9ccb250997b6263c45ccdea1d57603ba29
Merged-In: Iba69172b5e1912680c4c1a6be68070863dd35688
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before this CL, the package was still based on OpenJDK7u40. All of the
upstream changes integrated here were already present in OpenJDK8u60;
the only upstream changes between 8u60 and 8u121-13 related to timezone
data resource files, which are not used on Android (Android uses ICU).
Below,
[U] means that a change was integrated from upstream.
[L] means a local edit was made, e.g. to improve documentation of
existing Android changes.
[identical] means the file is identical to the upstream version,
after this CL.
The affected files were:
In sun.util.calendar:
BaseCalendar [identical]:
[U] drop unneeded import
CalendarDate [identical]:
[U]: pass cause to InternalError ctor during clone()
CalendarSystem
[L] improved formatting of Android-changed sections
[U] throw InternalError rather than RuntimeException
in case of Exception during calendarClass.newInstance()
(Shouldn't happen).
LocalGregorianCalendar:
[U] Add missing @Override annotations
[U] Drop unused imports
[U] Drop redundant generic type argument.
[LU] Adopt upstream implementation of getLocalGregorianCalendar().
Previously, the implementation was substantially different from
OpenJDK7u40, but the implementation in 8u121-b13 nearly exactly
matched what Android had.
The differences to previous Android versions are:
- Catch IllegalArgumentException, not just IOException,
when calling CalendarSystem.getCalendarProperties(), and
- throw InternalError rather than RuntimeException when
that fails.
This implementation in 8u121 was practically identical with what
Android had, allowing us to drop an Android change.
[L] Tweak an Android-changed comment.
In sun.util.locale:
BaseLocale [identical]:
[U] Adopt use of SoftReferences in Key.
See further below why this change is safe, but not obviously so.
InternalLocaleBuilder:
[L] Document the sole Android change from libcore commit
51b1b6997fd3f980076b8081f7f1165ccc2a4008 ("Initial import of
OpenJdk files") from Feb 2015 which first added this file.
The change is unexplained.
There were no upstream changes to this file between
OpenJDK7u40 and 8u121-b13.
LanguageTag [identical]:
[U]: Correct RFC number.
LocaleMatcher:
[L] document the places where the backport of JDK-8166994
(OpenJDK 9) has been applied. This change resulted
from a patch that was previously upstreamed to
OpenJDK. This documentation can be removed if/when
Android updates to OpenJDK 9, since that includes
this change.
LocaleObjectCache [identical]:
[U] fix createObject() to be called before rather than
after normalizeKey().
LocaleUtils [identical]:
[U] copyright year
LoggingProxy [identical]:
[U] copyright year
LoggingSupport [identical]
[U] copyright year
PlatformLogger:
[U] Remove (previously @Deprecated) isLoggable()/getLevel()/setLevel()
methods based on int values to identify the level.
[U] Make the int constants, representing log levels, private.
[L] Use /* .. */ rather than // to comment out a removed block;
This results in a small diff vs. upstream.
[U] Update the aforementioned block to the latest upstream version.
[L] document Android change in getCallerInfo where we have to
use throwable.getStackTrace() rather than
SharedSecrets.getJavaLangAccess().getStackTraceElement()
In sun.util.resources:
OpenListResourceBundle [identical]:
[U] narrow the scope of the synchronized block in loadLookup()
[U] add missing @Override annotations
[U] override keySet()
[U] Various API changes (public -> protected handleGetObject(),
handleGetKeys(); drop of getParent() override, addition
of createSet(), generic type arguments for createMap()).
Comments follow on why the adoption on SoftReference<String>s in
BaseLocale (and the change to LocaleObjectCache) appears correct but
not obviously so. This change was introduced by upstream commit
http://hg.openjdk.java.net/jdk9/client/jdk/rev/0fcff3336fee
Because investigation of whether this change is correct/safe and
its benefits took some time, these comments are fairly verbose:
- The only apparent benefit of these SoftReferences is that it avoids
holding on to (potentially large) String objects for "stale" Cache
entries. Cache entries are stale between the time the cached
(BaseLocale) value has been garbage collected and when the entire
entry is removed by LocaleObjectCache.cleanStaleEntries(), which
happens during Cache.get().
The Strings, e.g. from the Locale(String, String, String, String) ctor,
are typically short (this is the case for all Strings passed in in
the platform) so the four SoftReference objects appear to only be
an improvement if unusually large Strings are passed in by a misbehaved
application.
- The fact that normalizeKey() and createObject() do not need check
for whether the SoftReference<String>s have been cleared appears
correct but not obviously so:
- normalizeKey() and createObject() are only called from
LocaleObjectCache.get().
- Code in BaseLocale holds strong references to the String values
whenever it constructs Key objects to call LocaleObjectCache
with (guaranteeing that the String won't be garbage collected
during construction / interaction with the Cache).
- Specifically, BaseLocale.getInstance(String, String, String, String)
holds strong references while calling CACHE.get(), and
BaseLocale.createInstance(String, String) holds strong references
while calling CACHE.put() for a newly constructed Key object.
- normalizeKey() and createObject() could throw NPE if they were
called on a stale entry's Key, but the only way outside code
could get access to such a Key is through (unsafe) reflection.
- Likewise, the behavior of stale Cache entries is nontrivial:
- BaseLocale.Cache indirectly extends SoftReference<BaseLocale>.
The cache entry becomes stale when that SoftReference is cleared.
- BaseLocale has strong references to the same Strings as the Key,
so the earliest time the Key's SoftReference<String>s could be
cleared is when the entry becomes stale.
- While stale entries are never returned by the cache,
key.equals(obj) can still be called for them because other
(non-stale) keys in the LocaleObjectCache.map may have the
same hashCode.
- this is why, unlike normalizeKey() and createObject(),
Key.equals() *does* need to check whether the
SoftReference<String>s have been cleared.
- For keys whose SoftReference<String> has been cleared,
key.equals(obj) returns false for any obj other than themselves.
Such keys are deadweight, but will be removed from the cache during
cleanStaleEntries().
Bug: 37749191
Test: CtsLibcoreTestCases
Change-Id: Idfc63e0ee9bbc0a238ea1c124347f726b74058bc
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The upstream changes incorporate in the table of supported algorithms
for certificates the entries for AES and ECDH.
The entries for AES differ for what was being used by Android before
this change, as BouncyCastle permitted a wrong alias because of
backward compatibility, and we were scanning the aliases table.
Bug: 29631070
Test: vogar AlgorithmIdTest
Change-Id: Ib7de7c0710b8d1704b54aadc511c3a92a90f43d9
|
| |\
| |
| |
| | |
names"
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Before rev/f9224fb49890, the unstructuredName attributes supported only
IA5 strings. They support printable strings as well.
See https://bugs.openjdk.java.net/browse/JDK-8016916
Bug: 29631070
Test: run cts -m CtsLibcoreTestCases
Change-Id: I05c093b7701452d4e45edd8c4bd760d6207703a8
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The revision rev/5dc3f32c0d26 introduced changes to names of
algorithms in AlgorithmId
As a result, for the OID of SHA, it returns SHA-1 instead of SHA.
Note that SHA needed to be converted to SHA1 explicitly in code that
the revision deleted.
In N, for the algorithms whose name was hardcoded in the code
the name was returned without a hyphen (SHAXXX) while names obtained
by scanning the algorithms offered by providers were returned with
a hyphen (SHA-XXX). Now they are consistenly returned with a hyphen.
Change-Id: I43a85b72bc960c7868a121219cea3d3e4a3289b5
Bug: 29631070
Test: make CtsLibcoreTestCases
|
| |
|
|
|
|
|
|
|
|
|
| |
rev/3e3017eba8ac introduces support for SHA-224 and related
algorithms. The class AlgorithmId is used by the certpath
provider as to check that the certificates complain with
the algorithm constraints.
Test: run cts -m CtsLibcoreTestCases
Change-Id: Ic0cf2932969b57d0bbf1ae8ea8225a2e4fe31dba
Bug: 29631070
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Changes to KeyUsageExtension, NetscapeCerTypeExtension and
ReasonFlags as to check as to improve checks of array bounds.
sun.security.provider.certpath.DistributionPointFetcher has a
similar change concerning array bounds, where the opportunity
to improve probably was spotted by the fact that it uses
ReasonFlags.
Since in the classes in sun.security.x509 the logic for toString
changed slightly, tests are added that passed both before and
after the change, as to check that the outcome is the same.
Bug: 29631070
Test: run cts -m CtsLibcoreTestCases
Change-Id: I2a2c10c59509063e648f238f82ac71b4f513cd71
|
|
|
- Most APIs are currently unimplemented and will be filled in by
subsequent changes.
- This change includes basic tests for the APIs that are currently
implemented.
bug: 30550796
Test: make build-art-host, docs
Test: vogar MethodHandlesTestVerifyAccessTest
Change-Id: Idec3ee8072dc3a5f94b6fb7ddb08cbc25ed96693
|
