Adding pkeyutl tool to the CLI

[smittals2]

Description of changes:

Add pkeutl tool with:
-help
-in
-out
-sign
-verify
-inkey
-sigfile
-pubin
-passin

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license and the ISC license.

[codecov-commenter]

Codecov Report

❌ Patch coverage is 58.49673% with 127 lines in your changes missing coverage. Please review.
✅ Project coverage is 78.94%. Comparing base (ffe498f) to head (1053d6f).

Files with missing lines	Patch %	Lines
tool-openssl/pkeyutl_test.cc	46.21%	64 Missing ⚠️
tool-openssl/pkeyutl.cc	66.31%	63 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #2575      +/-   ##
==========================================
- Coverage   78.97%   78.94%   -0.03%     
==========================================
  Files         673      675       +2     
  Lines      114965   115273     +308     
  Branches    16166    16211      +45     
==========================================
+ Hits        90794    91008     +214     
- Misses      23385    23479      +94     
  Partials      786      786              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[justsmth]

The msys2/ucrt64 CI failures seem related:

tool-openssl/tool_openssl_test failed to complete: exit status 0xc0000005

A "0xc0000005" exit status seems to be associated with memory access violations on Windows.

[smittals2]

The msys2/ucrt64 CI failures seem related:

tool-openssl/tool_openssl_test failed to complete: exit status 0xc0000005

A "0xc0000005" exit status seems to be associated with memory access violations on Windows.

Yea I've been trying to debug why we see this. Before opening the file, we stat it to make sure it exists. In this particular use case, the file is created by the test harness, opened via BIO APIs and populated by the pkeyutl tool, and then fails when we try to read the file subsequently to validate it's contents. I added additional explicit instructions to close any BIO handles that may create resource contention but continued seeing this error.

We can see this in the logs here:

> DEBUG: ReadFileToString - Starting for path: C:\Users\RUNNER~1\AppData\Local\Temp\aws91A.tmp
> DEBUG: ReadFileToString - Checking if file exists with stat()
> DEBUG: ReadFileToString - File exists, size: 32 bytes
> DEBUG: ReadFileToString - Opening file stream
> tool-openssl/tool_openssl_test
> tool-openssl/tool_openssl_test failed to complete: exit status 0xc0000005

We also only see this access violation in msys2 ucrt64 - (Ninja/MinGW) builds. For example msys2 ucrt64 with MSYS Makefiles doesn't fail (neither do any of the other Windows CI checks).

My two pending investigation avenues are as follows:

1. Looking at the Cmake, the two build dimensions we see the error in are special cased:

   aws-lc/.github/workflows/windows-alt.yml

   Line 244 in 1a5b9eb

   - name: Run tests

   . Maybe the diff shell is impacting which libraries our test executable links to
2. Using the BIO APIs to access the same tmp files doesn't cause an issue, but using ReadFileToString which uses the native C++ file reading APIs does, so maybe there's some edge case/bug in these two build dimensions.

[github-actions]

clang-tidy made some suggestions

[github-actions]

warning: variable 'bytes_read' is not initialized [cppcoreguidelines-init-variables]

Suggested change

	int bytes_read;
	int bytes_read = 0;

[justsmth]

2. Using the BIO APIs to access the same tmp files doesn't cause an issue, but using ReadFileToString which uses the native C++ file reading APIs does, so maybe there's some edge case/bug in these two build dimensions.

I suspect the issue might be that it's linking to the wrong C++ runtime when the test runs.

I have a couple of ideas we could try to debug these tests:

• echo $PATH prior to test execution to verify "/ucrt64/bin" is listed first. (The PATH can affect which DLLs get loaded.) We use a "Windows" path above: cygpath -w ${SYSROOT}/bin >> $GITHUB_PATH, but perhaps we should used mixed: cygpath -m ${SYSROOT}/bin >> $GITHUB_PATH
• Run dumpbin /dependents <executable> or dumpbin /imports <executable> to compare executables across the different tests. (Actually, ldd might work in these environments as well.)
• Since the issue seems to be with linking to the C++ standard library, perhaps we could try adding -static-libstdc++ in CFLAGS or something?