You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently (2.2.0) the BouncyCastle.Cryptography.dll is just over 7MB and this has recently increased (it's double the old Portable.BouncyCastle dll size). In my application this accounts for almost a third of the installer size.
I would like to propose that the build be split into a Core for shared and or/essential parts, with additional DLLs (and therefore nugets) for other parts or exotic features, for instance I'm using the following namespaces:
using Org.BouncyCastle.Asn1.Sec;
using Org.BouncyCastle.Asn1.X509;
using Org.BouncyCastle.Asn1;
using Org.BouncyCastle.Crypto.EC;
using Org.BouncyCastle.Crypto.Generators;
using Org.BouncyCastle.Crypto.Operators;
using Org.BouncyCastle.Crypto.Parameters;
using Org.BouncyCastle.Crypto.Prng;
using Org.BouncyCastle.Crypto;
using Org.BouncyCastle.Crypto;
using Org.BouncyCastle.Math;
using Org.BouncyCastle.Ocsp;
using Org.BouncyCastle.OpenSsl;
using Org.BouncyCastle.Pkcs;
using Org.BouncyCastle.Security;
using Org.BouncyCastle.Utilities;
using Org.BouncyCastle.X509;
Splitting into separate DLLs would allows apps which cannot using trimming to still only include the functionality they need,
With feature groups in packages the download stats could be monitored to assess the relative popularity of feature groups, Future security problems in one are would not affect the SBOM for apps which simply don't include that feature.
A (full) BouncyCastle.Cryptography package could be retained for those who want to include the whole thing.
It's possible that interdependency between parts of the library prevent this from being a workable solution but I'd like to raise the issue for discussion at least.
The text was updated successfully, but these errors were encountered:
If file size is a design goal for your app, depending on a few things, maybe trimming self-contained applications could be useful to you too (though it has some limitations). From my understanding, it should already remove all unused code, from both the app itself and libraries.
@patagonaa thanks for your reply, I'm targeting net462 currently so I don't think that trimming would work for me, currently I'm using my own fork to trim the build instead,
Currently (2.2.0) the BouncyCastle.Cryptography.dll is just over 7MB and this has recently increased (it's double the old Portable.BouncyCastle dll size). In my application this accounts for almost a third of the installer size.
I would like to propose that the build be split into a Core for shared and or/essential parts, with additional DLLs (and therefore nugets) for other parts or exotic features, for instance I'm using the following namespaces:
Splitting into separate DLLs would allows apps which cannot using trimming to still only include the functionality they need,
With feature groups in packages the download stats could be monitored to assess the relative popularity of feature groups, Future security problems in one are would not affect the SBOM for apps which simply don't include that feature.
A (full) BouncyCastle.Cryptography package could be retained for those who want to include the whole thing.
It's possible that interdependency between parts of the library prevent this from being a workable solution but I'd like to raise the issue for discussion at least.
The text was updated successfully, but these errors were encountered: