John Biggs [Tue, 15 Nov 2022 19:50:15 +0000 (20:50 +0100)]
WireGuardKit: fix incorrect IP address allocation size
According to [1], the `capacity` parameter is specified as "the number
of instances of T in the re-bound region" and not the total size of the
rebound struct.
Without this patch, there are crashes in the extension with the
following error:
Fatal error: self must be a properly aligned pointer for types Pointee and T`
Since the subsequent line in the code only reads `sizeof(in_addr)` or
`sizeof(in6_addr)` anyway, change the `capacity` parameter to just be a
count of 1.
UI: When saving on-demand rules on a config, enable on-demand if active
When a user saves on-demand rules on the configuration, set
onDemandEnabled to true if the tunnel is active, and false if it isn't.
Then deactivate the tunnel.
Model: migrate iOS 14 keychain references to iOS 15 format
Keychain references used to be bijective, but with the change in format,
Apple tried to be too clever, and references are no longer bijective.
This lead to us deleting keychain entries, which in turn emptied out
people's configs upon upgrading to iOS 15. Disaster!
Fix this by detecting the change in format and saving the new password
reference. We still rely on this being bijective moving forward;
hopefully this bug won't repeat itself. It would be nice to not rely on
that property, but doing so without grinding startup to a halt isn't
obviously done, given how slow the keychain accesses are and how limited
the API is.
Reported-by: Eddie <stunnel@attglobal.net> Reported-by: Anatoli <me@anatoli.ws> Reported-by: Alan Graham <alan@meshify.app> Reported-by: Jacob Wilder <oss@jacobwilder.org> Reported-by: Miguel Arroz <miguel.arroz@gmail.com> Reported-by: Reid Rankin <reidrankin@gmail.com> Reported-by: Fabien <patate.cosmique@pm.me> Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Roopesh Chander [Mon, 2 Aug 2021 08:11:52 +0000 (13:41 +0530)]
build: Include 'swiftlint' location in the PATH before invoking it
In macOS 11, HomeBrew installs swiftlint under /opt/homebrew, which is not
in the default path that Xcode seems to use. So we include the PATH
to contain:
- /usr/local/bin:
Where HomeBrew installs 'swiftlint' in macOS 10.15 and earlier
Roopesh Chander [Mon, 2 Aug 2021 17:39:06 +0000 (23:09 +0530)]
UI: When saving on-demand rules, don't set isOnDemandEnabled
When adding or modifying a config, when on-demand options are set by a
user, the rules are saved, but isOnDemandEnabled is left unset (and can
be set by the appropriate control in the detail view (switch in iOS /
button in macOS)).
Kit: Adapter: use more reliable utun detection technique
Rather than hoping that the AF_SYSTEM fd is of type utun, and then
calling "2" on it to get the name -- which could be defined as something
else for a different AF_SYSTEM socket type -- instead simply query the
AF_SYSTEM control socket ID with getpeername. This has one catch, which
is that the ID is dynamically allocated, so we resolve it using the
qualified name. Normally we'd make a new AF_SYSTEM socket for this, but
since that's not allowed in the sandbox, we reuse the AF_SYSTEM socket
that we're checking. At this point in the flow, we know that it's a
proper AF_SYSTEM one, based on the first sockaddr member; we just don't
know that it's a utun variety.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Kit: Adapter: iterate through all FDs to find UTUN
This is a bit of a kludge, until I find something better. We simply
iterate through all FDs, and call getsockopt on each one until we find
the utun FD. This works, and completes rather quickly (fd is usually 6
or 7). Rather than maintain the old path for older kernels, just use
this for all versions, to get more coverage. Other techniques involve
undocumented APIs; this one has the advantage of using nothing
undocumented.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
macOS will use the wrong source address unless we add explicit routes
that mention the self-pointing gateway. Actually, it won't add any
implicit routes on its own, so in order to route the masks of the
addresses, we have to add our own routes explicitly.
However, this still doesn't fix the problem while inside of the network
extension, even though it works outside it.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
macOS freaks out if you try to explicitly route to 0.0.0.0/8 in its
includedRoutes parameter. Even though 0.0.0.0/8 isn't RFC1918, it is
marked in RFC6890 as "this host on this network", so removing it from
the Internet routes makes sense semantically too.
Apple forbids us from having a simple link to wireguard.com/donations/
in the version info window, citing the existence of this link as a form
of payment outside of their in-app purchase framework that requires 30%.
The link had been there for around two years. After rejecting an app
update for a critical networking regression unrelated to this, they
wrote:
Dec 17, 2020 at 8:35 PM
From Apple
3.1.1 - Business - Payments - In-App Purchase
We noticed that your app allows users to contribute donations to the
development of your app with a mechanism other than the in-app
purchase API, which is not appropriate for the App Store.
Next Steps
To resolve this issue, please revise your app to use the in-app
purchase API to pay for this type of transaction. Please note that
even though tipping another individual is optional, the tip is
connected to or associated with the receipt of digital content or
services in your app and must be purchased through in-app purchase
in accordance with guideline 3.1.1 of the App Store Review
Guidelines.
Please see attached screenshot for details.
Trying to appeal this or reason with Apple is not going to be a fruitful
endeavor, so instead we simply cut our losses and remove the donation
link entirely. The goal, anyway, is to get a timely critical update into
the hands of users, and encouraging Apple to block that further would be
a disservice.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
UI: add missing translations to incomplete locales
This is the wrong way to fix the problem. The correct way will involve
moving away from the whacky tr() macro and using translations functions
properly. But migrating to that will require some heavy scripting work.
So for now, use a hammer.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Kit: Adapter: do not treat NE settings timeouts as fatal
The general Network Extension framework is incredibly buggy, and a
timeout when setting the network settings does not necessarily imply
that the whole operation failed. Simply log the condition and move on.
This restores the app's old behavior.
Reported-by: Filipe Mendonça <cfilipem@gmail.com> Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Kit: PacketTunnelSettingsGenerator: do not require DNS queries if no DNS
Prior, we would set matchDomains=[""] even if the user didn't provide
any DNS servers. This was kind of incoherent, but I guess we had in mind
some kind of non-sensical leakproof scheme that never really worked
anyway. NetworkExtension didn't like this, so setTunnelNetworkSettings
would, rather than return an error, simply timeout and never call its
callback function. But everything worked fine, so we had code in the UI
to check to make sure everything was okay after 5 seconds or so of no
callback. Recent changes made the timeout fatal on the network extension
side, so rather than succeed, configs with no DNS server started
erroring out, causing user reports.
This commit attempts to handle the root cause of the timeout issue by
not twiddling with DNS settings if no DNS server was specified. For now,
however, it leaves the hard-timeout semantics in place.
Reported-by: Filipe Mendonça <cfilipem@gmail.com> Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Apple forbids us from having a simple donation link in the "About
WireGuard" dialog, due to new policies. And arguing with the giant is
not going to be a fruitful battle. Do the practical thing and just
remove it.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
projects / thirdparty / wireguard-apple.git / log
