-
Notifications
You must be signed in to change notification settings - Fork 10.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
DataProtection isn't linker friendly #24705
Comments
Well that's what you get for needing back compat to systems where DI doesn't exist :) |
Hah, I was looking at the code and its unfortunately some of the most reflection heavy code in the System. That never occurred to me before... |
It was also written when, well DI was crap, and if you look at some the issues, the response was roll your own reflection. However setting that side it's also policy based, where an admin outside of an application can place restrictions on the algorithms used and other key decisions that affect control flow. This is needed for some regulated environments. This type of external control does not lend itself to trimming, or indeed interop with other systems. Say for example, you trimmed app 1 to only support SHA256 because that's all trimming detected, but it also talks to app2 which sends SHA512. You'd going to have unknown and probably very hard to trace errors from that. Given it's data protection it has to fail closed/safe. Data Protection is probably not a target for trimming, not without a real concerted effort and careful design. |
I don't know what you mean by when the DI system was crap, but maybe you meant that it can't create things based on name which it still can't do. I think what you said is reasonable but the way it's designed today it sounds like an easy thing to do would be to keep all the implementations, which sounds fine as a first step. If data protection is untrimmable a designed today then we'll need to look at the cost of the assembly an determine if it worth it and if so maybe decouple other components from the implementation here |
Thanks for contacting us. |
@HaoK this is assigned to you for preview4 but we should move it and discuss it more before you start. |
Sure preview5? Do you want me to setup a meeting to discuss this work? |
Yep! |
Do we need Levi for this meeting or just Barry? |
Both would be ideal |
Honestly this seems doable to me. Might have to invent some tricks to help get the ball rolling, but nothing here immediately stands out as being impossible to trim. |
Linking #31821 |
How is that related? |
Discussion notes: High level options
Next steps
DataProtection -> Span in, Array out |
Update: I tried deleting all the code related to the windows implementations of SP800 so
This resulted in the following differences in Microsoft.AspNetCore.DataProtection.dll size: So looks like it saves around 11 KB, or around 7% |
Thanks for contacting us. We're moving this issue to the |
Here are the warnings:
Generally, DataProtection tries to load types from configuration, but these types are part of data protection itself so we can preserve these types so that loading works. Funnily enough, if we used the DI system, this wouldn't be a problem 😄
Components with dependencies on DataProtection:
The text was updated successfully, but these errors were encountered: