Guys,
In our installation we've run into an issue on deploying data to machines with a specific local security policy. 

The policy:
System cryptography: Use FIPS compliant algorithms for encryption, hashing and signing

When I enable this policy on my machine, I am unable to open any of our package files (no encryption) because of the compression being used. 
Get the generic message:
PackageIt has encountered a problem and needs to close.  We are sorry for the inconvenience.

Our installation will be for government machines, many of which will likely have this option set.  Programmatically we can turn off this setting IF local policy allows it, but there is a very real chance this won't be the case. 

Are there any settings you have within the DDT or PackageIt! that you can change to make the data packages FIPS compliant?

I've attached an overview of the policy if it helps.

I will test this to see if it is reproducable. There are going to be some things that are out of our control. However, that being said, let me first see if we can reproduce this issue and I will get back with you. Just FYI, within the PKG file, we are using GZIP technology for the compression. My guess is that this is where the sore spot is. But I will investigate and get back with you...this is the first we have ever heard of this. Also, we have a large number of government agencies, including the Department of Defense using the DDT deployment packages, and to date, this is the first time this type of thing has ever come up.

Alan,



I have found a number of articles on this. Most of them elude to loading .NET 2.0 SP1 or .NET 3.5. Have you tried this? Here is one example:



http://forum.kadonk.com/index.php?showtopic=90

I am finding that virtually no .NET application runs immediately after turning this on. Will take some time to investigate. Saw several hotfixes through the Microsoft MSDN area (http://code.msdn.microsoft.com/KB935434 for example). But not all reference or apply to the same logic.

Trent,
Thanks for the posts.  Our installation does install .Net 3.5 if it is not present.  However on the preconfigured Army systems the local policy is still enforced even if we have .Net 3.5.  We are planning on displaying a message to the system admins who will be installing that we are attempting to disable it.  If we are unable to do so, then it will at least be in the sys admin's hands to find a way to deal with that policy.

I don't think there's much that can be done, other than hoping our installation can disable it and then reenable it.  It doesn't seem to hinder our application once it is installed. 

If nothing else, keep it in mind.  I can see where this can cause lots of problems for data deployment and even the general Strataframe user.  Even changing it on my machine makes the DDT unusable - I get a license not activated message.

Well, since it came up it is on our radar. But at this point, we are many thousands of installations deep and this is the first time it ever came up. So though it is something that we will definitely need to check into, I would be surprised if this was extremely wide spread. Thanks for the heads up.

Trent,

This setting is a DISA (Defense Information Systems Agency) setting that will be implemented on all DOD (Department of Defense) servers and workstations in the near future. We have a disk from DISA that gives us all the security settings that will be changed on XP and Vista operating systems in the very near future (rollout has started). This will be affecting all of us who develop software for DOD customers.

The registry key setting is disabled on default installations of the OSs. The DISA disk will flip this setting to enabled. This changes the encryption type from RSA to 3DES I believe. When changing this a lot of items stop functioning correctly, even parts of the OS itself.

If you set this registry setting to enable(1) on your workstation and try to run the DDT application you will get the message that your software is not activated. If you switch this back to disabled(0), things are well again.

We will all be facing this issue very soon with all DOD customers. Could you please do more research and help us determine what we will have to change to get the SF based applications to function correctly with these settings.

I have other security settings that will have an effect on DOD customers but they are too many to talk about in this post. One other example: DOD is not going to allow any application to execute from the users TEMP folder to prevent any unwanted application executions. This may affect installation programs and data deployment routines from working.

Thanks in Advance

We will look into this...however, cursory glances indicate that there could be very little that we can do. We have already reproduced this in house, but there are some inherent issues with this security policy that exceed the control that we have over the OS and .NET in general. Again, this effects more than the DDT, it effects virtually all .NET applications. We will be looking into this.