Adds geolocation lookup feature. Update go version to go 1.22.2 as
bitmask-core uses/needs it.

Nowa Ammerlaan authored 6 months ago and jkito committed 5 months ago

which is an external command, command -v is the equivalent shell built-in.

Replacing the calls to which with command -v removes a build time dependency.

Bug: https://bugs.gentoo.org/940563


Signed-off-by: Nowa Ammerlaan <nowa-ammerlaan@riseup.net>

Pea Nut authored 8 months ago and jkito committed 5 months ago

This prevented VNP working on port 53 because the traffic was redirected
to the DNS server.

Pea Nut authored 8 months ago and jkito committed 5 months ago

We can only iterate once over a generator. After doing, it's like an
empty list. There no real benefit of having it here and we need it in
the future to iterate over the gateways multiple times.

Pea Nut authored 8 months ago and jkito committed 5 months ago

Having a space in Str() is supoptimal:
> DBG Allowd gateway IP gateway ip: =51.158.144.32

jkito authored 7 months ago and jkito committed 5 months ago

this adds a new helper setDefaults() in the config
package and calls it when the config file  doesn't
exist, this provides a way for us to have  default
values for the config options

setDefaults currently only sets the UDP config  to
'true' since it is expected that UDP is enabled by
default

jkito authored 7 months ago and jkito committed 6 months ago

earlier the qmake build always produced the binary named
as bitmask and later it was renamed to whatever PROVIDER
was set to, in the previous commit we fixed the  setting
of TARGET env so that qmake produces the binary with the
correct name

jkito authored 7 months ago and jkito committed 6 months ago

running 'getparam binname' should return the name we want to set
for the qmake TARGET based on the PROVIDER from the  vendor.conf
file, due to running it inside a subshell in make it always gets
the value for the default provider, setting PROVIDER env returns
the correct value

it also updates the qmake project file to use the TARGET env var
and the build script to pass TARGET to qmake command as arg

jkito authored 7 months ago and jkito committed 6 months ago

this allows us to have multiple branded desktop clients installed
along side each other

earlier installing one would uninstall the previous helper as both
used the same name and label for the launchd daemon

jkito authored 7 months ago and jkito committed 6 months ago

qmake is not inheriting the env variables from the parent
process to work around this, it is directly passed as arg
to the qmake invocation

jkito authored 7 months ago and jkito committed 6 months ago

as the RELEASE env variable is used to switch between
release or debug builds

jkito authored 6 months ago and jkito committed 6 months ago

patches are automatically applied during package build
so need to be applied manually

gui/build.sh already knows how to find the right qmake executable. We
don't have to overwrite it here. On ArchLinux, we need qmake6 instead of
qmake. The Makefile sets QMAKE=qmake, even if `gui/build.sh` knows
better (but not if QMAKE is already set).

If people run make -j, the targets are run in parallel in a random
order. So we need to create the directories.

Not needed anyore, as all Linux plattforms we support have a proper go
version.

Before, make clean always returned with an error because the file did
not exist

It gets generated with `make vendor`. After removing it from git repo,
the gui/providers/ directory does not exist anymore. The
gen-providers-json script fails. Therefore the script was fixed and now
creates gui/providers/ directory.

This is done by the build_ubuntu* jobs.

This makes it more consistent.

The CI fails with
go: downloading go1.22.2 (linux/amd64)
go: download go1.22.2 for linux/amd64: toolchain not available

this updates the jobs that builds the client on windows and
macOS on github actions

the jobs were failing due to missing qt-installer-framework
as well as failing to properly install qt6 on windows these
jobs now uses `aqt` to install qt6 on both win and macos

the backend.quit emits the 'quitDone' signal which also
triggers the 'aboutToQuit' signal for the  QApplication
since its handler calls 'QApplication::quit()'

the handler for 'aboutToQuit' signal already calls Quit
so removing it from backend.quit avoids another call to
Quit

This reverts commit b9fc3584.

the aboutToQuit signal is emitted just before the app closes and
gives chance to run some teardown routines, when closing the app
via a keyboard shortcut (cmd+q on macOS) we get this signal  and
the handler stops the firewall and performs other needed cleanup

removing this causes a bug where quiting the app would keep  the
firewall running which results into no internet access

since obfs4 and kcp is disabled in the UI when provider
is riseup, transport needs to be set to openvpn to work
around config file with Obfs4 and KCP set to true  from
a previous version of the app