-
Notifications
You must be signed in to change notification settings - Fork 160
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
BinSkim .NET Updates to version 9 #1024
base: main
Are you sure you want to change the base?
Conversation
3d1696b
to
990a79d
Compare
8c0ae1d
to
c90c64e
Compare
c72a5f2
to
0884878
Compare
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.
There are some configs under .vscode/
you want to change too.
@@ -121,13 +121,18 @@ public ulong ReadLength(out bool is64bit) | |||
/// <summary> | |||
/// Reads the string from the current position in the stream. | |||
/// </summary> | |||
[HandleProcessCorruptedStateExceptions] |
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.
I may be reading the docs wrong, but with HandleProcessCorruptedStateExceptions
being removed - are you still trying to catch CSEs with the try-catch
block?
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.
well I went over the docs, and as of now the only option seems to be try catch, so I did it with the generic try catch clause. But I'm more than open to the suggestions for improvements :)
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.
Yeah, I'm kind of wondering if try-catch
here actually serves any purpose and whether we can remove it altogether to not give us a false sense of "security" of exception being caught (from docs):
By default, the common language runtime (CLR) does not deliver these exceptions to managed code, and the try/catch blocks (and other exception-handling clauses) are not invoked for them.
.NET Core only: Even though this attribute exists in .NET Core, since the recovery from corrupted process state exceptions is not supported, this attribute is ignored. The CLR doesn't deliver corrupted process state exceptions to the managed code.
It doesn't seem like we have any automated tests for this right?
src/Directory.Packages.props
Outdated
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.
Nitpick: It seems there's a mix of major, minor and patch updates - I assume not all of them are strictly .NET update related (I'd be surprised if some of these patch level updates would be). I think it's fine to update dependencies in general, but too many changes here make it a bit tricky to review these. Separate PR in a regular dependency update cycle would be great in the future.
Enhance memory reading and COM object management with error handling and platform checks Add static keyword to lambdas in AnalyzeCommandTests.cs Modified lambda expressions in AnalyzeCommandTests.cs to be static. This change ensures that the lambdas do not capture variables from the enclosing scope, potentially improving performance and clarity. Fixing version constant file Refactor project to target .NET 9.0 and remove obsolete configurations Update ADO build configuration to target .NET 9.0 and add .vscode to .gitignore Update GitHub workflows to target .NET 9.0 and improve formatting steps Update .gitignore and improve Build scripts for .NET 9.0 compatibility Directory.Packages.props fixes Fix formatting in VersionConstants.cs by removing unnecessary whitespace Update ADO build configuration to allow all branches for PRs Remove platform-specific exceptions in PDB handling for cross-platform support Refactor platform-specific code and resource management Removed `using System.Runtime.Versioning;` and `[SupportedOSPlatform("windows")]` from `MSDiaComWrapper.cs` and `Pdb.cs`. Replaced `Marshal.GetObjectForIUnknown` with `ResourceReleaser.GetObjectForIUnknown` in `MSDiaComWrapper.cs`. Removed `OperatingSystem.IsWindows()` checks in `Pdb.cs` and ensured `PlatformSpecificHelpers.ThrowIfNotOnWindows()` still enforces Windows-only execution in `Init` methods. Simplified codebase by removing redundant platform checks.
53a1ae1
to
000e522
Compare
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.
I've left a few comments, overall LGTM!
@@ -16,4 +16,4 @@ jobs: | |||
run: dotnet tool install -g dotnet-format | |||
|
|||
- name: dotnet format | |||
run: dotnet-format --folder --check | |||
run: dotnet-format --folder --check |
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.
Nitpick: is this intentional?
@@ -121,13 +121,18 @@ public ulong ReadLength(out bool is64bit) | |||
/// <summary> | |||
/// Reads the string from the current position in the stream. | |||
/// </summary> | |||
[HandleProcessCorruptedStateExceptions] |
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.
Yeah, I'm kind of wondering if try-catch
here actually serves any purpose and whether we can remove it altogether to not give us a false sense of "security" of exception being caught (from docs):
By default, the common language runtime (CLR) does not deliver these exceptions to managed code, and the try/catch blocks (and other exception-handling clauses) are not invoked for them.
.NET Core only: Even though this attribute exists in .NET Core, since the recovery from corrupted process state exceptions is not supported, this attribute is ignored. The CLR doesn't deliver corrupted process state exceptions to the managed code.
It doesn't seem like we have any automated tests for this right?
@@ -6,6 +6,7 @@ | |||
using System.IO; | |||
using System.Linq; | |||
using System.Reflection; | |||
using System.Runtime.Versioning; |
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.
Is this still needed?
[WIP] BinSkim .NET Updates to version 9
Overview
This pull request focuses on updating the BinSkim project to incorporate the latest .NET updates. The goal is to ensure compatibility with the newest .NET features and improve overall performance and security.
Changes
Updated the project to target the latest .NET version.
Benefits
Enhanced Compatibility: Ensures that the BinSkim project is compatible with the latest .NET version, taking advantage of new features and improvements.
Testing
Verified that the project builds successfully with the latest .NET version.
Ran all existing tests to ensure no regressions were introduced.
Conducted manual testing to confirm that the functionality remains intact.
Additional Notes
If you encounter any issues or have questions about these updates, please feel free to reach out.