Issue with package encryption/compression


Author
Message
Alan Jones
Alan Jones
StrataFrame Beginner (35 reputation)StrataFrame Beginner (35 reputation)StrataFrame Beginner (35 reputation)StrataFrame Beginner (35 reputation)StrataFrame Beginner (35 reputation)StrataFrame Beginner (35 reputation)StrataFrame Beginner (35 reputation)StrataFrame Beginner (35 reputation)StrataFrame Beginner (35 reputation)
Group: StrataFrame Users
Posts: 7, Visits: 32
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.

Attachments
FIPS Algorithm Overview.txt (239 views, 1.00 KB)
Replies
Trent Taylor
Trent Taylor
StrataFrame Developer (14K reputation)StrataFrame Developer (14K reputation)StrataFrame Developer (14K reputation)StrataFrame Developer (14K reputation)StrataFrame Developer (14K reputation)StrataFrame Developer (14K reputation)StrataFrame Developer (14K reputation)StrataFrame Developer (14K reputation)StrataFrame Developer (14K reputation)
Group: StrataFrame Developers
Posts: 6.6K, Visits: 7K
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.
Alan Jones
Alan Jones
StrataFrame Beginner (35 reputation)StrataFrame Beginner (35 reputation)StrataFrame Beginner (35 reputation)StrataFrame Beginner (35 reputation)StrataFrame Beginner (35 reputation)StrataFrame Beginner (35 reputation)StrataFrame Beginner (35 reputation)StrataFrame Beginner (35 reputation)StrataFrame Beginner (35 reputation)
Group: StrataFrame Users
Posts: 7, Visits: 32
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.

Trent Taylor
Trent Taylor
StrataFrame Developer (14K reputation)StrataFrame Developer (14K reputation)StrataFrame Developer (14K reputation)StrataFrame Developer (14K reputation)StrataFrame Developer (14K reputation)StrataFrame Developer (14K reputation)StrataFrame Developer (14K reputation)StrataFrame Developer (14K reputation)StrataFrame Developer (14K reputation)
Group: StrataFrame Developers
Posts: 6.6K, Visits: 7K
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. Wink
GO

Merge Selected

Merge into selected topic...



Merge into merge target...



Merge into a specific topic ID...





Similar Topics

Reading This Topic

Login

Explore
Messages
Mentions
Search