Add SPDX license (but not copyright) headers to all files which follow a
certain pattern in their existing non-machine-readable header comment.
This commit was entirely generated using the command:
```
git ls-files gio/*.[ch] | xargs perl -0777 -pi -e 's/\n \*\n \* This library is free software; you can redistribute it and\/or\n \* modify it under the terms of the GNU Lesser General Public/\n \*\n \* SPDX-License-Identifier: LGPL-2.1-or-later\n \*\n \* This library is free software; you can redistribute it and\/or\n \* modify it under the terms of the GNU Lesser General Public/igs'
```
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #1415
The current code is unsafe to use from multiple threads at once.
GIOStream functions like this are supposed to be semi-threadsafe. It's
allowed for them to be called on both a reader thread and a writer
thread at the same time. Of course, it's still tricky and dangerous,
because it's only *really* threadsafe if the handshake has finished,
and API users have no plausible way to know that because the API
does not require performing an explicit handshake operation. But that's
a glib-networking problem. We can at least avoid the most obvious
threadsafety issue here in the API layer.
Note that we'll need to implement the new vfunc in glib-networking for
this to actually work.
Fixes#2393
This adds g_tls_connection_get_protocol_version(),
g_tls_connection_get_ciphersuite_name(), and DTLS variants. This will
allow populating TLS connection information in the WebKit web inspector.
This is WIP because we found it's not quite possibly to implement
correctly with GnuTLS. See glib-networking!151.
* Add g_tls_connection_get_channel_binding_data API call
* Add g_dtls_connection_get_channel_binding_data API call
* Add get_binding_data method to GTlsConnection class
* Add get_binding_data method to GDtlsConnection interface
* Add GTlsChannelBindingType enum with tls-unique and
tls-server-end-point types
* Add GTlsChannelBindingError enum and G_TLS_CHANNEL_BINDING_ERROR
quark
* Add new API calls to documentation reference gio-sections-common
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
This reverts commit 80fcb1bc26.
G_DISABLE_DEPRECATED should never be used by anybody, least of all by
GLib. We have deprecation annotations for the compiler, these days, and
they are much better suited than a macro that makes symbols appear and
disappear. The fact that gtk-doc doesn't understand the deprecation
annotations is a limitation of gtk-doc, and it's gtk-doc that ought to be
fixed.
Commit 80fcb1bc broke GStreamer, which disables old API that was
deprecated before the introduction of the deprecation annotations, but
still uses newly deprecated one, and relies on the deprecation
annotations to do their thing. It also broke libsoup, as it uses
GValueArray in its own API.
As pointed out by gtk-doc, these are all symbols which have been marked
as deprecated, but which aren’t protected by a deprecation guard. We
can’t use G_DEPRECATED_IN_* for them, as they are all non-function
symbols. Instead, wrap them in #ifndef G_DISABLE_DEPRECATED.
In some cases, we also need to wrap one or two functions which use the
deprecated types in G_DISABLE_DEPRECATED too.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
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.
Add the GLIB_AVAILABLE_IN_ALL annotation to all old functions (that
haven't already been annotated with the GLIB_AVAILABLE_IN_* macros or a
deprecation macro).
If we discover in the future that we cannot use only one macro on
Windows, it will be an easy sed patch to fix that.
https://bugzilla.gnome.org/show_bug.cgi?id=688681
gio/gproxyresolver.h: GProxyResolver already documented in gio/giotypes.h
gio/gtlsbackend.h: GTlsBackend already documented in gio/gtlsbackend.c
gio/gtlsclientconnection.h: GTlsClientConnection already documented in gio/gtlsclientconnection.c
gio/gtlsconnection.h: GTlsConnection already documented in gio/gtlsconnection.c
gio/gunixconnection.h: GTcpConnection already documented in gio/giotypes.h
glib/gversion.h: GLIB_CHECK_VERSION already documented in glib/gversion.c
Found these thanks to the improved gobject-introspection
GTK-Doc comment block/annotation parser.
See https://bugzilla.gnome.org/show_bug.cgi?id=672254https://bugzilla.gnome.org/show_bug.cgi?id=673385
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
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).
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
