-
Notifications
You must be signed in to change notification settings - Fork 5.1k
Rename rapidjson helper functions #114017
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
base: main
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Copilot wasn't able to review any files in this pull request.
Files not reviewed (7)
- src/native/corehost/comhost/clsidmap.cpp: Language not supported
- src/native/corehost/fxr/sdk_resolver.cpp: Language not supported
- src/native/corehost/fxr/standalone/hostpolicy_resolver.cpp: Language not supported
- src/native/corehost/hostpolicy/deps_format.cpp: Language not supported
- src/native/corehost/json_parser.cpp: Language not supported
- src/native/corehost/json_parser.h: Language not supported
- src/native/corehost/runtime_config.cpp: Language not supported
Tagging subscribers to this area: @vitek-karas, @agocke, @VSadov |
cd59749
to
b1f578c
Compare
Rebased on latest main to resolve merge conflicts. |
We could also consider switching to https://github.com/simdjson/simdjson. |
FWIW, here is the initial impl. main...am11:runtime:feature/corehost/simdjson (windows would require UTF-16/8 conversion as happens with rapidjson's non-insitu mode behind the scenes) It's a size regression (which I'm not sure matters in read-world with corehost variants):
|
Since rapidjson is a disallowed deserializer within Microsoft, signing off on .NET 10 will require us to attest that every call site into rapidjson processes only fully trusted input.
This is straightforward enough for a point-in-time assessment, but it does represent ongoing cost, and we don't want to risk introducing new call sites into this logic where we can't guarantee that the input is trustworthy. To facilitate this, I recommend renaming our rapidjson wrapping utility methods to
parse_fully_trusted_raw_data
andparse_fully_trusted_file
, which clearly indicate at the invocation site that the caller passes only fully trustworthy data. This should reduce the risk of us violating the trust contract going forward and should simplify future attestations.(Jeff, this is what I pinged you about via IM.)