4831c3328c
Current thought is to organize this by: - Core SSL_CTX APIs (creating, destroying) - Core SSL APIs (creating destroying, maybe handshake, read, write as well) - APIs to configure SSL_CTX/SSL, roughly grouped by feature. Probably options and modes are the first two sections. SSL_TXT_* constants can be part of documenting cipher suite configuration. - APIs to query state from SSL_CTX/SSL, roughly grouped by feature. (Or perhaps these should be folded into the configuration sections?) The functions themselves aren't reordered or reorganized to match the eventual header order yet. Though I did do the s -> ssl rename on the ones I've touched. Also formally deprecate SSL_clear. It would be a core SSL API except it's horrible. Change-Id: Ia7e4fdcb7bad4e9ccdee8cf8c3136dc63aaaa772 Reviewed-on: https://boringssl-review.googlesource.com/4784 Reviewed-by: Adam Langley <agl@google.com> |
||
---|---|---|
.. | ||
pqueue | ||
test | ||
CMakeLists.txt | ||
d1_both.c | ||
d1_clnt.c | ||
d1_lib.c | ||
d1_meth.c | ||
d1_pkt.c | ||
d1_srtp.c | ||
d1_srvr.c | ||
internal.h | ||
s3_both.c | ||
s3_clnt.c | ||
s3_enc.c | ||
s3_lib.c | ||
s3_meth.c | ||
s3_pkt.c | ||
s3_srvr.c | ||
ssl_algs.c | ||
ssl_asn1.c | ||
ssl_cert.c | ||
ssl_cipher.c | ||
ssl_lib.c | ||
ssl_rsa.c | ||
ssl_sess.c | ||
ssl_stat.c | ||
ssl_test.cc | ||
ssl_txt.c | ||
t1_enc.c | ||
t1_lib.c | ||
t1_reneg.c |