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>
The Keychain code is much too fragile, and it's better to err on the
safe side. Instead just log an error when this happens.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
In macOS 10.15 and macOS 11, the quit Apple event is sent by:
com.apple.AppStoreDaemon.StoreAEService
In some earlier macOS release, the quit Apple event was sent by:
com.apple.CommerceKit.StoreAEService
Signed-off-by: Roopesh Chander <roop@roopc.net>
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
- /opt/homebrew/bin:
Where HomeBrew installs 'swiftlint' in macOS 11
Signed-off-by: Roopesh Chander <roop@roopc.net>
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)).
Signed-off-by: Roopesh Chander <roop@roopc.net>
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>
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>
Jason A. Donenfeld
Roopesh Chander
Andrej Mihajlov