s3_both.c does a few too many things right now, but SSL_HANDSHAKE is not
only for TLS 1.3.
Change-Id: Ieac17c592a1271d4d5c9cee005eaf5642772b8f5
Reviewed-on: https://boringssl-review.googlesource.com/10443
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Also fix up those tests as they were a little confused. It is always the
shim that signs and has a configured certificate in these tests.
BUG=95
Change-Id: I57a6b1bad19986c79cd30aaa6cf3b8ca307ef8b2
Reviewed-on: https://boringssl-review.googlesource.com/10444
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
One less thing to keep track of.
https://github.com/tlswg/tls13-spec/pull/549 got merged.
Change-Id: Ide66e547140f8122a3b8013281be5215c11b6de0
Reviewed-on: https://boringssl-review.googlesource.com/10482
Reviewed-by: Steven Valdez <svaldez@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: Steven Valdez <svaldez@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
The TLS 1.3 state machine is actually less in need of the aggressive
state machine coverage tests, but nonetheless, we should cover all
handshake shapes. PSK resumption and HelloRetryRequest were missing.
We were also accidentally running "DTLS" versions of the TLS 1.3 tests
but silently running TLS 1.2.
Change-Id: I65db4052b89d770db7e47738e73aaadde9634236
Reviewed-on: https://boringssl-review.googlesource.com/10441
Reviewed-by: Nick Harper <nharper@chromium.org>
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Right now the logic happens twice which is a nuisance.
Change-Id: Ia8155ada0b4479b2ca4be06152b8cd99816e14e8
Reviewed-on: https://boringssl-review.googlesource.com/10440
Reviewed-by: Nick Harper <nharper@chromium.org>
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Some version mismatch cases were not being covered due to TLS 1.2 and
TLS 1.3 having very different spellings for tickets resumption. Also
explicitly test that TLS 1.2 tickets aren't offered in the TLS 1.3 slot
and vice versa.
Change-Id: Ibe58386ea2004fb3c1af19342b8d808f13f737a9
Reviewed-on: https://boringssl-review.googlesource.com/10183
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
BUG=75
Change-Id: Ied864cfccbc0e68d71c55c5ab563da27b7253463
Reviewed-on: https://boringssl-review.googlesource.com/9043
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Much of the ClientHello logic queries hello.vers. To avoid it getting
confused, do all modifications right at the end, otherwise
SendClientVersion also affects whether the key share is sent.
Change-Id: I8be2a4a9807ef9ad88af03971ea1c37e4ba36b9c
Reviewed-on: https://boringssl-review.googlesource.com/10341
Reviewed-by: Nick Harper <nharper@chromium.org>
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
In TLS 1.2 and below, the server is not supposed to echo it, but I just
came across a BigIP server which does. Document this so we know to take
care before trying to flip it in the future.
(It's actually kind of odd that it wasn't allowed to be sent given TLS
1.2 makes supported_groups interact with ECDSA client certificates. Ah
well.)
Change-Id: I4b97266f461e85bb1ad9bb935470e027f926d4df
Reviewed-on: https://boringssl-review.googlesource.com/10320
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
The server should not be allowed select a protocol that wasn't
advertised. Callers tend to not really notice and act as if some default
were chosen which is unlikely to work very well.
Change-Id: Ib6388db72f05386f854d275bab762ca79e8174e6
Reviewed-on: https://boringssl-review.googlesource.com/10284
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Since we are eliminating DHE support in TLS, this is just a waste of
bytes.
Change-Id: I3a23ece564e43f7e8874d1ec797def132ba59504
Reviewed-on: https://boringssl-review.googlesource.com/10260
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
These are probably a good idea to ship so long as we have the PSK
callbacks at all, but they're not *completely* standard yet and Android
tests otherwise need updating to know about them. We don't care enough
about PSK to be in a rush to ship them, and taking them out is an easier
default action until then.
Change-Id: Ic646053d29b69a114e2efea61d593d5e912bdcd0
Reviewed-on: https://boringssl-review.googlesource.com/10225
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
If cert_cb runs asynchronously, we end up repeating a large part of very
stateful ClientHello processing. This seems to be mostly fine and there
are few users of server-side cert_cb (it's a new API in 1.0.2), but it's
a little scary.
This is also visible to external consumers because some callbacks get
called multiple times. We especially should try to avoid that as there
is no guarantee that these callbacks are idempotent and give the same
answer each time.
Change-Id: I212b2325eae2cfca0fb423dace101e466c5e5d4e
Reviewed-on: https://boringssl-review.googlesource.com/10224
Commit-Queue: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Now that ssl_bytes_to_cipher_list is uninteresting, it can be an
implementation detail of ssl3_choose_cipher. This removes a tiny amount
of duplicated TLS 1.2 / TLS 1.3 code.
Change-Id: I116a6bb08bbc43da573d4b7b5626c556e1a7452d
Reviewed-on: https://boringssl-review.googlesource.com/10221
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
It's odd that a function like ssl_bytes_to_cipher_list secretly has side
effects all over the place. This removes the need for the TLS 1.3 code
to re-query the version range, and it removes the requirement that the
RI extension be first.
Change-Id: Ic9af549db3aaa8880f3c591b8a13ba9ae91d6a46
Reviewed-on: https://boringssl-review.googlesource.com/10220
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Between TLS 1.2, TLS 1.3, and the early callback, we've got a lot of
ClientHello parsers. Unify everything on the early callback's parser. As
a side effect, this means we can parse a ClientHello fairly succinctly
from any function which will let us split up ClientHello states where
appropriate.
Change-Id: I2359b75f80926cc7d827570cf33f93029b39e525
Reviewed-on: https://boringssl-review.googlesource.com/10184
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
This is more progress in letting other stacks use the test runner.
You can provide a per-shim configuration file that includes:
- A list of test patterns to be suppressed (presumably because
they don't work). This setting is ignored if -test is used.
- A translation table of expected errors to shim-specific errors.
BUG=92
Change-Id: I3c31d136e35c282e05d4919e18ba41d44ea9cf2a
Reviewed-on: https://boringssl-review.googlesource.com/9161
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
It was renamed to ticket_liftetime_hint in
1e6f11a7ff72bea394e6651b512e435fbc95d323, which breaks Qt.
Change-Id: I9c6d3097fe96e669f06a4e0880bd4d7d82b03ba8
Reviewed-on: https://boringssl-review.googlesource.com/10181
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
We handle this correctly but never wrote a test for it. Noticed this in
chatting about the second ClientHello.version bug workaround with Eric
Rescorla.
Change-Id: I09bc6c995d07c0f2c9936031b52c3c639ed3695e
Reviewed-on: https://boringssl-review.googlesource.com/9154
Reviewed-by: Steven Valdez <svaldez@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Only X509_up_ref left (it's still waiting on a few external callers).
BUG=89
Change-Id: Ia2aec2bb0a944356cb1ce29f3b58a26bdb8a9977
Reviewed-on: https://boringssl-review.googlesource.com/9141
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Inch towards OpenSSL 1.1.0 compatibility.
BUG=91
Change-Id: Ia45b6bdb5114d0891fdffdef0b5868920324ecec
Reviewed-on: https://boringssl-review.googlesource.com/9140
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
tls13_process_certificate can take a boolean for whether anonymous is
allowed. This does change the error on the client slightly, but I think
this is correct anyway. It is not a syntax error for the server to send
no certificates in so far as the Certificate message allows it. It's
just illegal.
Change-Id: I1af80dacf23f50aad0b1fbd884bc068a40714399
Reviewed-on: https://boringssl-review.googlesource.com/9072
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
We have tests for this as a server, but none as a client. Extend the
certificate verification tests here. This is in preparation for ensuring
that TLS 1.3 session resumption works correctly.
Change-Id: I9ab9f42838ffd69f73fbd877b0cdfaf31caea707
Reviewed-on: https://boringssl-review.googlesource.com/9111
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
No sense in having it in both the 1.2 and 1.3 code.
Change-Id: Ib3854714afed24253af7f4bcee26d25e95a10211
Reviewed-on: https://boringssl-review.googlesource.com/9071
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
While the sanity check isn't insane (one should arrange for sessions to
be invalidated once client auth settings change, and a sid_ctx is one
way to do it), this check lives in a poor place to enforce configuration
mistakes. To be effective, it needs to happen at the start of the
handshake, independent of the ClientHello from the peer.
But the benefit this check gives is low compared to the trouble it will
be to continually maintain this difference from OpenSSL (our own
ssl_test and bssl_shim forget to set a dummy sid_ctx). Instead, remove
it so we don't have to duplicate it across TLS 1.2 and TLS 1.3. Also so
we don't have weird failures which only manifest once a resuming client
connects.
Change-Id: Ia7f88711701afde5e26b7782c2264ce78dccc89b
Reviewed-on: https://boringssl-review.googlesource.com/9112
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Extend the DTLS mock clock to apply to sessions too and test that
resumption behaves as expected.
Change-Id: Ib8fdec91b36e11cfa032872b63cf589f93b3da13
Reviewed-on: https://boringssl-review.googlesource.com/9110
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
We almost forgot to handle this in TLS 1.3, so add a test for it.
Change-Id: I28600325d8fb6c09365e909db607cbace12ecac7
Reviewed-on: https://boringssl-review.googlesource.com/9093
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
We broke this to varying degrees ages ago.
This is the logic to implement the variations of rules in TLS to discard
sessions after a failed connection, where a failed connection could be
one of:
- A connection that was not cleanly shut down.
- A connection that received a fatal alert.
The first one is nonsense since close_notify does not actually work in
the real world. The second is a vaguely more plausible but...
- A stateless ticket-based server can't drop sessions anyway.
- In TLS 1.3, a client may receive many tickets over the lifetime of a
single connection. With an external session cache like ours which may,
in theory, but multithreaded, this will be a huge hassle to track.
- A client may well attempt to establish a connection and reuse the
session before we receive the fatal alert, so any application state we
hope to manage won't really work.
- An attacker can always close the connection before the fatal alert, so
whatever security policy clearing the session gave is easily
bypassable.
Implementation-wise, this has basically never worked. The
ssl_clear_bad_session logic called into SSL_CTX_remove_session which
relied on the internal session cache. (Sessions not in the internal
session cache don't get removed.) The internal session cache was only
useful for a server, where tickets prevent this mechanism from doing
anything. For a client, we since removed the internal session cache, so
nothing got removed. The API for a client also did not work as it gave
the SSL_SESSION, not the SSL, so a consumer would not know the key to
invalidate anyway.
The recent session state splitting change further broke this.
Moreover, calling into SSL_CTX_remove_session logic like that is
extremely dubious because it mutates the not_resumable flag on the
SSL_SESSION which isn't thread-safe.
Spec-wise, TLS 1.3 has downgraded the MUST to a SHOULD.
Given all that mess, just remove this code. It is no longer necessary to
call SSL_shutdown just to make session caching work.
Change-Id: Ib601937bfc5f6b40436941e1c86566906bb3165d
Reviewed-on: https://boringssl-review.googlesource.com/9091
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Save a little bit of typing at the call site.
Change-Id: I818535409b57a694e5e0ea0e9741d89f2be89375
Reviewed-on: https://boringssl-review.googlesource.com/9090
Reviewed-by: Adam Langley <agl@google.com>
We will now send tickets as a server and accept them as a
client. Correctly offering and resuming them in the handshake will be
implemented in a follow-up.
Now that we're actually processing draft 14 tickets, bump the draft
version.
Change-Id: I304320a29c4ffe564fa9c00642a4ace96ff8d871
Reviewed-on: https://boringssl-review.googlesource.com/8982
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
As of https://github.com/tlswg/tls13-spec/pull/530, they're gone.
They're still allowed just before the ClientHello or ServerHello, which
is kind of odd, but so it goes.
BUG=86
Change-Id: I3d556ab45e42d0755d23566e006c0db9af35b7b6
Reviewed-on: https://boringssl-review.googlesource.com/9114
Reviewed-by: Steven Valdez <svaldez@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Change-Id: Id6a7443246479c62cbe0024e2131a2013959e21e
Reviewed-on: https://boringssl-review.googlesource.com/9078
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Change-Id: I057e19a9547a14b3950395db4318eaf0da01ec13
Reviewed-on: https://boringssl-review.googlesource.com/9079
Reviewed-by: Steven Valdez <svaldez@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
OpenSSL 1.1.0 added a function to tell if an SSL* is DTLS or not. This
is probably a good idea, especially since SSL_version returns
non-normalized versions.
BUG=91
Change-Id: I25c6cf08b2ebabf0c610c74691de103399f729bc
Reviewed-on: https://boringssl-review.googlesource.com/9077
Reviewed-by: Steven Valdez <svaldez@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
None of the SSL_VERIFY_FAIL_IF_NO_PEER_CERT codepaths will ever be
reached if SSL_VERIFY_PEER is unset. If we've gotten as far as getting a
Certificate message, consider SSL_VERIFY_FAIL_IF_NO_PEER_CERT alone
significant grounds for rejecting no peer certificate.
Change-Id: I2c6be4269d65b2467b86b1fc7d76ac47ca735553
Reviewed-on: https://boringssl-review.googlesource.com/9070
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Change-Id: I998f69269cdf813da19ccccc208b476f3501c8c4
Reviewed-on: https://boringssl-review.googlesource.com/8991
Reviewed-by: Steven Valdez <svaldez@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
We'll need to update it on occasion, but we should not update our
default ClientHello without noticing.
Change-Id: I19ca52fdbe10e3ac14413fecd16be2e58af5a1f6
Reviewed-on: https://boringssl-review.googlesource.com/9075
Reviewed-by: Steven Valdez <svaldez@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Where we can move uncommon logic to the caller, we probably ought to.
Change-Id: I54a09fffffc20290be05295137ccb605d562cad0
Reviewed-on: https://boringssl-review.googlesource.com/9069
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
SSL_set_bio is a nightmare.
In f715c423224a292d79ba0e3df373c828fbae29f7, we noticed that, among
other problems, SSL_set_bio's actual behavior did not match how
SSL_set_rfd was calling it due to an asymmetry in the rbio/wbio
handling. This resulted in SSL_set_fd/SSL_set_rfd calls to crash. We
decided that SSL_set_rfd's believed semantics were definitive and
changed SSL_set_bio.
Upstream, in 65e2d672548e7c4bcb28f1c5c835362830b1745b, decided that
SSL_set_bio's behavior, asymmetry and all, was definitive and that the
SSL_set_rfd crash was a bug in SSL_set_rfd. Accordingly, they switched
the fd callers to use the side-specific setters, new in 1.1.0.
Align with upstream's behavior and add tests for all of SSL_set_bio's
insanity. Also export the new side-specific setters in anticipation of
wanting to be mostly compatible with OpenSSL 1.1.0.
Change-Id: Iceac9508711f79750a3cc2ded081b2bb2cbf54d8
Reviewed-on: https://boringssl-review.googlesource.com/9064
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Change-Id: Idf9db184348140972e57b2a8fa30dc9cb8b2e0f2
Reviewed-on: https://boringssl-review.googlesource.com/9065
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
In TLS 1.2, this was allowed to be empty for the weird SHA-1 fallback
logic. In TLS 1.3, not only is the fallback logic gone, but omitting
them is a syntactic error.
struct {
opaque certificate_request_context<0..2^8-1>;
SignatureScheme
supported_signature_algorithms<2..2^16-2>;
DistinguishedName certificate_authorities<0..2^16-1>;
CertificateExtension certificate_extensions<0..2^16-1>;
} CertificateRequest;
Thanks to Eric Rescorla for pointing this out.
Change-Id: I4991e59bc4647bb665aaf920ed4836191cea3a5a
Reviewed-on: https://boringssl-review.googlesource.com/9062
Reviewed-by: Steven Valdez <svaldez@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
We were sending decode_error, but the spec explicitly says (RFC 5246):
unsupported_extension
sent by clients that receive an extended server hello containing
an extension that they did not put in the corresponding client
hello. This message is always fatal.
Also add a test for this when it's a known but unoffered extension. We
actually end up putting these in different codepaths now due to the
custom extensions stuff.
Thanks to Eric Rescorla for pointing this out.
Change-Id: If6c8033d4cfe69ef8af5678b873b25e0dbadfc4f
Reviewed-on: https://boringssl-review.googlesource.com/9061
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
It seems much safer for the default value of |verify_result| to be an
error value.
Change-Id: I372ec19c41d77516ed12d0169969994f7d23ed70
Reviewed-on: https://boringssl-review.googlesource.com/9063
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
We managed to mix two comment styles in the Go license headers and
copy-and-paste it throughout the project.
Change-Id: Iec1611002a795368b478e1cae0b53127782210b1
Reviewed-on: https://boringssl-review.googlesource.com/9060
Reviewed-by: Steven Valdez <svaldez@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
BUG=74
Change-Id: I72d52c1fbc3413e940dddbc0b20c7f22459da693
Reviewed-on: https://boringssl-review.googlesource.com/8981
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
David Benjamin
Steven Valdez
EKR
Adam Langley
Martin Kreichgauer
Nick Harper