jacraig / craig-s-utility-library Goto Github PK

Hello,

Does Craig Utilities supports SHA256Managed with Salt and Repetitions?

Thank you,
Miguel

A number of these items are completely changed and will need to be rewritten:

1. Compression - Not 100% sure if GZip or Deflate is available in .Net Core. Need to look into this.
2. FileFormats - This needs to be reworked anyway to try to make things a bit more uniform and changed more to a factory/generator setup (you ask for a generator, give the generator the data, generator converts to/from the file format).
3. FileSystem - This just needs changes to work with .Net Standard. This may mean no more FileInfo, etc. features depending on the level of .Net Standard used. FTP and HTTP may also not be available, but more research needed.
   4, Logging - Just needs to be updated for the new FileSystem.
4. Messaging - Email isn't in .Net Core... So ???
5. Serializers - This just needs to be joined with the file formats section. They're just a file type and should be treated that way.

Other portions should be dropped/broken off into their own thing:

1. Encryption - This really needs to be its own thing and reworked.

The file system is pretty much a given to move over. May have to drop the http/ftp code though.

So System.Data had a number of changes but thankfully I did not use many of them. So it should be fairly straight forward. Most of the changes here will be actual enhancements in capabilities.

A couple of changes that are needed:

1. .Net Core doesn't support Domains at the moment. So figuring out what assemblies are loaded is not possible and needs to be supplied to the Bootstrapper class.
2. GetType() no longer gets a type's info in full. So some changes needed for GetTypeInfo().
3. ASP.Net Core's IoC container uses scopes which the current set of classes don't really use. So adding functionality that is compatible is needed.

I have a library on bitbucket that deals with file formats plus the ones here. Find out what I can move over and just push it over. Should be pretty straight forward for most of them.

Once again it should be straightforward. However thanks to Sundial, I have a number of improvements that I would like to make. Most notably I would like it to be easier to track metrics other than time in the system (memory, CPU, etc).

See here: https://github.com/JaCraig/Craig-s-Utility-Library/blob/master/Utilities/IO/Encryption/BaseClasses/SymmetricBase.cs#L159

This method doesn't include any type of authentication, to be secure, a MAC should be applied. This answer goes into some detail about what you should be doing here.

If you don't authenticate the ciphertext, an attacker can make simple changes to it, and when decrypted, will change the content of the encrypted message. So it's important to ensure the integrity of the message before decrypting it.

Logging code is pretty simple. Shouldn't be too difficult to move over once the file system code is in place.

Going to have to basically write a wrapper for something that can send an email in .Net Core... No idea on this one.

The MathExtensions.Median() function doesn't adhere to the statistical definition of median, that can be found on Wikipedia. This definition states that the value choosen depends on the value count:

If there is an odd number of numbers, the middle one is picked.

If there are an even number of observations, then there is no single middle value; the median is then usually defined to be the mean of the two middle values.

Current implementation takes the value at count / 2, that differs when value count is even with the above definition. When the value count is odd, the current implementation ok.

Generally speaking I feel these items should be removed from CUL and moved to Ironman. It's really only useful for ASP.Net and I would like to break those items off into the appropriate library.

Most of the validation code is fine. IClientValidatable may need to be changed as I do not know if it is available in ASP.Net Core. That said it should be removed anyway to move the code away from ASP.Net specific.

No binary but the rest should be movable.

Hello can you update to core 3.1

See here: https://github.com/JaCraig/Craig-s-Utility-Library/blob/master/Utilities/IO/Encryption/BaseClasses/SymmetricBase.cs#L140

This code sets the default iteration count to a value well below the recommended values - see here for some well known values. The default value, if one is supplied, should be in the thousands - not the two it's currnetly set to.

The default value is set so low that it provides practically no additional value.

Most NuGet packages for the library are currently at version 4.0.304. CraigsUtilityLibrary-FileFormats is still at 3.4.199, though, and requires the DataTypes and IO packages to be at exactly 3.4.199 as well. That means those cannot be updated to their current versions as long as the FileFormats package is installed.

Would it be possible to re-publish the FileFormats package as version 4.0.304, so the rest of the packages can be used in their most recent versions?

I've never really been happy with the current system and I'm not sure what is available in .Net Core/Standard. So this is getting broken off most likely.

IoC Manager attempts to load a native DLL thinking it is a Managed DLL.

System.BadImageFormatException: Could not load file or assembly 'freetype6.dll' or one of its dependencies. The module was expected to contain an assembly manifest.
   --- End of inner exception stack trace ---
   at System.Reflection.AssemblyName.nGetFileInformation(String s)
   at System.Reflection.AssemblyName.GetAssemblyName(String assemblyFile)
   at Utilities.IoC.Manager.<>c.<LoadAssemblies>b__13_2(FileInfo x) in Manager.cs:line 167
   at System.Linq.Enumerable.WhereSelectListIterator`2.MoveNext()
   at System.Linq.Buffer`1..ctor(IEnumerable`1 source)
   at System.Linq.Enumerable.ToArray[TSource](IEnumerable`1 source)
   at Utilities.IoC.Manager.LoadAssemblies() in Manager.cs:line 167
   at Utilities.IoC.Manager..ctor() in Manager.cs:line 44
   at Utilities.IoC.Manager..cctor() in Manager.cs:line 64

Pretty much just work on reducing the amount of memory creation and reduce the number of assemblies it looks in. Should reduce the amount of time it takes to boot up.

So System.Drawing isn't in .Net Core other than a couple of the data types... So a library is needed to read/write images and give access to the pixels. There is ImageProcessor but it's slow and has some weird choices that they've made. On top of that we really just need the Core portion. Finding a decent .Net item that could be used is difficult to find so I have been writing my own library to handle this portion of the code based on the ImageProcessor's Core code but fixing their issues. Once that is done the rest of the code can be moved over without too many issues.

See here: https://github.com/JaCraig/Craig-s-Utility-Library/blob/master/Utilities/IO/Encryption/BaseClasses/SymmetricBase.cs#L140

This code supplies a default salt of Kosher - this use defeats the purpose. Please here here for a detailed discussion of how salts should be applied - the key point is that to be effective, they should be random. Relying on a fixed or default salt defeats the purpose.

I would suggest removing the default, and add a method to generate a random salt using a CSPRNG.

See here:

...
        public byte[] Encrypt(byte[] Data, string Key,
            string Algorithm,
            string Salt = "Kosher",
            string HashAlgorithm = "SHA1",
            int PasswordIterations = 2,
            string InitialVector = "OFRna73m*aze01xY",
            int KeySize = 256)
        {
...

The use of a default initialzation vector is a security flaw - see here for a breakdown of why this is a bad idea, that document goes into detail for how IVs should be handled for CBC mode, so I won't repeat it all here.

To protect the integrity of encrypted data, this default IV should not be used.

I'm not 100% happy with this portion of the library. That said it should move over pretty easily. I just need to rework the system into something a bit simpler.

1. ContactInfoGenerators/NameGenerators/StringGenerators - It's difficult to get to these items or discover them. So it needs to be simplified.
2. Random - Most of the generators themselves should be fine but the Random class itself needs to be simplified.

https://github.com/JaCraig/Craig-s-Utility-Library/tree/3.4.0199/Utilities.Environment/Environment

Not exactly .Net Core usable but may still be useful.

I'm not certain if Deflate or GZip are in .net core or .net standard. So... This may be something that gets broken off into its own thing.

https://github.com/JaCraig/Craig-s-Utility-Library/tree/3.4.0199/Utilities.LDAP

Once again, may have uses.

Most of the changes will be related to the IO portion of the library. The main changes will be the SystemConfig, JsonConfig, XMLConfig, etc. That said many of the classes may not be needed as most of this can be moved into the FileFormats portion of IO. Obvious exceptions are the SystemConfig class which needs to be changed to remove System.Web references.

This is where things crash and burn a bit with the new .Net Core stuff. Moving to .Net Standard will require a bunch of work on a number of items:

1. AOP - This relies on Roslyn to generate the code. This has changed a bit but generally still should work without too many issues.
2. Caching - Most of the changes are related to ASP.Net Core. The default cache should just be an in memory cache and the other items are broken off as plugins based on the platform.
3. CodeGen - the Roslyn portion of the AOP generator. This is the part that will need to change.
4. Comparison - Actually pretty standard and good to go.
5. Conversion - The converters will need to be changed but otherwise it is pretty straight forward.
6. DataMapper - Most of the changes will be related to GetType and changes to type conversion.
7. Extensions - Each of the extensions needs to be looked at but most should be able to move over. A bigger issue is the fact that many of them are no longer needed thanks to changes in C#.
8. Formatters - Should be able to move it over.
9. Patterns - Should be able to move it over.
10. Dynamo - This will take a big set of changes but most of it will be related to the items up the list.
11. Other classes - Should be pretty simple actually.

Other items really aren't needed:

1. AI - you should just use Accord.net, numl, or Azure's machine learning library. The Naive Bayes class in here was something I created for a single project and other libraries have more features.

Basically make it compatible with ASP.Net Core and the IoC container that they use internally. Singleton and creating an item each time was supported but a session based scope wasn't really a consideration so it needs to be reworked. Look to the initial attempt back when doing the changes in 2015.