Hi, geniuspaste.c does not appear to be enabling TLS certificate verification on the SoupSessionAsync object it creates. [You have to do this manually when using the deprecated SoupSessionAsync.](https://blogs.gnome.org/mcatanzaro/2021/05/25/reminder-soupsessionsync-and-s...)
It's quite trivial to change GeniusPaste to call `soup_session_new_with_options()` instead of the current `soup_session_async_new_with_options()`, the resulting object is still the `SoupSession`, and it seems that the plugin is in fact doing a **synchronous** send. We can implement the queue'ed send, if needed, of course.
However, the implication of the proper TLS validation now is the need to have the system TLS certs available. On Linux there's usually a central cert-db, but not sure there's such on Windows. This plugin does not have direct ways to configure the cert-db location.
What's the recommended way to handle TLS validation on Windows?
On Linux there's usually a central cert-db, but not sure there's such on Windows.
I'm pretty sure that's not true.
What's the recommended way to handle TLS validation on Windows?
The recommended way is to do nothing. Just use the default GTlsDatabase. [That's implemented here](https://gitlab.gnome.org/GNOME/glib-networking/-/blob/master/tls/gnutls/gtls...) and it just uses GnuTLS's default trust store. Presumably that should work as expected on Windows.
On Linux there's usually a central cert-db, but not sure there's such on Windows.
I'm pretty sure that's not true.
Or it just depends on how you define "central cert-db". Usually there is a system wide certificate store with common public root certificates and this store is installed by a package called "ca-certificates" (or similar, depending on the distribution, e.g. https://packages.debian.org/buster/ca-certificates). In short, there is no such thing as an automagically always available store of certificates on Linux. It still must be installed and in the users' responsibility.
What's the recommended way to handle TLS validation on Windows?
The recommended way is to do nothing. Just use the default GTlsDatabase. [That's implemented here](https://gitlab.gnome.org/GNOME/glib-networking/-/blob/master/tls/gnutls/gtls...) and it just uses GnuTLS's default trust store. Presumably that should work as expected on Windows.
This is what I would doubt. Do you have any reference on this? The pasted link is just the code but I could not find any hint about included certificates. So I would assume "glib-networking" needs external certificate resources as well (which is totally fine IMO).
Anyway, for the Windows part: we ship the certificates from the "ca-certificates" package in the G-P Windows installer, for the UpdateChecker plugin but can be used here as well https://github.com/geany/geany-plugins/commit/60116231db908cbf3666d1df114f58...
This is what I would doubt. Do you have any reference on this? The pasted link is just the code but I could not find any hint about included certificates. So I would assume "glib-networking" needs external certificate resources as well (which is totally fine IMO).
If you use the default GTlsDatabase, then you'll get the GnuTLS default trust store, which on Windows will be the Windows trust store. [The code for this is here.](https://gitlab.com/gnutls/gnutls/-/blob/master/lib/system/certs.c)
Of course, you can always write your own GTlsDatabase if you want to do so, but that's only needed for unusual cases.
Anyway, for the Windows part: we ship the certificates from the "ca-certificates" package in the G-P Windows installer, for the UpdateChecker plugin but can be used here as well [6011623](https://github.com/geany/geany-plugins/commit/60116231db908cbf3666d1df114f58...)
Hm, I'm pretty sure GnuTLS is not going to use your ca-certificates trust store at all, not unless you configure it to do so when building GnuTLS. By default, it would prefer the Windows trust instead. You can force it to do what you want using the --with-default-trust-store configure flag when building GnuTLS.
Ok, I don't want to argue about this. Also I don't know enough about the "Windows trust". If it does work automagically, it's fine. If not, we probably will receive a couple of bug reports.
Don't get me wrong, not using TLS is no better.
github-comments@lists.geany.org