[DRAFT] AIO PR

[sfc-gh-turbaszek]

Please answer these questions before submitting your pull requests. Thanks!

1. What GitHub issue is this PR addressing? Make sure that there is an accompanying issue to your PR.

   Fixes #NNNN

2. Fill out the following pre-review checklist:

   • I am adding a new automated test(s) to verify correctness of my new code
   • I am adding new logging messages
   • I am adding a new telemetry message
   • I am modifying authorization mechanisms
   • I am adding new credentials
   • I am modifying OCSP code
   • I am adding a new dependency

3. Please describe how your code solves the related issue.

   Please write a short description of how your code change solves the related issue.

4. (Optional) PR for stored-proc connector:

The best way to fix the problem is to add a permissions block at the root of the workflow file (.github/workflows/build_test.yml), just after the name and before or after the on: trigger, but before defining jobs. This block should minimally specify contents: read, which means the default GITHUB_TOKEN provided to all jobs will only be able to read repository contents, not write or modify anything. If any job requires elevated permissions, those can be configured individually at the job level, but in this workflow, based on provided code snippets, none of the jobs appear to require more than contents: read.

Specifically, add:

permissions:
  contents: read

directly after the workflow name at the top of .github/workflows/build_test.yml.

No imports or definitions are required; just the YAML block as described.

---

To fix this issue, the permissions: key should be set explicitly for the test-aio job, or globally at the workflow level if all jobs share the same minimal needs. For jobs that only need to check out code and upload/download artifacts (such as test-aio), setting contents: read is sufficient and recommended. This prevents GITHUB_TOKEN from having broader write privileges. The explicit block should look like:

permissions:
  contents: read

The change should be made within .github/workflows/build_test.yml, either globally (above jobs:) or locally in the definition for the test-aio: job. If other jobs in the workflow might require different permissions, setting it per-job is safer; otherwise, global is preferred for consistency. For this fix, since CodeQL specifically flagged line 449 (the start of the test-aio job), the precise minimal fix is to add permissions: contents: read to the job definition immediately below test-aio: (i.e., after line 449).

No additional dependencies or code changes are required.

To fix the problem, the code should parse potential URLs in log lines and verify that any host matches (or ends with) 'blob.core.windows.net' rather than checking for this substring anywhere in the log line. The best way is to attempt to extract URLs from each log line and, for each, parse out the host portion. One can use the re module to extract URLs and urllib.parse.urlparse to get hosts, and then check if any host matches or ends with 'blob.core.windows.net'. Only those lines are subjected to further checks about expected_token_prefix. This keeps the test intent intact while avoiding false positives inherent to pure substring checks.

Required changes:

• Add import re at the top (if not present).
• Add from urllib.parse import urlparse at the top (if not present).
• Refactor the for-loop on log lines:
  • Extract all candidate URLs from the line using regex.
  • For each URL, parse it and check if its host matches/ends with 'blob.core.windows.net'.
  • Only run the sensitive-information assertion on such lines.

All changes are localized to the test file and specifically to lines near the existing substring check.

---

To fix the security issue, the RSA key generated on line 146 should be at least 2048 bits, per current recommendations. Change the line

private_key = rsa.generate_private_key(
    public_exponent=65537, key_size=1024, backend=default_backend()
)

so that key_size=2048 (or higher). This change preserves the intent and functionality of the test code with a secure key size. No other code modifications are necessary, and no additional imports or libraries are required since the rest of the key creation process remains unaffected.