Skip to content

Conversation

@jborean93
Copy link
Collaborator

@jborean93 jborean93 commented Dec 13, 2022

PR Summary

Do not try and roundtrip the -Content bytes to a Unicode encoded string and then back to bytes. Instead just use the raw input bytes when validating the content signature.

PR Context

Fixes #18773

PR Checklist

Do not try and roundtrip the -Content bytes to a Unicode encoded string
and then back to bytes. Instead just use the raw input bytes when
validating the content signature.
@pull-request-quantifier-deprecated

This PR has 135 quantified lines of changes. In general, a change size of upto 200 lines is ideal for the best PR experience!


Quantification details

Label      : Medium
Size       : +120 -15
Percentile : 47%

Total files changed: 4

Change summary by file extension:
.cs : +17 -15
.ps1 : +103 -0

Change counts above are quantified counts, based on the PullRequestQuantifier customizations.

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a
balance between between PR complexity and PR review overhead. PRs within the
optimal size (typical small, or medium sized PRs) mean:

  • Fast and predictable releases to production:
    • Optimal size changes are more likely to be reviewed faster with fewer
      iterations.
    • Similarity in low PR complexity drives similar review times.
  • Review quality is likely higher as complexity is lower:
    • Bugs are more likely to be detected.
    • Code inconsistencies are more likely to be detected.
  • Knowledge sharing is improved within the participants:
    • Small portions can be assimilated better.
  • Better engineering practices are exercised:
    • Solving big problems by dividing them in well contained, smaller problems.
    • Exercising separation of concerns within the code changes.

What can I do to optimize my changes

  • Use the PullRequestQuantifier to quantify your PR accurately
    • Create a context profile for your repo using the context generator
    • Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the Excluded section from your prquantifier.yaml context profile.
    • Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your prquantifier.yaml context profile.
    • Only use the labels that matter to you, see context specification to customize your prquantifier.yaml context profile.
  • Change your engineering behaviors
    • For PRs that fall outside of the desired spectrum, review the details and check if:
      • Your PR could be split in smaller, self-contained PRs instead
      • Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

How to interpret the change counts in git diff output

  • One line was added: +1 -0
  • One line was deleted: +0 -1
  • One line was modified: +1 -1 (git diff doesn't know about modified, it will
    interpret that line like one addition plus one deletion)
  • Change percentiles: Change characteristics (addition, deletion, modification)
    of this PR in relation to all other PRs within the repository.


Was this comment helpful? 👍  :ok_hand:  :thumbsdown: (Email)
Customize PullRequestQuantifier for this repository.

@iSazonov iSazonov requested a review from PaulHigin December 13, 2022 08:15
@iSazonov iSazonov added the CL-General Indicates that a PR should be marked as a general cmdlet change in the Change Log label Dec 13, 2022
@ghost ghost added the Review - Needed The PR is being reviewed label Dec 20, 2022
@ghost
Copy link

ghost commented Dec 20, 2022

This pull request has been automatically marked as Review Needed because it has been there has not been any activity for 7 days.
Maintainer, please provide feedback and/or mark it as Waiting on Author

@jborean93
Copy link
Collaborator Author

Any updates on this one, have been a few months with CI being green.

@jborean93 jborean93 closed this Apr 19, 2023
@daxian-dbw daxian-dbw reopened this Apr 20, 2023
@ghost ghost removed the Review - Needed The PR is being reviewed label Apr 20, 2023
Comment on lines 537 to 538
string verificationContents = Encoding.Unicode.GetString(script.OriginalEncoding.GetPreamble()) + script.ScriptContents;
signature = SignatureHelper.GetSignature(path, verificationContents);
signature = SignatureHelper.GetSignature(path, Encoding.Unicode.GetBytes(verificationContents));
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The existing code seems wrong here -- the OriginalEncoding could be an encoding other than Unicode, and that means Encoding.Unicode.GetBytes(verificationContents) could be different byte sequences than the original bytes from the file.
I will make a change and see if all tests still pass.

Copy link
Member

@daxian-dbw daxian-dbw left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM.
@SeeminglyScience I made a change on how we get the byte sequences for the content of a script file because the existing code seems incorrect to me. CIs still passed with my changes, but I'd like you to take a look just to make sure the changes make sense. Thanks!

private static byte[] GetContentBytesWithBom(Encoding encoding, string scriptContent)
{
ReadOnlySpan<byte> bomBytes = encoding.Preamble;
byte[] contentBytes = encoding.GetBytes(scriptContent);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unsure if this code path warrants it, but you could ArrayPool<byte>.Shared.Rent(encoding.GetMaxCharCount(scriptContent)) here to avoid some potentially LOH allocations here

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's been using System.Text.Encoding.Unicode.GetBytes(fileContent); in GetWinTrustData method, so I guess the LOH allocation has not become a concern, but yes, it's a potential perf issue.

@SeeminglyScience
Copy link
Collaborator

LGTM. @SeeminglyScience I made a change on how we get the byte sequences for the content of a script file because the existing code seems incorrect to me. CIs still passed with my changes, but I'd like you to take a look just to make sure the changes make sense. Thanks!

Yeah I think your changes make sense. It may actually solve some finickyness with encoding requirements and signing that I vaguely remember hearing about. LGTM!

@daxian-dbw daxian-dbw merged commit 93e9c63 into PowerShell:master Apr 25, 2023
@jborean93 jborean93 deleted the authenticode-data branch April 25, 2023 19:35
@ghost
Copy link

ghost commented Jun 29, 2023

🎉v7.4.0-preview.4 has been released which incorporates this pull request.:tada:

Handy links:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

CL-General Indicates that a PR should be marked as a general cmdlet change in the Change Log Medium

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Get-AuthenticodeSignature Displaying Inconsistent Behavior Between -FilePath and -Content

5 participants