updatechecker: Port to GIO and small other fixes

[b4n]

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.

[xiota]

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.

[eht16]

Guys, be a bit patient :D. I'll test this on Windows/MSYS2 later or in the next days.

[b4n]

@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.

[b4n]

@techee any chance you could check whether gvfs works with HTTP(S) under macos?

[elextr]

@xiota:

(win/mac – the platforms most likely to need update checkers).

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.

[b4n]

@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 :smiley:

[elextr]

just keep using the libsoup implementation

Yeah, but then its back to four plugins to synchronise on libsoup3/webkit2gtk-4.1.

[xiota]

has again pointed out the point I made a while back about this

I realized later that you'd already said it. You're too far ahead. Takes a while to catch up.

four plugins to synchronise

This number could be reduced...

[b4n]

Yeah, but then its back to four plugins to synchronise on libsoup3/webkit2gtk-4.1.

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.

[elextr]

@b4n:

Yet, does it currently matter?

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!

@xiota:

You're too far ahead. Takes a while to catch up.

Just around longer, but older ... and grumpier :grin:

[b4n]

@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.

[elextr]

you never know what the future of the web holds

Yeah, its just a fad :grin:

A new feature maybe, but well.

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.

[techee]

@techee any chance you could check whether gvfs works with HTTP(S) under macos?

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.

[eht16]

Guys, be a bit patient :D. I'll test this on Windows/MSYS2 later or in the next days.

I "think" it will work. In detail this is, when querying https://geany.org I get an error: GET request failed: WinHttp error: SECURE_CHANNEL_ERROR. But I guess this is not related to the changes but rather to the combination of how GIO handles TLS, the outdated Windows 7 I'm using and the fact that geany.org offers only TLS 1.2 or newer. This doesn't seem to be too good for Windows 7.

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. If anyone has access to a Windows 10/11 system, the artifacts of the CI build https://github.com/geany/geany-plugins/actions/runs/8850165013 contain the Geany and G-P installers for easy testing.

[b4n]

I "think" it will work. In detail this is, when querying https://geany.org/ I get an error: GET request failed: WinHttp error: SECURE_CHANNEL_ERROR. […]

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. Does the libsoup version work any better? (I doubt it, but who knows)

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.

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 :laughing:

[eht16]

I "think" it will work. In detail this is, when querying https://geany.org/ I get an error: GET request failed: WinHttp error: SECURE_CHANNEL_ERROR. […] 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. Does the libsoup version work any better? (I doubt it, but who knows)

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: Linux users who install Geany from sources and not via the distro package manager. I don't know if there are any and if so how many and I won't make any attempts to analyse any log files. But we should keep this in mind before dropping the plugin.

[elextr]

@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.

nobody is gonna be using it 😆

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 :tada: we can drop it :smile:

[techee]

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 😆

Yeah, it was with libsoup which, when using gtk-osx for building dependencies, depends on gnutls:

https://gitlab.gnome.org/GNOME/gtk-osx/-/blob/master/modulesets-stable/gtk-osx-network.modules?ref_type=heads#L240

But yeah, the situation may really be different with gio because the package has no such dependency - I'll try.

@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.

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 ;-).

[techee]

So I get

17:47:11.712578: Updatechecker MESSAGE  : Checking for updates (querying URL "https://geany.org/service/version/")
17:47:14.085164: Updatechecker WARNING  : Unable to perform version check: Operation not supported

in debug messages and also the corresponding popup error :-(.

[xiota]

GET request failed: WinHttp error: SECURE_CHANNEL_ERROR

Unable to perform version check: Operation not supported

To confirm, the first is Windows? The second macOS? Both with GIO?

[techee]

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.

[eht16]

So it probably works provided one uses an up to date operating system. If anyone has access to a Windows 10/11 system, the artifacts of the CI build https://github.com/geany/geany-plugins/actions/runs/8850165013 contain the Geany and G-P installers for easy testing.

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.

[techee]

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.

[b4n]

Yeah I agree, better stick with libsoup then, although relying on an existing component was an interesting idea.