updatechecker: Port to GIO and small other fixes #1340
Conversation
libsoup2 is phasing out, and using it in a plugin causes conflicts with other plugins using a newer version, including ones using a current webkit2gtk.
Also, properly abort pending requests when unloading the plugin, in the unlikely case they didn't all finish by that time.
Not only should this be in the German translation if need be, but I'd also just not use quotes after a colon.
There are very little HTTP needs, so GIO with an HTTP VFS implementation, which is usually available. This fixes the libsoup2 vs libsoup3 issue as well.
|
I think a problem with gio method is depends on gvfs (gnome) and not available on msys2 and brew (win/mac – the platforms most likely to need update checkers). Wondering now about libcurl vs libsoup. |
|
Guys, be a bit patient :D. I'll test this on Windows/MSYS2 later or in the next days. |
|
@xiota I don't think we need to explore a different additional HTTP library; either we only use what's already part of the general GTK stack, or using libsoup which is also a direct or indirect dependency of 3 other plugins is fine. |
|
@techee any chance you could check whether gvfs works with HTTP(S) under macos? |
has again pointed out the point I made a while back about this, its useful for Windows and Macos, but for Linux it lies, just because the project releases a new Geany does not put it in the distro they are using. And for many distros it won't ever get updated until the user updates to a new version of the distro. Its ok for Windows and Macos so long as @eht16 and @techee keep making the binaries for those platforms. But all it does for Linux users when this plugin announces a new version is cause frustration. So unless it works on WinMac its pretty useless. |
|
@elextr hence checking if it does :) But if it's a concern, just keep using the libsoup implementation, it ought to work with HTTP as that's the whole point of that library 😃 |
Yeah, but then its back to four plugins to synchronise on libsoup3/webkit2gtk-4.1. |
I realized later that you'd already said it. You're too far ahead. Takes a while to catch up.
This number could be reduced... |
Yet, does it currently matter? I mean, the code is ready (but for more testing maybe) for all four now, porting isn't what is holding back anymore. Sure the question might arise again for a future libsoup4 (if they don't make it possible for those to coexist in a process), but that doesn't seem to be around the corner just yet. |
|
@b4n:
Well if you are willing to maintain them in sync its fine. But who knows if a security alert will require them to change libsoup3.1 API, its a web library after all!
Just around longer, but older ... and grumpier 😁 |
|
@elextr you never know what the future of the web holds, but I highly doubt a security issue would ruin the current API. A new feature maybe, but well. |
Yeah, its just a fad 😁
But the G* guys would never break API without a new major version .... Anyway as you say, there are prototypes for all four plugins available, so if we are not gonna kill any off then they can continue to limp along, just needs to decision about this one using soup or gio. |
The thing is that I didn't even manage to get tls running correctly (it compiled but https didn't work afterwards, probably some configuration issue) so the updatechecker plugin isn't part of the macOS release. |
I "think" it will work. If I change the URL to query to https://httpbin.org/anything/version, the HTTP request works fine and I get the expected response. So it probably works provided one uses an up to date operating system. |
OK, might be either TLS versions or certificates not installed I guess.
What do you mean, with GIO, with libsoup, with anything? If it doesn't work neither on macos not Windows, it starts to feel like nobody is gonna be using it 😆 |
I cannot say for sure, with the libsoup version I get a different error message. Might be the same reason though. Even if we are not sure whether it runs on Windows and we know it does not work on MacOS, there is still another use case for this plugin we tend to forget about: |
|
@techee you don't want to be shipping TLS, that should be using a system library, the last thing you need is to be constantly updating as CVEs are fixed against it. If it doesn't use a system library then it shouldn't be available.
Its wrong on Linux, doesn't work on Windows (except maybe on new versions that the team can't support), and doesn't work on Macos. Yay 🎉 we can drop it 😄 |
Yeah, it was with libsoup which, when using gtk-osx for building dependencies, depends on gnutls: But yeah, the situation may really be different with gio because the package has no such dependency - I'll try.
Probably not, but in this case when it's used only for this plugin (and I believe geniuspaste too), it wouldn't be so horrible even if there were some security issues. Both plugins connect to trusted domains, don't transfer any secrets, and I don't expect there are many attackers eager to pretend there's a new Geany release ;-). |
|
So I get in debug messages and also the corresponding popup error :-(. |
To confirm, the first is Windows? The second macOS? Both with GIO? |
Only speaking for the macOS part - yes, the second message is on macOS with GIO. |
I was about to ask @techee or @rdipardo whether they could test this build but then thought maybe it is not worth the work at all if GeniusPaste still depends on libsoup and so especially for the macOS and Windows bundles, it makes no difference whether UpdateChecker uses GIO or libsoup. |
|
Regarding macOS, the way gio behaves I expect it will never work so better to use libsoup (2 or 3, both are provided by gtk-osx). I can try again if I manage to get tls work with libsoup - to be honest, I didn't try too hard last time because I don't use neither of the plugins. |
|
Yeah I agree, better stick with libsoup then, although relying on an existing component was an interesting idea. |
Same as #1336 but using GIO instead of libsoup.
If wanted? CC @elextr @xiota @frlan.
If we go with that, I can also squash commits 1, 2 and 5 together.