Bump to xamarin/java.interop/master@dcaf794d

[jonpryor]

Fixes: https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1139578

Context: dotnet/java-interop#691
Context: https://liquid.microsoft.com/Web/Object/Read/ms.security/Requirements/Microsoft.Security.SystemsADM.10039#guide

Changes: dotnet/java-interop@007b35b...dcaf794

• dotnet/java-interop@dcaf794d: [generator] Fix error and warning codes values (Update .gitmodules mono branch to d15-3 #697)
• dotnet/java-interop@08ff4db1: [java-interop, Java.Interop] Securely load native libs (Pull in the Build Process documentation from the docs repo. #691)
• dotnet/java-interop@09c68911: [generator] Clean up generated whitespace ([Xamarin.Android.Build.Tasks] Implement a new process for defining versionCode. #692)
• dotnet/java-interop@d664e90e: [generator] Make warning and error messages localizable. ([monodroid] Update to new profiler init symbol name. #689)

For improved security, the guidance is that when loading .dll files
on Windows, the default LoadLibrary() behavior is to be
avoided, as the Dynamic-Link Library Search Order includes the
"current working directory" and directories listed in %PATH%, both
of which are under control of an "attacker" and not the application.

Instead, LoadLibraryEx() should be used, providing a set of
LOAD_LIBRARY_SEARCH_* values which constrain the set of directories
that will be searched for the library (if a full path is not used)
and/or the library's dependencies.

Historically, Xamarin.Android hasn't directly called any
LoadLibrary() function. Instead, xamarin-android called
dlopen(3), then used dlfcn-win32/dlfcn-win32@ef7e412d to
implement dlopen() in terms of LoadLibraryEx().

Unfortunately, dlfcn-win32/dlfcn-win32@ef7e412d calls LoadLibraryEx()
with LOAD_WITH_ALTERED_SEARCH_PATH, which while a security
improvement, does not go far enough for our internal requirements.

Migrate away from dlfcn-win32 and instead use the new
java-interop-dlfcn.h family of functions added in
dotnet/java-interop@08ff4db1. These new functions appropriately use
LoadLibraryEx() with a constrained set of LOAD_LIBRARY_SEARCH_*
flags.

Non-obvious semantic note: On Mono for all platforms, P/Invoking
__Internal is equivalent to trying to load the path NULL, e.g.
on macOS dlopen(NULL, …). However, only Android allows a custom
"loader_func" to intercept the attempted load of NULL and "do
something" with it, which xamarin-android does intercept, "remapping"
NULL to libxa-internal-api.so. On all other platforms,
loader_func cannot intercept this invocation.

…which made for an "interesting" interaction: on macOS, if we used:

api_dso_handle = java_interop_lib_load (dso_path.get (), JAVA_INTEROP_LIB_LOAD_LOCALLY, nullptr);

then the macOS Designer integration tests would fail!

Renderer >> 4 [monodroid] Calling into managed runtime init
Renderer (error) >>
Renderer (error) >> Unhandled Exception:
Renderer (error) >> System.EntryPointNotFoundException: java_interop_jnienv_get_java_vm assembly:<unknown assembly> type:<unknown type> member:(null)
Renderer (error) >> at (wrapper managed-to-native) Java.Interop.NativeMethods.java_interop_jnienv_get_java_vm(intptr,intptr&)
Renderer (error) >> at Java.Interop.JniEnvironment+References.GetJavaVM (System.IntPtr jnienv, System.IntPtr& vm) [0x00000] in <0f003a4904fd44d0a8cc6a63962ab40b>:0
Renderer (error) >> at Java.Interop.JniEnvironmentInfo.set_EnvironmentPointer (System.IntPtr value) [0x00037] in <0f003a4904fd44d0a8cc6a63962ab40b>:0
Renderer (error) >> at Java.Interop.JniEnvironmentInfo..ctor (System.IntPtr environmentPointer, Java.Interop.JniRuntime runtime) [0x00006] in <0f003a4904fd44d0a8cc6a63962ab40b>:0
Renderer (error) >> at Java.Interop.JniRuntime..ctor (Java.Interop.JniRuntime+CreationOptions options) [0x0017b] in <0f003a4904fd44d0a8cc6a63962ab40b>:0
Renderer (error) >> at Android.Runtime.AndroidRuntime..ctor (System.IntPtr jnienv, System.IntPtr vm, System.Boolean allocNewObjectSupported, System.IntPtr classLoader, System.IntPtr classLoader_loadClass, System.Boolean jniAddNativeMethodRegistrationAttributePresent) [0x00000] in /Users/builder/azdo/_work/4/s/xamarin-android/src/Mono.Android/Android.Runtime/AndroidRuntime.cs:25

In order for the macOS Designer integration tests to succeed,
libxa-internal-api.dylib must be loaded as RTLD_GLOBAL, which is
done via JAVA_INTEROP_LIB_LOAD_GLOBALLY.

[jonpryor]

Related: dotnet/java-interop#691

[jonpryor]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[jonpryor]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[jonpryor]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[jonpryor]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[jonpryor]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[jonpryor]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[radekdoulik]

There is something wrong with warning codes, like in Xamarin.Android.Build.Tests.BuildTest.GeneratorValidateEventName(False,True,"","") test. Where we expect BG8504 warning, but we get BG2138:

  BINDINGSGENERATOR : warning BG2138: Event name for 'Com.Xamarin.Testing.Test.IOn123Listener.SetOn123Listener' is invalid. A valid 'eventName' or 'argsType' can be assigned by adding a rule to the Metadata.xml transforms file. [/Users/runner/work/1/s/bin/TestRelease/temp/GeneratorValidateEventNameFalseTrue/UnnamedProject.csproj]

The Localized message seems to have the right number:

public static LocalizedMessage WarningInvalidEventName => new LocalizedMessage (8504, Java.Interop.Localization.Resources.Generator_BG8504);

@jpobst could you please take a look?

[radekdoulik]

Oh, I see where is the problem. We print it as hexadecimal value, which I guess is not what we want. I will try to fix it.

[radekdoulik]

We have some hexadecimal coded warnings, so I ended up with making the codes as hexdecimal values as well, so that we can print everything the same as before the localization changes.

This PR dotnet/java-interop#697 should fix it and we can update this PR once it is merged.

[jonpryor]

Forgot to also mention: mono/mono#20295