Class TlsFileDatabase

Whenever the source_property is changed the target_property is updated using the same value. For instance:

  g_object_bind_property (action, "active", widget, "sensitive", 0);

Will result in the "sensitive" property of the widget #GObject instance to be updated with the same value of the "active" property of the action #GObject instance.

If flags contains %G_BINDING_BIDIRECTIONAL then the binding will be mutual: if target_property on target changes then the source_property on source will be updated as well.

The binding will automatically be removed when either the source or the target instances are finalized. To remove the binding without affecting the source and the target you can just call g_object_unref() on the returned #GBinding instance.

Removing the binding by calling g_object_unref() on it must only be done if the binding, source and target are only used from a single thread and it is clear that both source and target outlive the binding. Especially it is not safe to rely on this if the binding, source or target can be finalized from different threads. Keep another reference to the binding and use g_binding_unbind() instead to be on the safe side.

A #GObject can have multiple bindings.

This function is the language bindings friendly version of g_object_bind_property_full(), using #GClosures instead of function pointers.

This handle should be stable across various instances of the application, and between applications. If a certificate is modified in the database, then it is not guaranteed that this handle will continue to point to it.

This is necessary for accessors that modify multiple properties to prevent premature notification while the object is still being modified.

The value can be:

• an empty #GValue initialized by %G_VALUE_INIT, which will be automatically initialized with the expected type of the property (since GLib 2.60)
• a #GValue initialized with the expected type of the property
• a #GValue initialized with a type to which the expected type of the property can be transformed

In general, a copy is made of the property contents and the caller is responsible for freeing the memory by calling g_value_unset().

Note that g_object_get_property() is really intended for language bindings, g_object_get() is much more convenient for C programming.

The handle should have been created by calling g_tls_database_create_certificate_handle() on a #GTlsDatabase object of the same TLS backend. The handle is designed to remain valid across instantiations of the database.

If the handle is no longer valid, or does not point to a certificate in this database, then %NULL will be returned.

This function can block, use g_tls_database_lookup_certificate_for_handle_async() to perform the lookup operation asynchronously.

If the handle is no longer valid, or does not point to a certificate in this database, then %NULL will be returned.

This function can block. Use g_tls_database_lookup_certificate_issuer_async() to perform the lookup operation asynchronously.

Beware this function cannot be used to build certification paths. The issuer certificate returned by this function may not be the same as the certificate that would actually be used to construct a valid certification path during certificate verification. RFC 4158 explains why an issuer certificate cannot be naively assumed to be part of the the certification path (though GLib's TLS backends may not follow the path building strategies outlined in this RFC). Due to the complexity of certification path building, GLib does not provide any way to know which certification path will actually be used when verifying a TLS certificate. Accordingly, this function cannot be used to make security-related decisions. Only GLib itself should make security decisions about TLS certificates.

This function can block, use g_tls_database_lookup_certificates_issued_by_async() to perform the lookup operation asynchronously.

The database may choose to hold a reference to the issuer byte array for the duration of of this asynchronous operation. The byte array should not be modified during this time.

When possible, eg. when signaling a property change from within the class that registered the property, you should use g_object_notify_by_pspec() instead.

Note that emission of the notify signal may be blocked with g_object_freeze_notify(). In this case, the signal emissions are queued and will be emitted (in reverse order) when g_object_thaw_notify() is called.

This function omits the property name lookup, hence it is faster than g_object_notify().

One way to avoid using g_object_notify() from within the class that registered the properties, and using g_object_notify_by_pspec() instead, is to store the GParamSpec used with g_object_class_install_property() inside a static array, e.g.:

  enum
  {
    PROP_0,
    PROP_FOO,
    PROP_LAST
  };

  static GParamSpec *properties[PROP_LAST];

  static void
  my_object_class_init (MyObjectClass *klass)
  {
    properties[PROP_FOO] = g_param_spec_int ("foo", "Foo", "The foo",
                                             0, 100,
                                             50,
                                             G_PARAM_READWRITE);
    g_object_class_install_property (gobject_class,
                                     PROP_FOO,
                                     properties[PROP_FOO]);
  }

and then notify a change on the "foo" property with:

  g_object_notify_by_pspec (self, properties[PROP_FOO]);

Since GLib 2.56, if GLIB_VERSION_MAX_ALLOWED is 2.56 or greater, the type of object will be propagated to the return type (using the GCC typeof() extension), so any casting the caller needs to do on the return type must be explicit.

In other words, if the object is floating, then this call "assumes ownership" of the floating reference, converting it to a normal reference by clearing the floating flag while leaving the reference count unchanged. If the object is not floating, then this call adds a new normal reference increasing the reference count by one.

Since GLib 2.56, the type of object will be propagated to the return type under the same conditions as for g_object_ref().

This function should only be called from object system implementations.

If the object already had an association with that name, the old association will be destroyed.

Internally, the key is converted to a #GQuark using g_quark_from_string(). This means a copy of key is kept permanently (even after object has been finalized) — so it is recommended to only use a small, bounded set of values for key in your program, to avoid the #GQuark storage growing unbounded.

void
object_add_to_user_list (GObject     *object,
                         const gchar *new_string)
{
  // the quark, naming the object data
  GQuark quark_string_list = g_quark_from_static_string ("my-string-list");
  // retrieve the old string list
  GList *list = g_object_steal_qdata (object, quark_string_list);

  // prepend new string
  list = g_list_prepend (list, g_strdup (new_string));
  // this changed 'list', so we need to set it again
  g_object_set_qdata_full (object, quark_string_list, list, free_string_list);
}
static void
free_string_list (gpointer data)
{
  GList *node, *list = data;

  for (node = list; node; node = node->next)
    g_free (node->data);
  g_list_free (list);
}

Using g_object_get_qdata() in the above example, instead of g_object_steal_qdata() would have left the destroy function set, and thus the partial string list would have been freed upon g_object_set_qdata_full().

Duplicate notifications for each property are squashed so that at most one #GObject::notify signal is emitted for each property, in the reverse order in which they have been queued.

It is an error to call this function when the freeze count is zero.

If the pointer to the #GObject may be reused in future (for example, if it is an instance variable of another object), it is recommended to clear the pointer to %NULL rather than retain a dangling pointer to a potentially invalid #GObject instance. Use g_clear_object() for this.

chain is a chain of #GTlsCertificate objects each pointing to the next certificate in the chain by its #GTlsCertificate:issuer property.

purpose describes the purpose (or usage) for which the certificate is being used. Typically purpose will be set to %G_TLS_DATABASE_PURPOSE_AUTHENTICATE_SERVER which means that the certificate is being used to authenticate a server (and we are acting as the client).

The identity is used to ensure the server certificate is valid for the expected peer identity. If the identity does not match the certificate, %G_TLS_CERTIFICATE_BAD_IDENTITY will be set in the return value. If identity is %NULL, that bit will never be set in the return value. The peer identity may also be used to check for pinned certificates (trust exceptions) in the database. These may override the normal verification process on a host-by-host basis.

Currently there are no flags, and %G_TLS_DATABASE_VERIFY_NONE should be used.

If chain is found to be valid, then the return value will be 0. If chain is found to be invalid, then the return value will indicate at least one problem found. If the function is unable to determine whether chain is valid (for example, because cancellable is triggered before it completes) then the return value will be %G_TLS_CERTIFICATE_GENERIC_ERROR and error will be set accordingly. error is not set when chain is successfully analyzed but found to be invalid.

GLib guarantees that if certificate verification fails, at least one error will be set in the return value, but it does not guarantee that all possible errors will be set. Accordingly, you may not safely decide to ignore any particular type of error. For example, it would be incorrect to mask %G_TLS_CERTIFICATE_EXPIRED if you want to allow expired certificates, because this could potentially be the only error flag set even if other problems exist with the certificate.

Prior to GLib 2.48, GLib's default TLS backend modified chain to represent the certification path built by #GTlsDatabase during certificate verification by adjusting the #GTlsCertificate:issuer property of each certificate in chain. Since GLib 2.48, this no longer occurs, so you cannot rely on #GTlsCertificate:issuer to represent the actual certification path used during certificate verification.

Because TLS session context is not used, #GTlsDatabase may not perform as many checks on the certificates as #GTlsConnection would. For example, certificate constraints may not be honored, and revocation checks may not be performed. The best way to verify TLS certificates used by a TLS connection is to let #GTlsConnection handle the verification.

The TLS backend may attempt to look up and add missing certificates to the chain. This may involve HTTP requests to download missing certificates.

This function can block. Use g_tls_database_verify_chain_async() to perform the verification operation asynchronously.

If chain is found to be valid, then the return value will be 0. If chain is found to be invalid, then the return value will indicate the problems found. If the function is unable to determine whether chain is valid or not (eg, because cancellable is triggered before it completes) then the return value will be %G_TLS_CERTIFICATE_GENERIC_ERROR and error will be set accordingly. error is not set when chain is successfully analyzed but found to be invalid.