Issues with package -p zip

[JPHutchins]

The Windows app will run OK on the machine that compiles it, but when unzipped and run on another machine, this error is encountered:

Traceback (most recent call last):
  File "\app\fabuttongui\__main__.py", line 4, in <module>
    main().main_loop()
    ^^^^^^
  File "\app\fabuttongui\app.py", line 131, in main
    return fabuttongui()
           ^^^^^^^^^^^^^
  File "\app_packages\toga\app.py", line 464, in __init__
    self.factory = get_platform_factory()
                   ^^^^^^^^^^^^^^^^^^^^^^
  File "\app_packages\toga\platform.py", line 114, in get_platform_factory
    factory = importlib.import_module(f"{backend.value}.factory")
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "importlib\__init__.py", line 90, in import_module
  File "<frozen importlib._bootstrap>", line 1387, in _gcd_import
  File "<frozen importlib._bootstrap>", line 1360, in _find_and_load
  File "<frozen importlib._bootstrap>", line 1310, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 488, in _call_with_frames_removed
  File "<frozen importlib._bootstrap>", line 1387, in _gcd_import
  File "<frozen importlib._bootstrap>", line 1360, in _find_and_load
  File "<frozen importlib._bootstrap>", line 1331, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 935, in _load_unlocked
  File "<frozen importlib._bootstrap_external>", line 994, in exec_module
  File "<frozen importlib._bootstrap>", line 488, in _call_with_frames_removed
  File "\app_packages\toga_winforms\__init__.py", line 1, in <module>
    import clr
  File "\app_packages\clr.py", line 6, in <module>
    load()
  File "\app_packages\pythonnet\__init__.py", line 143, in load
    func = assembly.get_function("Python.Runtime.Loader.Initialize")
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "\app_packages\clr_loader\types.py", line 94, in get_function
    return ClrFunction(self._runtime, self._path, name, func)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "\app_packages\clr_loader\types.py", line 58, in __init__
    self._callable = runtime._get_callable(assembly, typename, func_name)
                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "\app_packages\clr_loader\netfx.py", line 47, in _get_callable
    raise RuntimeError(
RuntimeError: Failed to resolve Python.Runtime.Loader.Initialize from \app_packages\pythonnet\runtime\Python.Runtime.dll
'''

If we go to that file and "unblock" it, then a new error is produced:

'''

System.NotSupportedException: An attempt was made to load an assembly from a network location which would have caused the assembly to be sandboxed in previous versions of the .NET Framework. This release of the .NET Framework does not enable CAS policy by default, so this load may be dangerous. If this load is not intended to sandbox the assembly, please enable the loadFromRemoteSources switch. See http://go.microsoft.com/fwlink/?LinkId=155569 for more information.

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "\app\fabuttongui\__main__.py", line 4, in <module>
    main().main_loop()
    ^^^^^^
  File "\app\fabuttongui\app.py", line 131, in main
    return fabuttongui()
           ^^^^^^^^^^^^^
  File "\app_packages\toga\app.py", line 464, in __init__
    self.factory = get_platform_factory()
                   ^^^^^^^^^^^^^^^^^^^^^^
  File "\app_packages\toga\platform.py", line 114, in get_platform_factory
    factory = importlib.import_module(f"{backend.value}.factory")
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "importlib\__init__.py", line 90, in import_module
  File "<frozen importlib._bootstrap>", line 1387, in _gcd_import
  File "<frozen importlib._bootstrap>", line 1360, in _find_and_load
  File "<frozen importlib._bootstrap>", line 1331, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 935, in _load_unlocked
  File "<frozen importlib._bootstrap_external>", line 994, in exec_module
  File "<frozen importlib._bootstrap>", line 488, in _call_with_frames_removed
  File "\app_packages\toga_winforms\factory.py", line 18, in <module>
    from .widgets.mapview import MapView
  File "\app_packages\toga_winforms\widgets\mapview.py", line 12, in <module>
    from toga_winforms.libs.extensions import (
  File "\app_packages\toga_winforms\libs\extensions.py", line 15, in <module>
    clr.AddReference(os.path.join(WEBVIEW2_DIR, "Microsoft.Web.WebView2.Core.dll"))
System.IO.FileLoadException: Could not load file or assembly 'file:///\app_packages\toga_winforms\libs\WebView2\Microsoft.Web.WebView2.Core.dll' or one of its dependencies. Operation is not supported. (Exception from HRESULT: 0x80131515)
File name: 'file:///\app_packages\toga_winforms\libs\WebView2\Microsoft.Web.WebView2.Core.dll' ---> System.NotSupportedException: An attempt was made to load an assembly from a network location which would have caused the assembly to be sandboxed in previous versions of the .NET Framework. This release of the .NET Framework does not enable CAS policy by default, so this load may be dangerous. If this load is not intended to sandbox the assembly, please enable the loadFromRemoteSources switch. See http://go.microsoft.com/fwlink/?LinkId=155569 for more information.
   at System.Reflection.RuntimeAssembly._nLoad(AssemblyName fileName, String codeBase, Evidence assemblySecurity, RuntimeAssembly locationHint, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks)
   at System.Reflection.RuntimeAssembly.InternalLoadAssemblyName(AssemblyName assemblyRef, Evidence assemblySecurity, RuntimeAssembly reqAssembly, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks)
   at System.Reflection.RuntimeAssembly.InternalLoadFrom(String assemblyFile, Evidence securityEvidence, Byte[] hashValue, AssemblyHashAlgorithm hashAlgorithm, Boolean forIntrospection, Boolean suppressSecurityChecks, StackCrawlMark& stackMark)
   at System.Reflection.Assembly.LoadFrom(String assemblyFile)
   at Python.Runtime.AssemblyManager.LoadAssemblyFullPath(String name) in /tmp/build-via-sdist-h3j67_wc/pythonnet-3.0.3/src/runtime/AssemblyManager.cs:line 255
   at Python.Runtime.CLRModule.AddReference(String name) in /tmp/build-via-sdist-h3j67_wc/pythonnet-3.0.3/src/runtime/Types/ClrModule.cs:line 111
'''

Hoping to be able to use the portable as it has a few advantages for us!

Thanks for looking!

JP

[freakboy3742]

Thanks for the report. I haven't seen that one before; I'm guessing the MSI installer is setting whatever flags are required as part of the installation process. I can't say I know what the workaround for this is (other than the manual unblock that you've already found).

I'm guessing the fix will be one of two things:

1. Modifying the stub to allow for unsafe loads. It's not clear to me from the docs pages that are linked in the error message where we'd need to set that flag
2. Modify the python.net usage of clr.AddReference() to allow an "unsafe load" of the Python and WebKit binaries.

If you're able to find a programmatic change that makes this work, I'm happy to integrate it into Briefcase.

[JPHutchins]

OK, that makes sense! We're testing the MSI and it may work for us.

Does briefcase provide a hook to the user documents or desktop folder by chance? I'm saving some files to the relative path and sorta puzzled about where exactly they are ending up!

[freakboy3742]

Briefcase doesn't provide any paths, because that's not really in scope for Briefcase; but Toga does, using the paths attribute on the application. That doesn't currently expose a "Documents" path - but it would make sense to expose one (likewise for some other common paths, like Desktop and Pictures).

If you're using a relative path in a Toga app that has been packaged with Briefcase, you should find they're being stored in the User's home directory (pathlib.Path.home()) unless there's something else mess with the current working directory.

[rmartin16]

This looks like Windows' "mark of the web" "feature". This is a problem for the ZIP because the provenance of the DLLs is being tracked as the ZIP is moved from machine to machine while the MSI intentionally doesn't mark the DLLs as foreign.

I was able to bypass both of these errors, though, by adding the content below to a file named <App Formal Name>.exe.config alongside my <App Formal Name>.exe file:

<configuration>
   <runtime>
      <loadFromRemoteSources enabled="true"/>
   </runtime>
</configuration>

Alternatively, you can remove the mark of the web using the Unblock option in properties for all the DLLs included in the ZIP...but that'd have to be done each time the ZIP is extracted.

[JPHutchins]

Well, $%&*(#%, they were only letting me use it for free before it was released. It's to the point where OSS shouldn't even run on Windows. They won't let me provide authenticated packages without paying ransom even though there are myriad solutions available.

[JPHutchins]

I've been using cosign lately and that infrastructure seems fine.

[rmartin16]

Does signing work for these "portable" ZIPs?

It should; the signing process will just sign the stub exe using a cert store certificate for ZIP packaging.

[JPHutchins]

If the exe is signed, how is the authenticity of all the python source files verified?

[rmartin16]

Currently, the Python source code for the app isn't authenticated; even with the MSI package, it is signed but once the Python source is installed, it is not verified before running.

I'd say the main issue is Python doesn't provide a mechanism to verify any sort of signature for a module before importing it. So, I think we'd need to make our own import loader (or possibly leverage an existing implementation) to do this.

[MarkusPiotrowski]

Maybe this is a dumb question: But when is the "Mark of the Web" added to the file? E.g. when I unpack the ZIP on the same computer where it was packed and copy this to a USB stick, would the exe then run (from the stick) on a different computer? And when I then copy the folder to the other computer?

[rmartin16]

when is the "Mark of the Web" added to the file?

The MotW is applied at the time a file is fetched from a remote server. Notably, though, this is not an automatic process; each piece of software that can create files from remote content must apply this mark. Furthermore, propagating the mark from a bundled and/or compressed file itself (such as a ZIP) to the extracted uncompressed files must be supported by the decompression software.

when I unpack the ZIP on the same computer where it was packed and copy this to a USB stick, would the exe then run (from the stick) on a different computer?

Maybe; in this situation, MotW probably won't apply. Instead, I would expect other protections around running and loading code from removable media to kick in.

when I then copy the folder to the other computer?

As the file is from a remote server, I would expect this to apply MotW...especially if you use Windows Explorer to copy the files. Alternatively, if you used an ancient file transfer software, I probably wouldn't expect the files to have the mark.