summaryrefslogtreecommitdiff
path: root/proxy
Commit message (Collapse)AuthorAgeFilesLines
* Flag all final types accordinglyHEADmasterMichael Catanzaro2023-04-063-13/+13
| | | | Part-of: <https://gitlab.gnome.org/GNOME/glib-networking/-/merge_requests/237>
* proxy: Use environment-libproxy as the as-installed test for libproxySimon McVittie2023-02-121-5/+5
| | | | | | | | | | | | | | Previously the .test file was generated with a reference to ${installed_tests_dir}/environment, which is only built (from the same source code) when the module for proxy configuration from environment variables (without using libproxy) is enabled. The build-time test already correctly ran environment-libproxy. Resolves: https://gitlab.gnome.org/GNOME/glib-networking/-/issues/208 Bug-Debian: https://bugs.debian.org/1031166 Signed-off-by: Simon McVittie <smcv@debian.org> Part-of: <https://gitlab.gnome.org/GNOME/glib-networking/-/merge_requests/235>
* Try to fix environment proxy resolver on WindowsMichael Catanzaro2023-02-091-3/+4
| | | | | | | | The entry points were not exported, oops! Found by Chun-wei Fan. Hopefully fixes #185 Part-of: <https://gitlab.gnome.org/GNOME/glib-networking/-/merge_requests/226>
* Remove auto featuresMichael Catanzaro2022-10-121-1/+1
| | | | | | | | | | | | | | | | I tried to be too clever here and enabled environment proxy support by default whenever libproxy is disabled. This strategy fails because all distros enable auto features: https://gitlab.gnome.org/GNOME/glib-networking/-/merge_requests/217#note_1529568 The solution is to enable libproxy by default, and disable environment proxy by default. This leaves only two remaining auto features: GnuTLS, which is almost always wanted, and GNOME proxy, which is also almost always wanted. Just pick the right defaults. If you don't want these enabled, pass the flag to disable them. Simple Part-of: <https://gitlab.gnome.org/GNOME/glib-networking/-/merge_requests/220>
* Fix static link on WindowsXavier Claessens2022-10-061-3/+4
| | | | | | | | | | When making a static module on Windows, we should not have `dllexport` on g_io_* functions. However, G_MODULE_EXPORT is defined to always have `dllexport` on Windows because it is made for shared modules only. Building both shared and static modules is not supported on Windows. Part-of: <https://gitlab.gnome.org/GNOME/glib-networking/-/merge_requests/223>
* Do not install shared module when only static is neededXavier Claessens2022-10-063-6/+6
| | | | Part-of: <https://gitlab.gnome.org/GNOME/glib-networking/-/merge_requests/223>
* Propagate GIO_PROXY_TEST_NAME to installed testsMichael Catanzaro2022-08-291-0/+1
| | | | | | | Otherwise, the test has no way to test the proxy resolver that it claims to test. Part-of: <https://gitlab.gnome.org/GNOME/glib-networking/-/merge_requests/222>
* Disable libproxy resolver when running environment proxy testMichael Catanzaro2022-08-292-14/+8
| | | | | | | | After reversing the priority of the environment proxy vs. libproxy proxy resolvers, I forgot to also reverse the logic that ensures the correct resolver gets used when running tests. Part-of: <https://gitlab.gnome.org/GNOME/glib-networking/-/merge_requests/222>
* Meson: Bump version requirement to 0.60.0Xavier Claessens2022-08-121-7/+1
| | | | Fix all deprecation warnings this causes.
* Meson: Use summary() to print enabled modulesXavier Claessens2022-08-123-0/+6
| | | | | Also build a list of modules so parent project can know which one have been configured.
* Meson: Add dependencies on static modulesXavier Claessens2022-08-123-0/+3
| | | | | | They are not needed to build the static library since it's using only object files from the shared library, but they are needed to link against them when used in an application.
* Meson: Add 'recursive: true' to avoid warningXavier Claessens2022-08-123-3/+3
| | | | | In our case it makes no difference, but Meson prints warning if we don't specify that keyword argument.
* Meson: Build static modules when default_library is 'static' or 'both'Xavier Claessens2022-08-123-3/+3
| | | | | | | | | This makes it closer to the behaviour we would have if using library() instead of shared_module(). Ideally Meson should allow us to do just that, see https://github.com/mesonbuild/meson/pull/3361. When we can depend on Meson >= 0.60 we should mark 'static_modules' option deprecated.
* Add build option for environment proxy resolverMichael Catanzaro2022-08-051-3/+1
| | | | | | | | | | Since fixing #190, the environment proxy resolver is now redundant with libproxy and there is no reason for it to be built or installed if libproxy is enabled. Accordingly, let's give it its own build option. It will be enabled by default if libproxy is enabled, and disabled by default otherwise. Part-of: <https://gitlab.gnome.org/GNOME/glib-networking/-/merge_requests/217>
* Drop environment proxy resolver to lowest priorityMichael Catanzaro2022-08-052-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | Currently the environment proxy resolver has 100 priority. The portal resolver in GLib has 90 priority, the GNOME settings resolver has 80 priority, and the libproxy resolver is relegated to last place with 0 priority. Making the new environment proxy resolver highest-priority seemed like a good idea to me because environment variables are for debugging and surely if an environment variable is set it's because you want it to be respected, right? Wrong. Problem is, Console and Terminal both inspect GNOME proxy settings and translate them into environment variables, see console#81. If we prioritize the environment variables, which are unable to fully express the desktop configuration, then we lose out on goodies like web proxy autoconfig and such. Worse, this will only happen when running from your terminal, meaning applications will break only when run in Console or Terminal. Imagine how frustrating that would be to debug. Although I'm usually reluctant to make major behavior changes in a stable release, we should revert back to longstanding historical behavior. The environment proxy resolver will be used only as the last fallback, useful in case libproxy is not available. Fixes #190 Part-of: <https://gitlab.gnome.org/GNOME/glib-networking/-/merge_requests/217>
* gproxyresolvergnome: validate proxy URIsMichael Catanzaro2022-06-281-7/+41
| | | | | | | | | | If we have something silly stored in gsettings, we should reject it rather than pass it along to API users. This ensures we return only valid URIs or NULL. P.S. This also fixes a GError leak on an error path. Part-of: <https://gitlab.gnome.org/GNOME/glib-networking/-/merge_requests/212>
* glibproxyresolver: validate proxy URIsMichael Catanzaro2022-06-281-0/+9
| | | | | | | | | This adds an extra layer of safety to ensure our GProxyResolver only ever returns URIs that GLib considers valid. Otherwise, if libproxy returns something silly like an empty string, nothing prevents us from passing it along. Part-of: <https://gitlab.gnome.org/GNOME/glib-networking/-/merge_requests/212>
* Use px_proxy_factory_free_proxies()Michael Catanzaro2022-06-281-16/+1
| | | | | | I've been waiting to do this for a long time! Part-of: <https://gitlab.gnome.org/GNOME/glib-networking/-/merge_requests/212>
* genvironmentproxyresolver: validate environment variable valuesMichael Catanzaro2022-06-281-14/+36
| | | | | | | | | | | | | | | Instead of blindly trusting the environment, let's make sure we have actually received proper URLs. An empty string will be assumed to mean "no proxy, please." Any empty environment variable will still cause all GNOME proxy settings to be ignored, because you might want to use an empty environment variable to temporarily suppress use of GNOME proxy settings without messing with XDG_CURRENT_DESKTOP. Helps with glib#2597 Fixes #189 Part-of: <https://gitlab.gnome.org/GNOME/glib-networking/-/merge_requests/212>
* meson: Export static libraries and depsOlivier Crête2022-06-213-3/+14
| | | | | | This way it can be used as a subproject Part-of: <https://gitlab.gnome.org/GNOME/glib-networking/-/merge_requests/213>
* Proxy tests should unset proxy environment variablesMichael Catanzaro2022-02-281-0/+10
| | | | | Otherwise, environment variable proxy configuration of the test runner could mess up our test.
* meson: Set GIO_EXTRA_MODULES in devenvXavier Claessens2022-02-213-0/+18
| | | | | | | This makes GIO find modules within "meson devenv" without having to install it on the system. Part-of: <https://gitlab.gnome.org/GNOME/glib-networking/-/merge_requests/208>
* proxy/tests/common.c: Use g_getenv() instead of getenv()Chun-wei Fan2022-02-211-1/+1
| | | | | | | | | getenv() does not exist on Visual Studio builds at least, but we can be assured that g_getenv() is. This will fix the proxy tests on Visual Studio-like builds at least. Part-of: <https://gitlab.gnome.org/GNOME/glib-networking/-/merge_requests/207>
* build: move some code to lower-level meson.buildsMichael Catanzaro2022-02-161-0/+15
| | | | | | | This simplifies the subdir logic in the toplevel meson.build by pushing it lower. It's not a huge simplification, but helps a bit. Part-of: <https://gitlab.gnome.org/GNOME/glib-networking/-/merge_requests/204>
* proxy: update copyright year in environment proxy filesMichael Catanzaro2022-02-112-2/+2
|
* Add environment variable proxy resolverMichael Catanzaro2022-02-0911-39/+408
| | | | | | | | | | | | | | | | | | | | There is no reason to use libproxy just to resolve some environment variables for us. This makes it possible to resolve proxies outside GNOME when built with libproxy support disabled, and also reduces our odds of crashing if a gjs app uses a libproxy that's linked to mozjs, or if a WebKit app uses a libproxy that's linked to JavaScriptCore. This should also help the user in #183 who was confused that libproxy doesn't look at environment variables when running under KDE. Of course, apps that use libproxy directly, rather than GProxyResolver, are still going to look at desktop settings first. That should probably change in libproxy. Fixes #162 Part-of: <https://gitlab.gnome.org/GNOME/glib-networking/-/merge_requests/203>
* Remove unused GLIBPROXY_PACRUNNERMichael Catanzaro2022-02-091-1/+0
| | | | Part-of: <https://gitlab.gnome.org/GNOME/glib-networking/-/merge_requests/203>
* Add FIXME to switch to using px_proxy_factory_free_proxies()Michael Catanzaro2020-08-131-0/+5
|
* Name all GTasks and tighten assertions around their useMichael Catanzaro2019-07-042-1/+5
| | | | | | | | | | | | | Every GTask should have a name! This helps when debugging problems. Also, for every GTask used in an async operation, we should check (a) that the source tag matches, and (b) that the task is valid. This uses g_return assertions for anything applications can screw up, and g_assert for anything internal to glib-networking. Lastly, there's no need to set a source tag in g_libproxy_resolver_lookup() since that's a sync function and there's nowhere it can ever be checked.
* Stop writing out '== NULL' and '!= NULL'Michael Catanzaro2019-06-242-3/+3
| | | | | | | | | | | | | | | | | | | Currently glib-networking code style is inconsistent on whether to test for NULL using !pointer or pointer == NULL. This is harmful because it forces us to think and make a decision each time when writing such conditions. We have somewhat-arbitrarily agreed to stop writing this out longways. The tiebreaker is the C++ core guidelines (endorsed by the C++ standardization people): http://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#es87-dont-add-redundant--or--to-conditions glib-networking is not C++, but the decision either way is arbitrary, so this seems like as good a tiebreaker as any. Also, WebKit requires it this way, and therefore so does Epiphany. Fixes #72
* Use #pragma onceMichael Catanzaro2019-06-242-8/+2
| | | | Fixes #73
* proxy/gnome: remove unused methodIgnacio Casal Quinteiro2019-05-141-12/+0
|
* gnome-proxy-module.c: Export the GIO module entry pointsChun-wei Fan2019-03-071-3/+3
| | | | | | As we could install gsettings-desktop-schemas and things work, we should also make sure that the GNOME proxy module also works on Visual Studio builds.
* meson: Use .so for modules on macOS instead of dylibNirbheek Chauhan2018-05-292-0/+2
| | | | This matches what libtool produces, and what gio/gmodule expect.
* Generate a .pc file for each moduleXavier Claessens2018-04-252-0/+2
| | | | | | | | | When static_modules is true, generate a .pc file to each module to be able to get their private dependencies. This uses a simplified pkg.generate() API added in Meson 0.46.0. https://bugzilla.gnome.org/show_bug.cgi?id=795043
* Rename GLibProxyResolver to GLibproxyResolverMichael Catanzaro2018-04-152-11/+11
| | | | | | Is it GLib's proxy resolver, or is it GLib's libproxy resolver? The answer is the later, but you'd be forgiven for being very confused. Let's avoid that.
* tests: Stop setting GIO_EXTRA_MODULESMichael Catanzaro2018-04-152-4/+0
| | | | | It's pointing to a libtool directory that isn't created anymore. This is handled nowadays by setting GIO_MODULE_DIR in the test environment.
* meson: allow building as a subprojectMathieu Duponchelle2018-03-282-0/+4
| | | | | | and use fallbacks for the mandatory dependencies https://bugzilla.gnome.org/show_bug.cgi?id=794709
* Don't generate installed test files when not enabledMichael Catanzaro2018-03-161-7/+8
| | | | | | | | | | | These files are not needed except when installed tests are enabled, so they should not be generated at all by default. This is good to do for its own sake, but also works around some weird behavior of meson that has resulted in these files being installed even when installed tests are disabled. https://bugzilla.gnome.org/show_bug.cgi?id=794372
* Use consistent code style for castsMichael Catanzaro2018-03-111-1/+1
|
* proxy: Change variable name to be less confusingMichael Catanzaro2018-02-121-4/+4
|
* proxy: Reword comment to be more accurateMichael Catanzaro2018-02-121-2/+2
|
* pacrunner: Unset XDG_CURRENT_DESKTOPMichael Catanzaro2018-02-121-0/+4
| | | | | This is precautionary. Should allow libproxy to do the right thing once we get rid of these older, less-favored environment variables.
* proxy: Use XDG_CURRENT_DESKTOP to determine which proxy module to loadMichael Catanzaro2018-02-122-9/+9
| | | | | | | | | | | | | | | This will somewhat reduce the odds that that we'll load libproxy in the gnome-shell greeter process, causing libproxy's old version of mozjs to be loaded into the same process as gjs's newer version, causing the login screen to crash in a spectacular loop of sadness, causing coredumpctl to thrash the system... yeah. This is already fixed in gnome-session by https://git.gnome.org/browse/gnome-session/commit/?id=5f920253dfb2c0f2c4b742690f306cfea2ac6613 but I figure I should do my civic duty here to make it easier to remove these environment variables in the future. https://bugzilla.gnome.org/show_bug.cgi?id=790387
* Use G_DECLARE_[FINAL,DERIVABLE]_TYPEMichael Catanzaro2018-02-082-24/+2
| | | | | | | | | | | This means we eliminate the priv pointer from final classes, and access it via the _get_instance_private() getter for derivable classes. It's a mechanical transformation, except in GTlsCertificateGnutls where a couple loops need adjusted to make it easier to get the priv struct of other GTlsCertificateGnutls objects. This is considered the modern best-practice, and is possible now that we finally depend on a recent version of GLib.
* Kill tabs and add modelinesMichael Catanzaro2018-02-0710-203/+223
| | | | The tabs are slowing me down too much. I'm not doing tabs.
* Add 'static-modules' optionXavier Claessens2018-01-042-2/+18
| | | | | | | When enabled both a shared module and static library are built for each module. https://bugzilla.gnome.org/show_bug.cgi?id=791100
* Allow static build of modulesXavier Claessens2018-01-044-6/+10
| | | | | | | | | | To be able to static link all modules into an executable, g_io_module_load/unload/query() symbols needs to be renamed to the new naming scheme supported by glib 2.56. Those functions should also support receiving NULL GIOModule, and register the extension point manually since they won't be pre-discovered by reading giomodule.cache. https://bugzilla.gnome.org/show_bug.cgi?id=791100
* Fix glib-pacrunner.service install dirMichael Catanzaro2017-11-211-1/+1
| | | | | | | This should be 'lib', not libdir, because systemd looks for unit files under /usr/lib/systemd, not /usr/lib64 and not under multiarch locations. https://bugzilla.gnome.org/show_bug.cgi?id=790367
* Revert "build: Retrieve D-Bus and systemd paths"Michael Catanzaro2017-11-211-2/+2
| | | | This reverts commit 101561dc4b28a4ab544c3a498003bc72eddaa63b.
View Lorry Controller Status