Thoughts on code modernization?

[jarz]

Some idioms seem outdated (implementing IEnumberable but not IEnumerable being a big one).

Is this just an effect of making the C# and Java code look similar? Would clean-up contributions be accepted?

Thanks!

[peterdettman]

It's partly the Java origins, partly backward compatibility, partly supporting .NET 1.1 (1.8 series is the last release for that). We will be forking off a maintenance branch for 1.8 "shortly", at which point we would welcome modernization patches to the master branch (intended target .NET 4).

[clairernovotny]

@peterdettman is there any point in using .NET 4 as the baseline given that .NET 4-4.5.1 is no longer supported by Microsoft for security updates?

Can the baseline be .NET 4.5.2 (or at least 4.5 from an API/compat standpoint)?

[jstedfast]

FWIW, I'm fine with Bouncy Castle deciding to target >= .NET 4.5, but here are a few thoughts:

1. There's no sense in targeting a .NET platform version higher than what you need API-wise.
2. .NET 4.0 gives you everything you need to create Task-based API's allowing developers consuming your library to take advantage of async if they want to (granted, if BC itself wants to take advantage of doing things asynchronously internally, that would be grounds for depending on .NET 4.5 imho)

So I guess the question comes down to: what does .NET 4.5 offer that we'd want to use inside BC?

.NET 2.0 offers a LOT of advantages over 1.1 such as the Dispose pattern for Streams, generics, etc.
.NET 3.5 starts to add some LINQ which can be really handy
.NET 4.0 adds some nice Stream API's such as CopyTo(Stream) (or was this added in .NET 3.5?), CancellationToken, System.Threading.Task, etc.
.NET 4.5 adds async/await, but unless bouncy castle actually intends to use async internally, this is somewhat moot.

[clairernovotny]

.NET 4.5's most important characteristic is that it's a System.Runtime based target. That is, it can use contracts instead of mscorlib directly.

More to the point, you'll be able to use xProj to create multiple profiles in a single project:

• netstandard1.3 full support for everything and consumable by .NET Core, .NET 4.6 and UWP
• net45 support for .net 4.5+
• portable-win8+wpa81+wp8+net45 Profile 259 with some features not present (filesystem, etc)

Then you just have iOS/Android projects until they support netstandard1.3. Once Xamarin supports those contracts you won't need platform specific builds for them.

The doc on the .NET Standard Platform is here: https://github.com/dotnet/corefx/blob/master/Documentation/project-docs/standard-platform.md

[jarz]

@jstedfast async and await were added in .NET Framework 4.5. It'd be easier to use those than TPL -- I'm not sure TPL is maintained now.

ETA: I can't read -- you already mentioned that. D'oh!

[clairernovotny]

@peterdettman I have pushed a packaging update to the 1.8.1 version that includes support for netstandard.

https://github.com/onovotny/BouncyCastle-PCL/tree/pcl-netstandard

I plan on releasing this as 1.8.1.1 to the Portable.BouncyCastle package on Monday so that people can more easily use it with .NET Core.

[clairernovotny]

An update -- the netstandard version is here now: https://github.com/onovotny/bc-csharp/tree/netstandard

It's built on VS 2017's cross-compiling feature to simplify and reduce the number of projects needed.

[Rajarch]

Hi, just wanted to know if there are any plans by committers to extend the library to include SimonEngine.cs and SpeckEngine.cs on the lines of these cipher engines which are available in the java. Thanks

[mtausig]

@peterdettman Is there any timeline when this branching will be happening?

[mdsitton]

I would assume modernization patches can be merged now?

As of now the oldest supported version of .net framework from Microsoft is .net framework 4.6.2 which you can find this information here:
https://dotnet.microsoft.com/en-us/platform/support/policy/dotnet-framework

Which checking here:
https://docs.microsoft.com/en-us/dotnet/standard/net-standard?tabs=net-standard-2-0

This brings us up to .net standard 2,0 support as being the minimum supported version.

If i were managing the library in order to do a full modernization effort, I would dual target .net standard 2.0 and make use of System.Buffers for Memory/Span/ReadOnlySpan support:
https://docs.microsoft.com/en-us/dotnet/api/system.buffers
https://www.nuget.org/packages/System.Buffers/

The advantages of migrating internal code to use this is the massive performance and memory allocation reduction enhancements that can be achieved using these api's that can reduce thrashing of the heap and reduce garbage collection overhead on older .net framework versions (the coreclr gc is generally faster than older .net framework based runtimes)

I can help out with contributions in this area if this proposal would be considered.

[mdsitton]

Mentioning my suggestion of a full library modernization effort targeting a BC 2.0 release which would drop support for older .net releases. Would be a great time to also do a lot of modernization work to move to generic collections, or Span/Memory based apis potentially.

Since incrementing the major version number would be a good opportunity for doing an API compatibility break. (though i don't know what BC's policy is on such api deprecation/changes and whatnot.) Older versions can still be maintained in branches for critical bug-fixes and security fixes.

[mdsitton]

Additional changes that i think could be done in such a modernization effort is moving namespaces to just be BouncyCastle instead of Org.BouncyCastle as this type of Reverse DNS based naming is not utilized in the ,net world.