Using the generic marshaller has drawbacks beyond performance. One such
drawback is that it breaks the stack unwinding from the Linux kernel due
to having unsufficient data to walk past ffi_call_unixt64. That means that
performance profiling by application developers looks grouped among
seemingly unrelated code paths.
While we can't fix the kernel unwinding here, we can provide proper
c_marshallers and va_marshallers for objects within Gio so that
performance profiling of applications is more reliable.
Related to GNOME/Initiatives#10
These have all been documented as deprecated for a long time, but we’ve
never had a way to programmatically mark them as deprecated. Do that
now.
This is based on the list of deprecations from the reverted commit
80fcb1bc2.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Fixes: #638
Allowing unsafe rehandshakes used to be required for web compatibility,
but this is no longer a concern in 2018. So there should no longer be
compatibility benefits to calling this function. All it does is make
your TLS connection insecure.
Also, rehandshaking no longer exists at all in TLS 1.3.
At some point (maybe soon!) glib-networking will begin ignoring the
rehandshake mode, so let's deprecate it now.
Let's entirely deprecate calling this function for rehandshaking. The
current documentation is OK, but guarantees defined behavior (to attempt
a rehandshake) when TLS 1.2 is in use. But there's no way to force TLS
1.2, and also no way to check which version of TLS is in use. I really
should have deprecated use of this function for rehandshaking entirely
last time I updated it.
Fortunately, there should be no compatibility risk for existing code,
because rehandshaking has no visible effects at the API level.
I made a mistake when last updating the documentation in 94a99ae9. I
wrote that, with TLS 1.3, this would perform a rekey instead of a
rehandshake. In fact, that's only true for client connections. For
server connections, it's a no-op.
I was a bit nervous about how to document the behavior anyway, because
we really don't know what behavior will be reasonable with non-GnuTLS
crypto backends. This behavior is reasonable for the GnuTLS backend, but
might not necessarily make sense for OpenSSL. Ideally, we would
discourage API users from doing things which could have unexpected
effects, so instead of documenting what the GnuTLS backend does, I think
it'd be better to document that this is "undefined but not dangerous,"
since of course we want to make sure that existing code that doesn't
know about TLS 1.3 is not broken.
If we have an input parameter (or return value) we need to use (nullable).
However, if it is an (inout) or (out) parameter, (optional) is sufficient.
It looks like (nullable) could be used for everything according to the
Annotation documentation, but (optional) is more specific.
Add a new GDtlsConnection interface, plus derived GDtlsClientConnection
and GDtlsServerConnection interfaces, for implementing Datagram TLS
support in glib-networking.
A GDtlsConnection is a GDatagramBased, so may be used as a normal
datagram socket, wrapping all datagrams from a base GDatagramBased in
DTLS segments.
Test cases are included in the implementation in glib-networking.
https://bugzilla.gnome.org/show_bug.cgi?id=752240
The database is an abstract object implemented by the various TLS
backends, which is used by GTlsConnection to lookup certificates
and keys, as well as verify certificate chains.
Also add GTlsInteraction, which can be used to prompt the user
for a password or PIN (used with the database).
https://bugzilla.gnome.org/show_bug.cgi?id=636572
To help cross compilation, don't use glib-genmarshal in our
build. This is easy now that we have g_cclosure_marshal_generic().
In gobject/, add gmarshal.[ch] to git (making the existing entry
points stubs).
In gio/, simply switch to using g_cclosure_marshal_generic().
https://bugzilla.gnome.org/show_bug.cgi?id=652168
Make the certificate and peer-certificate properties virtual, and add
peer-certificate-errors as well. Change the documentation on
peer-certificate to say that it's not set until after the handshake
succeeds (which means notify::peer-certificate can be used to tell
when a handshake has completed).
We were combining "allow un-notified closes" and "close without
notifying" into a single property, which meant that it was impossible
to "be liberal in what you accept and conservative in what you send".
Change require-close-notify to only be about the peer behavior, and
make our connections always close-notify properly when closing (while
noting that you can just close the base-io-stream directly if you want
to do an unclean close).
Trying to do this as a signal won't work well with either
GTlsCertificateDB (in which case looking up a certificate in the db is
a blocking/asynchronous act) or session resumption support (in which
case the certificate or lack thereof is part of the session definition
and so needs to be known immediately). Make the caller use
g_tls_connection_set_certificate() ahead of time (or when retrying)
instead.
This adds an extension point for TLS connections to gio, with a
gnutls-based implementation in glib-networking.
Full TLS support is still a work in progress; the current API is
missing some features, and parts of it may still be changed before
2.28.
https://bugzilla.gnome.org/show_bug.cgi?id=588189
