Split MimeKit into MimeKit[.Core] and MimeKit.Cryptography #820
Comments
|
What projects are you talking about, specifically? I would argue that those projects should be using MimeKit always and not MimeKitLite. |
|
To add context: I just had the problem, that Wiremock.net added the dependency to MimekitLite to parse emails. I was using Mailkit to send emails. Here is also a Wiremock.net issue: WireMock-Net/WireMock.Net#990 |
|
This has been on my radar for a while now but I don't know of a good way to do it that wouldn't require the user manually register the fact that they have the crypto stuff available to the MimeParser. The MimeVisitor class would also need changes because right now, MimeKitLite's MimeVisitor API is not identical to the MimeVisitor API in MimeKit. MimeMessage also has ties to the crypto APIs that are conditionally built depending on MimeKit vs MimeKitLite build configuration. |
|
Also been thinking a while of this, reading a bit into the code. Not quite sure of everything though. At first glance, it looks to me the biggest issue is the I guess it would be doable to dynamically load a known assembly by name and call an additional static initializer method there that would additionally register the additional mimeparts, eg via the existing It could also set some kind of FeatureFlag or something on the ParserOptions indicating if Crypto is available. Then Would this make sense? |
|
Yea, that's more or less what I've also concluded. MimeParser isn't a problem - it uses ParserOptions to instantiate the various MIME type classes. MimeVisitor is/was the biggest problem because MimeKitLite does not have any of the crypto classes like ApplicationPkcs7Mime or MultipartEncrypted or MultipartSigned and obviously that is not so easy to make work via reflection or any sort of runtime decision making. |
|
Having the same issue. |
|
I'll put this on the roadmap for 5.0 but I don't have definite plans for that yet. In the meantime, there is also a MailKitLite if that helps. Or ask the developers of StrongGrid to publish a version built against MimeKit instead of MimeKitLite. That would be a LOT easier to do than rearchitect MimeKit. |
jstedfast
changed the title
|
What I would propose is that we completely get rid of MimeKitLite (mostly I hate the naming) and either:
Either way, MimeKitLite ceases to exist. The next question is: should Microsoft.Extensions.DependencyInjection be used? Or should stuff like CryptographyContext.Register() continue to be the way the SecureMimeContext and OpenPgpContext get registered? The problem with the .Register() approach is that we'd need something similar for DKIM/ARC. So much of what exists in MimeKit.Cryptography is deeply tangled with BouncyCastle which is going to make this split extremely painful. I already have some local branches that have started:
This is going to be more difficult than I thought 😦 |
This is the first step towards splitting crypto out of MimeKit into a separate extension package (e.g. MimeKit.Cryptography). The start of a fix for issue #820
This allows us to include the necessary APIs for things like IMultipartEncrypted, IMultipartSigned, IApplicationPkcs7Mime, etc. while only providing the implementation of those types in a future separate MimeKit.Cryptography extension nuget package. Classes like ApplicationPgpEEncrypted and ApplicationPgpSignature, on the other hand, could be part of the core MimeKit package because they don't actually provide any crypto routines. They are just convenience classes. Another partial fix for issue #820
The idea here is to provide the DKIM interfaces in the core MimeKit package, but provide the BouncyCastle implementation of said interfaces in a future MimeKit.Cryptography package. Partial fix for issue #820
This is the first step towards splitting crypto out of MimeKit into a separate extension package (e.g. MimeKit.Cryptography). The start of a fix for issue #820
This allows us to include the necessary APIs for things like IMultipartEncrypted, IMultipartSigned, IApplicationPkcs7Mime, etc. while only providing the implementation of those types in a future separate MimeKit.Cryptography extension nuget package. Classes like ApplicationPgpEEncrypted and ApplicationPgpSignature, on the other hand, could be part of the core MimeKit package because they don't actually provide any crypto routines. They are just convenience classes. Another partial fix for issue #820
The idea here is to provide the DKIM interfaces in the core MimeKit package, but provide the BouncyCastle implementation of said interfaces in a future MimeKit.Cryptography package. Partial fix for issue #820
The idea here is to provide the DKIM interfaces in the core MimeKit package, but provide the BouncyCastle implementation of said interfaces in a future MimeKit.Cryptography package. Partial fix for issue #820
The idea here is to provide the DKIM interfaces in the core MimeKit package, but provide the BouncyCastle implementation of said interfaces in a future MimeKit.Cryptography package. Partial fix for issue #820
This is the first step towards splitting crypto out of MimeKit into a separate extension package (e.g. MimeKit.Cryptography). The start of a fix for issue #820
This allows us to include the necessary APIs for things like IMultipartEncrypted, IMultipartSigned, IApplicationPkcs7Mime, etc. while only providing the implementation of those types in a future separate MimeKit.Cryptography extension nuget package. Classes like ApplicationPgpEEncrypted and ApplicationPgpSignature, on the other hand, could be part of the core MimeKit package because they don't actually provide any crypto routines. They are just convenience classes. Another partial fix for issue #820
The idea here is to provide the DKIM interfaces in the core MimeKit package, but provide the BouncyCastle implementation of said interfaces in a future MimeKit.Cryptography package. Partial fix for issue #820
This is the first step towards splitting crypto out of MimeKit into a separate extension package (e.g. MimeKit.Cryptography). The start of a fix for issue #820
This allows us to include the necessary APIs for things like IMultipartEncrypted, IMultipartSigned, IApplicationPkcs7Mime, etc. while only providing the implementation of those types in a future separate MimeKit.Cryptography extension nuget package. Classes like ApplicationPgpEEncrypted and ApplicationPgpSignature, on the other hand, could be part of the core MimeKit package because they don't actually provide any crypto routines. They are just convenience classes. Another partial fix for issue #820
The idea here is to provide the DKIM interfaces in the core MimeKit package, but provide the BouncyCastle implementation of said interfaces in a future MimeKit.Cryptography package. Partial fix for issue #820
This is the first step towards splitting crypto out of MimeKit into a separate extension package (e.g. MimeKit.Cryptography). The start of a fix for issue #820
This allows us to include the necessary APIs for things like IMultipartEncrypted, IMultipartSigned, IApplicationPkcs7Mime, etc. while only providing the implementation of those types in a future separate MimeKit.Cryptography extension nuget package. Classes like ApplicationPgpEEncrypted and ApplicationPgpSignature, on the other hand, could be part of the core MimeKit package because they don't actually provide any crypto routines. They are just convenience classes. Another partial fix for issue #820
The idea here is to provide the DKIM interfaces in the core MimeKit package, but provide the BouncyCastle implementation of said interfaces in a future MimeKit.Cryptography package. Partial fix for issue #820
|
The mess of interfaces is too much to handle. I think it might be time to consider an alternative option. I'm thinking now that the MimePart subclasses need to stay in MimeKit itself (or MimeKit.Core, depending on naming conventions) while any code that touches BouncyCastle would move into a new MimeKit.Cryptography assembly.
Unfortunately, many of the MultipartEncrypted/Signed methods are actually static methods that create the multipart instances, so I'm not sure what to do about that. I'd have to somehow make them "instance" methods (actually extension methods). Ugh. |
Is your feature request related to a problem? Please describe.
Right now, different projects can end up with weird conflicts when one dependency uses MimeKitLite and another uses MimeKit. When this happens, there can be an error about not being sure which version to use.
Describe the solution you'd like
It would be conceptually simpler to have MimeKit simply depend on MimeKitLite and add the additional functionality on top of it. Of course this would probably require a major version change.
Describe alternatives you've considered
The workaround at the moment is to use aliased references that allows you to select which reference to pull a type from. Another dev approach would be to use a different namespaces, but that is far uglier.
The text was updated successfully, but these errors were encountered: