|
mio
Guest
|
Dear ADX team,
We are currently facing a critical issue in our software (add-in) and urgently need your assistance.
tl;dr: Toggling the "enforceFIPSPolicy" configuration switch in the runtime configuration is ignored in the configuration file the add-in loader refers to in its manifest, but is working as expected, if set in a configuration file next to the host application.
A customer wants to use our software but is experiencing exceptions that arise from the FIPS policy (https://docs.microsoft.com/en-us/windows/security/threat-protection/fips-140-validation), which is enabled on their Windows machines, company-wide. If this policy is enabled, the .NET runtime (and the operating system) only allows to use specific crypographic algorithms - other cryptographic algorithms (or rather: their "un-tested" implementations, e.g. RijndaelManaged) throw exceptions upon initialization.
We agreed on "resolving" this issue by disabling the enforcement of this policy through a configuration switch for the .NET runtime: https://docs.microsoft.com/de-de/dotnet/framework/configure-apps/file-schema/runtime/enforcefipspolicy-element
Unfortunately, adding this switch to the app.config (actually: %assemblyName%.config) does not appear to work for add-ins, unless this configuration file is placed next to the host application's executable and renamed to match the name of the host application (e.g. "winword.exe.config") - we validated this by toggling the switch on and off in that configuration file, and noticed that this indeed does prevent the exceptions from being thrown depending on the value of the switch. Placing the configuration file next to the host application obviously is no viable solution for a production environment, though.
We already made sure the %assemblyName%.config file is generally working for our add-in. The config file's name is correctly referenced in the adxloader.manifest, and removing some of the binding redirects defined in there breaks our add-in.
Could you please help and give some advice
Thanks. |
|
|
Andrei Smolin
Add-in Express team
Posts: 18825
Joined: 2006-05-11
|
Hello Fabian,
Some settings belongs with the host application, not with the add-in. These are .NET-wide or, better, application-wide settings. While the add-in's config is AppDomain-wide. If the .NET is already initialized, you can't reinitialize it. I assume this may mean that the policy setting may work if your add-in loads first; check if this this is so when your add-in is the only add-in loading. If this doesn't work, you'll have to use the host's config.
Andrei Smolin
Add-in Express Team Leader |
|
|
mio
Guest
|
Hi Andrei,
even if the addin is the only addin that is loaded the configuration is not applied.
There is no way in Add-in Express to apply configurations for the runtime?
Adding files to the office installation directory is not an acceptable solution. |
|
|
Andrei Smolin
Add-in Express team
Posts: 18825
Joined: 2006-05-11
|
Hello Fabian,
The add-in's .config is part of the add-in's AppDomain. There are global things that get initialized before the AppDomain is created: once initialized, they cannot be changed.
> Adding files to the office installation directory is not an acceptable solution.
I understand this. But I don't see any other way. .NET targets EXEs. You configure .NET for use in an EXE via the EXE's config file.
Andrei Smolin
Add-in Express Team Leader |
|
Forums
Topics
Search
Help
Login
Register