I'm developing an Electron app and the current build is ready to be rolled out. I have enabled the audit mode on a virtual machine.
This is the error I am getting in the Event viewer:
Code Integrity determined that a process (<path_to_system32>\svchost.exe) attempted to load <path_to_app>\my_app.exe that did not meet the Custom 1 signing level requirements or violated code integrity policy (Policy ID:{a244370e-44c9-4c06-b551-f6016e563076}). However, due to code integrity auditing policy, the image was allowed to load.
I've installed this app with his .appx. Get-AuthenticodeSignature says that my signed appx is valid.
If I run my Get-AuthenticodeSignature in the installed folder, my exe is not signed, the dlls however are correctly signed.
My second error messages looks a little bit different:
Code Integrity determined that a process (<path_to_app>\my_app.exe) attempted to load <path_to_app>\<some_dll>.dll that did not meet the Custom 1 signing level requirements or violated code integrity policy (Policy ID:{a244370e-44c9-4c06-b551-f6016e563076}). However, due to code integrity auditing policy, the image was allowed to load.
The <some_dll> are ffmpeg.dll, d3dcomiler_47.dll, swiftshader/libGLESv2.dll and swiftshader/libEGL.dll.
my package.json looks like this:
"appx": {
"identityName": "company.myapp",
"backgroundColor": "#FFFFFF",
"publisher": "CN=company, O=company, STREET=xxxx, L=yyyy, S=zzzz, PostalCode=1234, C=xx",
"publisherDisplayName": "company",
"displayName": "myapp",
"languages": [
"nl",
"en",
"fr"
]
},
"win": {
"target": "nsis",
"icon": "icons/icon.ico",
"publisherName": "Company",
"certificateFile": "./certs/certificate.p12",
"certificatePassword": "mypassword",
"certificateSubjectName": "company",
"signAndEditExecutable": true,
"signDlls": "true",
"sign": "./customSign.js",
"extraResources": [
"electron/bin/*.exe"
],
"verifyUpdateCodeSignature": true
}
Related
My app was constructed using Python and Pyinstaller and utilizes both tkinter and PyQt5. Codesign produces no error messages and I'm able upload it for notarization, but notarization fails.
The LogFileURL produces 24 error messages, all indicating a binary was not signed or the signature does not contain a valid timestamp. Here are two examples:
{
"severity": "error",
"code": null,
"path": "My_Application.zip/My_Application.app/Contents/Resources/PyQt5/Qt/qml/QtQuick.2/libqtquick2plugin.dylib",
"message": "The binary is not signed.",
"docUrl": null,
"architecture": "x86_64"
}
,and
{
"severity": "error",
"code": null,
"path": "My_Application_10_7.zip/My_Application_10_7.app/Contents/Resources/PyQt5/Qt/qml/QtQml/WorkerScript.2/libworkerscriptplugin.dylib",
"message": "The signature does not include a secure timestamp.",
"docUrl": null,
"architecture": "x86_64"
}
What's common about all the errors is that the dylib resides in a subdirectory of PyQt5 whose name contains a period.
Ben Hagen describes how such a presence of periods can prevent signing and provides a workaround script at https://github.com/pyinstaller/pyinstaller/wiki/Recipe-OSX-Code-Signing-Qt. I used this tool to get my app signed successfully. But somehow I need to do something more prior to uploading for notarization.
When I launch in VSCode dlv debug, I get this message:
User specified 'dlvLoadConfig' setting will be ignored by debug
adapter 'dlv-dap'.
Source is Go Nightly extension.
have dlvLoadConfig config section already become unavailable (obsolete)?
launch.json :
"configurations": [
{
"name": "Application Server",
"type": "go",
"request": "launch",
"mode": "auto",
"program": "${workspaceFolder}/cmd/main.go",
"args": ["--config", "${workspaceFolder}/configuration/application.toml"],
"env": {
"CC":"/usr/bin/gcc",
"GOOS":"linux",
"GOARCH":"amd64",
"CGO_ENABLED":1
},
"dlvLoadConfig": {
"followPointers": true,
"maxVariableRecurse": 1,
"maxStringLen": 1024,
"maxArrayValues": 64,
"maxStructFields": -1
},
"trace": "log"
// "buildFlags": "-tags dev -ldflags '-X main.BuildDate=2021-04-28T19:38:16+03:00'"
}
]
You might need to update your configuration as mentioned here:
https://github.com/golang/vscode-go/blob/master/docs/debugging.md#switching-to-legacy-debug-adapter
https://github.com/golang/vscode-go/blob/master/docs/debugging.md
(from :https://github.com/golang/vscode-go/blob/master/docs/dlv-dap.md )
"go.delveConfig": {
"debugAdapter": "legacy",
}
On a side note, installing the latest didn't seem to copy the binary as dlv-dap (which seems to be expected by vscode) I just created a sym link to dlv (mac-osx), and it works in dlv-dap mode
ln -s dlv dlv-dap
Adding "debugAdapter" works for me too.
"debugAdapter": "legacy",
https://github.com/golang/vscode-go/blob/master/docs/debugging.md#settings
The new dlv-dap takes a completely different approach in loading data, so dlvLoadConfig is no longer necessary.
For string values, it uses 512 or 4K depending on the context as of Aug 2021. (512 for display in the VARIABLES section, 1K for function call results, 4K if you query the variables from the DEBUG CONSOLE or use COPY VALUE)
I noticed you were using maxStringLen: 1024 in your settings. We are currently considering to increase the limit of how much we show in the VARIABLES section. We are increasing this slowly and conservatively because it causes loading a lot of data for all variables automatically and it can slow down the debugging performance. If inspecting long string variables from DEBUG CONSOLE (on demand) is not sufficient, please open a new issue in the github.com/golang/vscode-go repo.
I have recently started debugging the mserver5 application using vscode and a very comfy plugin for cmake called CMake Tools. Moreover, I am using gcc 9.3.0 (Ubuntu 9.3.0-17ubuntu1~20.04) as a compiler together with the following launch.json debug configuration for mserver5 in vscode:
{
"version": "0.2.0",
"configurations": [
{
"name": "(gdb) mserver5 triangleDB",
"type": "cppdbg",
"request": "launch",
// Resolved by CMake Tools:
"program": "${command:cmake.launchTargetPath}",
"args": ["--dbpath=/home/mledl/dbfarm/triangleDB", "--set", "mapi_port=0"],
"stopAtEntry": false,
"cwd": "${workspaceFolder}/build",
"environment": [
{
// add the directory where our target was built to the PATHs
// it gets resolved by CMake Tools:
"name": "PATH",
"value": "$PATH:${command:cmake.launchTargetDirectory}"
},
],
"externalConsole": true,
"MIMode": "gdb",
"setupCommands": [
{
"description": "Enable pretty-printing for gdb",
"text": "-enable-pretty-printing",
"ignoreFailures": true
},
{ "description":"In this mode GDB will be attached to both processes after a call to fork() or vfork().",
"text": "-gdb-set detach-on-fork off",
"ignoreFailures": true
},
{ "description": "The new process is debugged after a fork. The parent process runs unimpeded.",
"text": "-gdb-set follow-fork-mode child",
"ignoreFailures": true
}
]
}
]
}
The database I am connecting to (here triangleDB) has been created within a dbfarm using the monetdb application and I am going to connect to it using the mclient application with the default username and password combination monetdb. I can successfully connect to and query my triangleDB when starting it using the monetdb application withing a running dbfarm.
When starting up the mserver5 for debugging from vscode using the above launch.json file and connecting to it using mclient and the monetdb user I cannot authenticate somehow and get the following error printed to the mserver5 logs:
client1: createExceptionInternal: !ERROR: InvalidCredentialsException:checkCredentials:invalid credentials for user 'monetdb'
Does anybody know why mserver5 cannot retrieve the default user? Does it rely on the deamon monetdbd to retrieve the user data from? Can someone tell me what I am missing or how I can efficiently debug the mserver5?
Another point is that I need to set mapi_port=0 in order to make mserver5 bind to available ports since it is opening two mapi connections somehow when debugging with vscode and CLion. The application crashes when using a specific port since the second binding attempt will be on an already use address. The following section shows that two connections are opened when debugging:
# MonetDB 5 server v11.40.0
# This is an unreleased version
# Serving database 'triangleDB', using 24 threads
# Compiled for x86_64-pc-linux-gnu/64bit with 128bit integers
# Found 31.349 GiB available main-memory of which we use 25.549 GiB
# Copyright (c) 1993 - July 2008 CWI.
# Copyright (c) August 2008 - 2021 MonetDB B.V., all rights reserved
# Visit https://www.monetdb.org/ for further information
# Listening for connection requests on mapi:monetdb://localhost:46093/
# Listening for connection requests on mapi:monetdb://localhost:40387/
Thanks in advance for everybody that can help me out on this one. Looking forward to hearing from you and sty safe everyone.
If your database was created using monetdb and you want to start it directly using mserver5, you need to tell mserver5 where the .vaultkey is.
In you dbfarm, do a grep monet_vault_key merovingian.log, copy the whole --set monet_vault_key=/<path-to>/dbfarm/demo/.vaultkey and add this option to the start-up command of your mserver5.
I am giving an additional answer here, because I want to make clear what I had to do in order to debug the mserver5 using vscode and interact with it using the mclient application.
While trying to figure out why certain modules/libraries could not be loaded, I noticed that the GDK kernel is missing an environment variable called monet_mod_path which can be set using the --set monet_mod_path=/usr/local/lib/monetdb5 option for mserver5. The missing monet_mod_path has also been the reason why mserver5 listened on two addresses for a mapi connection.
I am now using the following command to start mserver5 for debugging:
mserver5 --dbpath=/home/mledl/dbfarm/triangleDB --set monet_vault_key=/home/mledl/dbfarm/triangleDB/.vaultkey --set monet_mod_path=/usr/local/lib/monetdb5 --set gdk_nr_threads=24 --set max_clients=64 --set sql_optimizer=default_pipe
A minimal working configuration would be the following one:
mserver5 --dbpath=/path/to/your/db --set monet_vault_key=/path/to/your/db/.vaultkey --set monet_mod_path=/usr/local/lib/monetdb5
Note: I installed the application into default installation directory. If you choose a custom one the monet module path has the following pattern:
monet_mod_path=/path/to/install/lib/monetdb5
I hope this answer will help someone in the future and saves all the investigation time I had to put in.
I was trying to setup debug configuration to attach to already running gdbserver.
(ref used: https://code.visualstudio.com/docs/cpp/launch-json-reference)
[Note. I can attach and debug with an arch specific gdb instance fine to the gdbserver]
That's the template that has logic check deadlock.
{
"name": "(gdb) Attach to gdbserver in QEMU",
"type": "cppdbg",
"request": "attach",
"MIMode": "gdb",
"miDebuggerPath": "/path/to/gdb/../../bin/mips-mti-linux-gnu-gdb",
"miDebuggerServerAddress": "localhost: 1234",
"program": "${workspaceFolder}/__out--MIPS64r6_MTI/vmlinux",
// "processId": "${command:none}",
// "processId": "${command:pickProcess}",
// "processId": "23739",
"setupCommands": [
{
"description": "Enable pretty-printing for gdb",
"text": "-enable-pretty-printing",
"ignoreFailures": true
}
]
},
When no "processId" given, it complains:
unable to parse process id
When some valid "processId" given (and then some process also selected from the list, if demanded by UI), it complains:
'processId' cannot be used with miDebuggerServerAddress
Does anyone know how to resolve this deadlock in VC debug config parsing logic or this is a bug?
Thank you.
Ok. After several tries it worked ;)
Using the "request": "launch" (despite sounds a bit illogical, as we're attaching to already running process, just supplied with gdbserver i-face) without "processId" as advised in #577 bug discussion, the DB session was braking up initially with complain:
remote replied unexpectedly to 'vMustReplyEmpty': timeout, but eventually worked after repeated tries ;)
Note. For "lanuch" case, VC demanded also adding: "cwd": "${workspaceRoot}"
The VC+CPP-plugin support needs updating the instructions then (https://code.visualstudio.com/docs/cpp/launch-json-reference).
It sounds really illogical to use "request": "launch" to actually do the attach action :).
I installed my Electron Windows App on a fresh Windows 10, Windows Server 2016 Standard and Windows Server 2012 R2 Build 9600 and it is working fine. The connection to my websocket is also working.
On some machines with Windows Server 2016 Standard the app is not working as expected. I am just getting the windows border of the app but no content nor a menu. But the websocket connection of my app is working. ( i checked it with wireshark). so i guess it is a rendering problem?
Sadly i don't have access to the machines where the problem exists.
I assume same packages are missing?
screenshot with rendering problem:
Electron 5.0.2
Electron Store 3.2.0
Electron Prompt 1.3.1
I had the same issue as you mentioned, I solved it by generating a 32bit version of my Electron app for that Windows Server it did not work on.
Here is my build snippet from my package.json to generate both a 64 and a 32 bit version.
"build": {
"appId": "com.example.app",
"productName": "app",
"copyright": "Copyright © 2019",
"files": [
"build/**/*",
"node_modules/**/*"
],
"directories": {
"buildResources": "assets"
},
"win": {
"target": [
{
"target": "portable",
"arch": [
"x64",
"ia32"
]
}
],
"icon": "assets/app.ico"
}
},