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