(cherry picked from commit a76b9fc73cdd06bf40ab5181b1593975aef1dcd2)

  The base class mainly assigns GTlsConnection and GDtlsConnection
  vfuncs, checks whether handshake is complete and passes the data
  to the low-level TLS backend implementation via own vfunc

  The implementation supports tls-unique, server-end-point and
  experimental proposed tls-exporter binding type.

  The implementation supports tls-unique, server-end-point and
  experimental proposed tls-exporter binding type.

      * Test units verify if both client and server binding data matches.
      * Test units require Glib-2.0 version 2.65.1 hence bump the dependency

We should use test asserts instead.

Fixes #137

(cherry picked from commit ef578948d98f15965c3d927862c6b87d90bb4c73)

RSA-1024 is now blocked by Fedora 33 system policy.

This exposes an embarassing mistake. Browsers blocked RSA-1024 five
years ago. It is surprising that it was not blocked before now.

SHA-1 is still allowed for certificates that are trust roots, but it is
NOT allowed for the "alternative" CA certificate sent in the chain,
because that alternative certificate is not a trust root, even though it
has the same public key as a trust root. So we can no longer use SHA-1
in ca-alternative.pem, though it's still allowed in ca.pem. Both
certificates are constructed from the same .conf, so we either need to
use separate .conf or change them both. Changing them both is easier. We
have no compelling reason to test whether SHA-1 is allowed on trust
roots here; we can expect GnuTLS and OpenSSL to do that in their
testsuites.

Interestingly, only GnuTLS rejects SHA-1 on the alternative CA
certificate with F33 crypto policy. OpenSSL allows it. I guess the
OpenSSL behavior seems reasonable, because there should be no security
risk to allowing SHA-1 signatures for a certificate that has the same
public key as a trust root. If the owner of the corresponding private
key is not trusted, then it should not have any certificates installed
as trust roots.

Fixes #140

We no longer need to allow legacy crypto.

Previously, the cipher list was set as "HIGH:!DSS:!aNULL@STRENGTH" by
default.  This made the OpenSSL backend to not follow the system-wide
crypto policies in systems like Fedora or RHEL.

With this change, the cipher list is only set when the environment
variable G_TLS_OPENSSL_CIPHER_LIST is specified.

Fixes #106

Signed-off-by: Anderson Toshiyuki Sasaki <ansasaki@redhat.com>

Found by coverity

Found by coverity

This is slow. Don't misconfigure your server by failing to include
required certificates if you don't want your website to be slow.

Note that since we're already on a dedicated handshake thread if called
from GTlsConnection, we can do sync I/O throughout, no worries.

Fixes #96

This reverts commit d90b93a8.

- Use Fedora 33 as Rawhide is currently broken
- Build glib 2.67 (master currently)
- Add opensc for pkcs11-spy module

It has leaks that we don't care about

This was hard. The problem was that the mock PKCS#11 module accepts only
a single PKCS#11 session at a time. The test normally creates one
session, closes it, creates another, and closes it. But sometimes the
first session doesn't get closed before the second is created, and the
test breaks. The problem is that the PKCS#11 session is created and
closed by the GTlsClientConnection. The test creates two, and unrefs the
first one before creating the second, but other refs are held by the
first connection's GTasks. These GTasks complete in idle callbacks, and
if one idle fails to run before we finish iterating the main loop, the
first GTlsClientConnection won't be destroyed and so the first PKCS#11
session won't be closed in time. Note there is no bug in the
implementation, and nothing is leaked; rather, it's just not destroyed
soon enough for the test.

Fix this by iterating the test's main context until the first connection
is destroyed.

And call the openssl api if it is defined
Fixes #156

Also point to the glib 2.67 branch for now

It seems we have no tests to see if these errors work or not, because
the code is comparing a GTlsConnectionBaseStatus code to a GnuTLS error
code. It has been broken since 0e94c20a.
The code previously used "status" as the name for a GnuTLS error code,
then changed it to be a GTlsConnectionBaseStatus in that commit. Alas, I
should have used a different intermediary name instead, which would have
caught this as a compiler error.

Getting the tests to return particular errors is likely impractical.
Let's just fix this and move on.

Turns out the current code to guess whether to return
G_TLS_ERROR_CERTIFICATE_REQUIRED is racy. With TLS 1.2, the client would
see a handshake failure if a client certificate was required but not
provided (or not accepted). That's no longer the case with TLS 1.3;
instead, the client will see a successful handshake before it sees the
server close the connection. GnuTLS is no longer able to indicate *why*
the connection was closed unless the server sends
GNUTLS_A_CERTIFICATE_REQUIRED, but we don't support alerts yet, #65. In
the meantime, we're stuck using a heuristic to decide whether to return
G_TLS_ERROR_CERTIFICATE_REQUIRED: if the server requested a certificate,
and we did not provide one, and an operation fails, and we have never
successfully done any operation after the handshake, then assume the
server rejected our certificate and return
G_TLS_ERROR_CERTIFICATE_REQUIRED. This behavior was added in 14be4745.

However, there in a window of time during which the client may see write
operations succeed even though it failed to provide an acceptable
certificate and the connection is about to be closed by the server. If a
write succeeds, then our heuristic to decide whether to return
G_TLS_ERROR_CERTIFICATE_REQUIRED fails. So let's change the heuristic to
check only for reads instead. A read can never succeed because a
properly-implemented server would not write any data before it verifies
that the client certificate is acceptable.

This commit fixes 14be4745. It's sort of covered by existing tests, in
that we have tests that check for G_TLS_ERROR_CERTIFICATE_REQUIRED,
although they don't seem to be tripping this race. We have a libsoup
test /ssl/tls-interaction that is really hitting this race, although
this change won't be enough to fix that test, because that test needs to
be changed to no longer expect the TLS 1.2 behavior.

Use bash, because 'read -p' is a bashism.

Use 'set -e' to give up on error, or shellcheck will complain that we
don't check whether cd fails.

Remove an unused variable.

Note this commit does not violate hard code freeze because this script
is only run manually by glib-networking maintainers.

Coverity noticed that if g_tls_connection_base_handshake_thread_request_certificate()
returns FALSE here, we call g_tls_certificate_gnutls_copy_free() twice
with the same data. It's obvious and should never have happened. Oops.

All priv members need to be locked, including priv->trust_list. Although
it is read-only once it is initialized, apparently still not safe to
share across threads.

We also need to lock priv->verify_chain_cancellable.

https://bugzilla.redhat.com/show_bug.cgi?id=1937513

This reverts commit 248003f3.

This is not quite ready yet, and I don't want to maintain it on the
GLib 2.68 branch. See #160 for details on further work required.