Open xantari opened 6 days ago
Hi @xantari Thank you for using kiota and for reaching out.
This is unintended, in the meantime you can use the release distribution since it's properly signed.
For others picking this up, we need to:
Which is roughly what we're doing around here but either the sign step does not drop the exe at the expected place pack is looking, or pack is triggering a new build somehow.
Just double checking here @baywet, @xantari
Are we saying the nuget published packages are not signed while the GH ones are? From an initial look, it looks like the only thing we don't sign are the linux artifacts. DLLs/Exe's look signed though..
@andrueastman yes I checked the signature for the windows release (it's signed) but the tool once installed is not.
Is your feature request related to a problem? Please describe the problem.
We run in a high security environment. Only applications signed with a code signing certificate that are whitelisted (via Windows AppLocker) are allowed to run.
All Kiota .exe's however are unsigned, so there is no easy way to whitelist Kiota .exe files because each version change of Kiota changes the file hash.
Whitelisting by code signing certificate is the best way to whitelist in high security AppLocker environments.
Client library/SDK language
Csharp
Describe the solution you'd like
All kiota .exe files should be signed with the Microsoft code signing certificate. Right now the big one is kiota.exe.
Microsoft signs most .exe's, such as dotnet-ef.exe (for entity framework) found in C:\Users\profilename\.dotnet\tools when it is installed as a global .net core tool.
I am requesting you do the same for Kiota so that we can start to use this tool in our environment.
Additional context
No response