GitLab

cd libcore/luni/src/main/files
git rm cacerts/c0cafbd2.0
./certimport.sh

Bug: 5232736
Change-Id: I455a7c72a6d08cd0556fd4a64bb195e9e97dbfc0

Change-Id: I9a018ca88373d5f317335e35fc6ca43c5473490e
http://b/4188137

X509CertImpl instances can be shared between threads without a caller
knowing due to the CERT_CACHE in X509CertFactoryImpl. In some cases,
initialization of pairs of fields such as notBefore/notAfter and
sigAlgOID/sigAlgName were protected by checking if only was one of the
two values were initialized. This could lead to one thread half
initializing a pair and a second thread seeing the half initialized
pair, would assume both halves were initialized, returning an
uninitialized value. Even in the lazy initialization of single fields
there was no use of volatile or synchonized to be properly safe.

git cherry-pick -e ef6370c1
http://code.google.com/p/android/issues/detail?id=11870
Bug: 2295023

Change-Id: I82ff6e2742b3562e06fe3988dff1071b8ef5e82b

A device may not support any specific locale (i.e. China, German, etc,.)

Change-Id: I894bfc76d3503d879913ff33a2b5e8887ea2ca49

This was cherry-picked back from Honeycomb 41e32e5a

sslSelect had a comment explaining why its blocking read from a pipe
would never block. However, there is repeatable evidence to the
contrary. Attaching gdb to a process with SSLSocket blocked in both
read and write showed that the writer was waiting in sslSelect trying
to acquire the AppData::mutex while the reader was holding the mutex
and blocked in read(2).

This change makes the file descriptor of the pipe non-blocking.
Callers of sslSelect select already repeat their attempt to handshake,
read, or write as necessary when waking up from select, so now if the
code is woken up by the pipe, it continues regardless of the read
status.

Bug: 3332268
Change-Id: I75fb094e168d89a8e2752a6e12ee79f9adadc013

In both the write and flush we were looping writing data from the
Deflater to the OutputStream until we needsInput was true. However, we
should have simply been looping until there were no bytes returned.

Bug: 4005091
Change-Id: I995ef0eeb3d3c500144f33456b5b2d15d374efcb

Added and removed expired CAs in cacerts directory with summary below.
Regenerated cacerts.bks

Remove   SHA1      : 9F:C7:96:E8:F8:52:4F:86:3A:E1:49:6D:38:12:42:10:5F:1B:78:F5
         Subject   : C=DE, ST=Hamburg, L=Hamburg, O=TC TrustCenter for Security in Data Networks GmbH, OU=TC TrustCenter Class 3 CA/emailAddress=certificate@trustcenter.de

Remove   SHA1      : 83:8E:30:F7:7F:DD:14:AA:38:5E:D1:45:00:9C:0E:22:36:49:4F:AA
         Subject   : C=DE, ST=Hamburg, L=Hamburg, O=TC TrustCenter for Security in Data Networks GmbH, OU=TC TrustCenter Class 2 CA/emailAddress=certificate@trustcenter.de

Added    SHA1      : 4A:BD:EE:EC:95:0D:35:9C:89:AE:C7:52:A1:2C:5B:29:F6:D6:AA:0C
         Subject   : C=EU, L=Madrid (see current address at www.camerfirma.com/address)/serialNumber=A82743287, O=AC Camerfirma S.A., CN=Global Chambersign Root - 2008

Added    SHA1      : 03:9E:ED:B8:0B:E7:A0:3C:69:53:89:3B:20:D2:D9:32:3A:4C:2A:FD
         Subject   : C=US, O=GeoTrust Inc., OU=(c) 2008 GeoTrust Inc. - For authorized use only, CN=GeoTrust Primary Certification Authority - G3

Added    SHA1      : 59:AF:82:79:91:86:C7:B4:75:07:CB:CF:03:57:46:EB:04:DD:B7:16
         Subject   : C=NL, O=Staat der Nederlanden, CN=Staat der Nederlanden Root CA - G2

Added    SHA1      : DD:E1:D2:A9:01:80:2E:1D:87:5E:84:B3:80:7E:4B:B1:FD:99:41:34
         Subject   : C=TR, O=Elektronik Bilgi Guvenligi A.S., CN=e-Guven Kok Elektronik Sertifika Hizmet Saglayicisi

Added    SHA1      : F1:8B:53:8D:1B:E9:03:B6:A6:F0:56:43:5B:17:15:89:CA:F3:6B:F2
         Subject   : C=US, O=thawte, Inc., OU=Certification Services Division, OU=(c) 2008 thawte, Inc. - For authorized use only, CN=thawte Primary Root CA - G3

Added    SHA1      : AE:C5:FB:3F:C8:E1:BF:C4:E5:4F:03:07:5A:9A:E8:00:B7:F7:B6:FA
         Subject   : C=ES, CN=Autoridad de Certificacion Firmaprofesional CIF A62634068

Added    SHA1      : E0:B4:32:2E:B2:F6:A5:68:B6:54:53:84:48:18:4A:50:36:87:43:84
         Subject   : CN=ACEDICOM Root, OU=PKI, O=EDICOM, C=ES

Added    SHA1      : FA:B7:EE:36:97:26:62:FB:2D:B0:2A:F6:BF:03:FD:E8:7C:4B:2F:9B
         Subject   : C=RO, O=certSIGN, OU=certSIGN ROOT CA

Added    SHA1      : 67:65:0D:F1:7E:8E:7E:5B:82:40:A4:F4:56:4B:CF:E2:3D:69:C6:F0
         Subject   : C=TW, O=Chunghwa Telecom Co., Ltd., OU=ePKI Root Certification Authority

Added    SHA1      : 89:DF:74:FE:5C:F4:0F:4A:80:F9:E3:37:7D:54:DA:91:E1:01:31:8E
         Subject   : C=HU, L=Budapest, O=Microsec Ltd., CN=Microsec e-Szigno Root CA 2009/emailAddress=info@e-szigno.hu

Added    SHA1      : 06:08:3F:59:3F:15:A1:04:A0:69:A4:6B:A9:03:D0:06:B7:97:09:91
         Subject   : C=HU, L=Budapest, O=NetLock Kft., OU=Tan\xC3\xBAs\xC3\xADtv\xC3\xA1nykiad\xC3\xB3k (Certification Services), CN=NetLock Arany (Class Gold) F\xC5\x91tan\xC3\xBAs\xC3\xADtv\xC3\xA1ny

Added    SHA1      : D6:DA:A8:20:8D:09:D2:15:4D:24:B5:2F:CB:34:6E:B2:58:B2:8A:58
         Subject   : C=HK, O=Hongkong Post, CN=Hongkong Post Root CA 1

Added    SHA1      : 61:57:3A:11:DF:0E:D8:7E:D5:92:65:22:EA:D0:56:D7:44:B3:23:71
         Subject   : C=NO, O=Buypass AS-983163327, CN=Buypass Class 3 CA 1

Added    SHA1      : 40:9D:4B:D9:17:B5:5C:27:B6:9B:64:CB:98:22:44:0D:CD:09:B8:89
         Subject   : emailAddress=pki@sk.ee, C=EE, O=AS Sertifitseerimiskeskus, CN=Juur-SK

Added    SHA1      : 3B:C4:9F:48:F8:F3:73:A0:9C:1E:BD:F8:5B:B1:C3:65:C7:D8:11:B3
         Subject   : C=JP, O=Japan Certification Services, Inc., CN=SecureSign RootCA11

Added    SHA1      : 7F:8A:B0:CF:D0:51:87:6A:66:F3:36:0F:47:C8:8D:8C:D3:35:FC:74
         Subject   : C=JP, O=Japanese Government, OU=ApplicationCA

Added    SHA1      : 36:79:CA:35:66:87:72:30:4D:30:A5:FB:87:3B:0F:A7:7B:B7:0D:54
         Subject   : C=US, O=VeriSign, Inc., OU=VeriSign Trust Network, OU=(c) 2008 VeriSign, Inc. - For authorized use only, CN=VeriSign Universal Root Certification Authority

Added    SHA1      : 8B:AF:4C:9B:1D:F0:2A:92:F7:DA:12:8E:B9:1B:AC:F4:98:60:4B:6F
         Subject   : C=CN, O=CNNIC, CN=CNNIC ROOT

Added    SHA1      : 8C:96:BA:EB:DD:2B:07:07:48:EE:30:32:66:A0:F3:98:6E:7C:AE:58
         Subject   : CN=EBG Elektronik Sertifika Hizmet Sa\xC4\x9Flay\xC4\xB1c\xC4\xB1s\xC4\xB1, O=EBG Bili\xC5\x9Fim Teknolojileri ve Hizmetleri A.\xC5\x9E., C=TR

Added    SHA1      : 2A:C8:D5:8B:57:CE:BF:2F:49:AF:F2:FC:76:8F:51:14:62:90:7A:41
         Subject   : C=SK, L=Bratislava, O=Disig a.s., CN=CA Disig

Added    SHA1      : 1B:4B:39:61:26:27:6B:64:91:A2:68:6D:D7:02:43:21:2D:1F:1D:96
         Subject   : C=TR, L=Gebze - Kocaeli, O=T\xC3\xBCrkiye Bilimsel ve Teknolojik Ara\xC5\x9Ft\xC4\xB1rma Kurumu - T\xC3\x9CB\xC4\xB0TAK, OU=Ulusal Elektronik ve Kriptoloji Ara\xC5\x9Ft\xC4\xB1rma Enstit\xC3\xBCs\xC3\xBC - UEKAE, OU=Kamu Sertifikasyon Merkezi, CN=T\xC3\x9CB\xC4\xB0TAK UEKAE K\xC3\xB6k Sertifika Hizmet Sa\xC4\x9Flay\xC4\xB1c\xC4\xB1s\xC4\xB1 - S\xC3\xBCr\xC3\xBCm 3

Added    SHA1      : 78:6A:74:AC:76:AB:14:7F:9C:6A:30:50:BA:9E:A8:7E:FE:9A:CE:3C
         Subject   : C=EU, L=Madrid (see current address at www.camerfirma.com/address)/serialNumber=A82743287, O=AC Camerfirma S.A., CN=Chambers of Commerce Root - 2008

Added    SHA1      : A0:A1:AB:90:C9:FC:84:7B:3B:12:61:E8:97:7D:5F:D3:22:61:D3:CC
         Subject   : C=NO, O=Buypass AS-983163327, CN=Buypass Class 2 CA 1

Added    SHA1      : F9:B5:B6:32:45:5F:9C:BE:EC:57:5F:80:DC:E9:6E:2C:C7:B2:78:B7
         Subject   : C=US, O=AffirmTrust, CN=AffirmTrust Commercial

Added    SHA1      : 29:36:21:02:8B:20:ED:02:F5:66:C5:32:D1:D6:ED:90:9F:45:00:2F
         Subject   : C=US, O=AffirmTrust, CN=AffirmTrust Networking

Added    SHA1      : D8:A6:33:2C:E0:03:6F:B1:85:F6:63:4F:7D:6A:06:65:26:32:28:27
         Subject   : C=US, O=AffirmTrust, CN=AffirmTrust Premium

Bug: 3469985
Change-Id: I963e790cbc042bb19a2ef41858526e823cd6b0ba

Bug: 3405962
Bug: 3350645
git cherry-pick -e 1c64b3ad

Change-Id: Ic1a1a046e6fa359fe29f4cee71a8591aad43988d

Change-Id: I629fb99e0ed1d8e39892543792830b2c4b57ae1f

Change-Id: I8f251d2b1d7e2b5454c0702ae5cd836ca5507106

Change-Id: I17ffa62ca632ff1cbcdd0847c97ce539877e8667

Change-Id: I08acbd0053308fc4d3452b039532f49e138a1529

Change-Id: I8f251d2b1d7e2b5454c0702ae5cd836ca5507106

Change-Id: I17ffa62ca632ff1cbcdd0847c97ce539877e8667

I accidentally changed unsigned division to signed division here in gingerbread.

Bug: 3238333
Change-Id: I72cb80adbfc12082a222310929c90f8740b568da

Change-Id: I6c9ec10a8b37170173eb19be928f19119aef997c

Random's javadoc was pretty random, and Pattern was missing some escaping
in code samples.

Also work round droiddoc bugs that were messing up Formatter and classes
that inherited documentation from Object.

Bug: http://code.google.com/p/android/issues/detail?id=13264
Bug: 3318601
Change-Id: Iddb0c807398840191ee003bc1644d611aef4d61d

Change-Id: I432c3e402ff6a97651959891a8581be229c4b958

We should use LOCAL_PRELINK_MODULE instead.

Change-Id: I0a3056e839da5b2373e2fac89d69b1b9e9b0c853

Summary:

In 2.3, HttpsURLConnection was change to retry TLS connections as SSL
connections w/o compression to deal with servers that are TLS
intolerant. However, if the handshake proceeded to the point of
invoking the X509TrustManager, we should not retry. Similarly, if we
should not invoke the HostnameVerifier repeatedly, and need to wait
until the SSL handshake has completed.

Tested with (includes two new tests for this issue):
	libcore/luni/src/test/java/libcore/javax/net/ssl/
	libcore/luni/src/test/java/libcore/java/net/URLConnectionTest.java
	libcore/luni/src/test/java/org/apache/harmony/luni/tests/internal/net/www/protocol/https/HttpsURLConnectionTest.java

Details:

    HttpConnection.setupSecureSocket has been broken into two
    pieces. setupSecureSocket now just does the SSL
    handshaking. verifySecureSocketHostname now does the
    verification. The old HttpConnection code was careful never to
    assign its sslSocket field until verification was complete. A new
    unverifiedSocket field is added to store the sslSocket before
    verification is completed by verifySecureSocketHostname.

	luni/src/main/java/org/apache/harmony/luni/internal/net/www/protocol/http/HttpConnection.java

    HttpsEngine.makeConnection now skips TLS intolerant retry if the
    reason for the makeSslConnection failure was a
    CertificateException, since that implies that we failed during
    certification validation after initial handshaking. We also
    prevent retrying hostname verification by moving it out of
    makeSslConnection and only doing it on new SSL connections,
    tracking the changes to HttpConnection.setupSecureSocket mentioned
    above. We also now skip the redundant call to setUpTransportIO in
    makeSslConnection on reused SSLSockets.

	luni/src/main/java/org/apache/harmony/luni/internal/net/www/protocol/https/HttpsURLConnectionImpl.java

    Instead of throwing away the underlying CertificateExceptions, set
    them as the cause of the SSLExceptions. This is what the RI does
    in the case of X509TrustManager failures and is now used by
    HttpsEngine.makeConnection.

	luni/src/main/java/org/apache/harmony/xnet/provider/jsse/OpenSSLSessionImpl.java
	luni/src/main/java/org/apache/harmony/xnet/provider/jsse/OpenSSLSocketImpl.java

    Added new testConnectViaHttpsToUntrustedServer which makes sure
    that connections are not retried on certificate verification
    failure.

	luni/src/test/java/libcore/java/net/URLConnectionTest.java

    Added new test_SSLSocket_untrustedServer that verifies that an
    SSLHandshakeException is thown containing a CertificateException
    is thrown on certificate verification problems.

	luni/src/test/java/libcore/javax/net/ssl/SSLSocketTest.java

    Added second test CA and a new TestKeyStore.getClientCA2 test key
    store that does not trust the primary test key stores. This is
    useful for negative testing and is used in the above two new
    tests.

	support/src/test/java/libcore/java/security/TestKeyStore.java

Issue: http://code.google.com/p/android/issues/detail?id=13178
Bug: 3292412

Change-Id: I37136bb65f04d2bceaf2f32f542d6432c8b76ad4

Change-Id: I4c2ed726d41d6b55e27a503467a412fa05242383
http://b/3172197

Fixed CopyOnWriteArrayList problems:
- addAll() doesn't return true if the collection is empty
- clear() fails on an empty list
- containsAll() doesn't return true if the collection is empty
- subList() fails on an empty range
- subList() doesn't implement equals(), hashCode() or toString()

Fixed CopyOnWriteArraySet problems:
- addAll() adds duplicates if the added collection contains duplicates
- equals() throws NullPointerException if this is empty

The following issues aren't fixed:
- the iterator throws UnsupportedOperationException when it should throw
  IllegalStateException
- sublists don't reflect non-structural changes in the underlying list

http://b/3270784
Change-Id: I8c174e4ceda1ff964e2ad8224fa7338dac552288

This has been causing trouble for Gmail. The original fix cleaned up large
parts of the java.util.zip code; this just contains the active ingredient.

(I've excluded the error-handling change to this same function because
that hasn't been tested in the real world yet.)

Bug: 3220923
Change-Id: Ib4bc585a45061ef55c29f09f2bd650c772aab64d

Already committed to master as change 78504.

Change-Id: Ib883e92bb03b142f34449ef1314c57878dcc00f0

http://b/3169861

    Add public getSecureSocket so that HttpsURLConnection can reset its sslSocket field on reused connections.

        luni/src/main/java/org/apache/harmony/luni/internal/net/www/protocol/http/HttpConnection.java

    discardIntermediateResponse now maintain old values for
    intermediateReponse, which is necessary when retrying the CONNECT
    method with proxy authorization.

        luni/src/main/java/org/apache/harmony/luni/internal/net/www/protocol/http/HttpURLConnectionImpl.java

    Clear sslSocket before retrying makeSslConnection to ensure we reconnect.
    makeSslConnection now resets sslSocket on resumed connection.
    makeSslConnection now exits early on existing connection.

        luni/src/main/java/org/apache/harmony/luni/internal/net/www/protocol/https/HttpsURLConnectionImpl.java

git cherry-pick -e 4df5be29
Bug: 3184701
Change-Id: Ida3c027f79e5e29968263ac761d4f4f79d063a27

Rewrote HttpsURLConnectionTest to work with current SSLSocket
implementation which more strictly follows RI behavior.

Also made upates to URLConnectionTest related to HttpsURLConnection
- changed assertContent call connect() explictly to illustrate problem
  with https proxy case also seen by HttpsURLConnectionTest
- Rewrote testConnectTimeouts to work reliably. Before if often
  worked on WiFi but not on mobile networks where a "HTTP/1.1 501 Bad
  Gateway" would be seen causing a FileNotFoundException.
- Changed testConnectViaHttpProxyToHttpsUsingHttpProxySystemProperty
  to match expectation that https does not use the http.proxyHost
  values. Added new testConnectViaHttpProxyToHttpsUsingProxyArgWithNoProxy
  which should have the same behavior as the fixed
  testConnectViaHttpProxyToHttpsUsingHttpProxySystemProperty

git cherry-pick -e f02c695e

Bug: 3184701
Change-Id: Id25f619d2437db607deaf35aeb1d5e817514b92f

There can be a pending exception in the cert_client_cb if the server
certificate failed verification and the server requested a client
certificate. Since the handshake is going to be terminated, just
return from client_cert_cb immediately indicating no client cert will be
provided, allowing the existing exception to propagate.

Bug: 3149826
git cherry-pick 30a77f31

Bug: 3184701
Change-Id: I58b038267f66d6b5f80e9f3d81ff1c0f8052ef27

Change-Id: Idfb25df214cfeeb32b32d7cdb046954511cf755d
http://b/3171231

Change-Id: Icd07496c4d1371215a2153198d45d6aa719b26b7

The previous change:

    commit 5f2e6872
    Author: Brian Carlstrom <bdc@google.com>
    Date:   Mon Aug 23 14:06:51 2010 -0700

    SSLSocket.read should throw SocketException not NullPointerException

added checkOpen() to throw SocketException instead of
NullPointerException, but there was still a race between read/write on
one thread and close on another that could allow a
NullPointerException to escape. This change moves checkOpen() calls to
be protected by the existing writeLock/readLock/handshakeLock
synchronzied blocks to avoid this case.

byte buffer error checking for read/write is also moved into the to
lock region to preserve compatability as measured by the test:
    libcore.javax.net.ssl.SSLSocketTest#test_SSLSocket_close

Bug: 3153162

Change-Id: Ifef2b25500474f7e3b18ff97e7831717f2c9b391

Use the Apache Harmony version.

Change-Id: I5b9d6fac10dcaf20e16fccb73cfc2ae7110a683d