This ensures we access the socket as user who NM ran the auth-dialog for,
especially for system-wide connections where the connection does not
mention a user.
We also make sure we don't use the cached socket and user of a previous
connection attempt, because system-wide connections might be used by
different users.
This ensures that only certificates/private keys accessible by the
configured user are accessed and prevents attackers from misusing
other user's credentials.
Also removed setting NM_VERSION_MIN_REQUIRED, which suppresses deprecation
warnings that were added with newer API versions, and
NM_VERSION_MAX_ALLOWED, which warns if using functions added in newer
API versions, so we always build against the latest API available.
But we check explicitly for the required function so this works with
older NM versions and automatically will use it if the function is
backported.
Note that we can't use BUILD_FROM_FILE to read the temporary files as that
uses mmap() which SELinux policies prevent us from using at the location
these files are stored ([/var]/run/NetworkManager/cert/).
Fixes: CVE-2025-9615
Using FrameLayout for the settings instead of the recommended
FragmentContainerView because the latter makes handling insets more
complicated (fitsSystemWindows doesn't work as the fragment is responsible
for handling insets but how that should work with PreferenceFragmentCompat
is unclear).
Fixes: 2404b2bee6 ("android: Apply UI changes for edge-to-edge views in Android 15+")
This allows associating a pre-installed certificate/key with a VPN
profile. For instance, one locally generated on the device via
SCEP/ETS by the MDM. It only works if the app is granted access to the
certificate/key (alias) by the MDM.
For now, users may still select a different certificate if one is
available (since this requires the certificate to be installed as
user-selectable there might not be).
Seems to not get pulled in automatically anymore. This has actually been
deprecated for years apparently. Unfortunately, it's not that easy to
replace, so keep it for now.
When targeting Android 15, edge-to-edge is the default and when targeting
Android 16, apps can't opt-out from this anymore. So we update our views
and enable edge-to-edge also for older versions (avoids the black bar
behind the system UI at the bottom). For most views we just use automatic
margins via android:fitsSystemWindows (or programmatically via
setDecorFitsSystemWindows). However, for the profile lists and log views,
we take some extra measures that allow the lists to go behind the bottom
system UI. Appropriate padding is applied at the bottom of the lists so
the last item(s) can be scrolled into full view.
This copies the AC_SEARCH_LIBS check from the main strongSwan
configure.ac.
When building networkmanager-strongswan with slibtool if fails.
ld: cannot find none: No such file or directory
ld: cannot find required: No such file or directory
This is because configure.ac uses AC_SEARCH_LIBS to find dlopen which
sets the value of $ac_cv_search_dlopen to 'none required' which then
gets set in DL_LIBS and passed to slibtool.
With GNU libtool it silently ignores the unknown arguments.
Gentoo issue: https://bugs.gentoo.org/914100Closesstrongswan/strongswan#2141
Signed-off-by: orbea <orbea@riseup.net>
Also removed on Play so the app does not show up when people search
for these keywords (they tend to not read the actual description and
then are surprised that neither protocol is supported).
Newer NDKs have RISC-V as experimental ABI (not enabled by default, see
next commit). If we don't have a mapping for a specific target, OpenSSL
falls back to 'android-arm', so that won't really work (interestingly,
it does build).
These sockets are closed immediately again, so no need to re-protect them
during roaming events.
References strongswan/strongswan#1691
Fixes: 6d87a86510 ("android: Use new sockets to determine source IP")
The callbacks provided via ProcessLifecycleOwner are only triggered when
Activities are started. However, when Android triggers the Always-on
VPN it directly starts our VpnService subclass, no Activity. So the
configs were not loaded and the VPN couldn't be initiated with a managed
profile. This ensures the config is loaded right from the start of
the app. And by registering for modifications in onCreate() we can also
use the correct config if the app is never started in-between changes to
the managed profiles and triggering the Always-on VPN.
Besides being clearer, this fixes issues with GCC 15. The latter uses
C23 by default, which changes the meaning of function declarations
without parameters such as
bool return false();
Instead of "this function takes an unknown number of arguments", this
now equals (void), that is, "this function takes no arguments". So we
run into incompatible pointer type warnings all over when using such
functions. They could be cast to (void*) but this seems the cleaner
solution for this use case.