[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 risk of cleartext logging of sensitive information, we must guarantee that sensitive keys (such as "PASSCODE", "password", etc.) are never logged.
The best approach is:

• Maintain a separate set of sensitive keys (e.g., SENSITIVE_AUTH_KEYS) that are explicitly redacted regardless of the whitelist.
• When constructing the log message, always redact the value for any key in SENSITIVE_AUTH_KEYS, even if it is also present in the whitelist.
• Double-check that the PASSCODE (and similar sensitive keys) are always redacted.
• Importantly, make this redaction explicit and simple, so future maintainers cannot mistakenly expose sensitive values by merely editing the whitelist.

Implementation plan:

• Define a set (or list) called SENSITIVE_AUTH_KEYS, including "PASSCODE", "password", and any similar key.
• In the log message dictionary comprehension, for each key:
  • If key is in SENSITIVE_AUTH_KEYS, log "******".
  • Else if key is in the existing whitelist, log its value.
  • Else, log "******".
• Edit only the relevant log statement and local definitions in src/snowflake/connector/aio/auth/_auth.py.
• No external library is needed; use built-in Python set/dict logic.

---

To fix the issue, the code should avoid displaying the OAuth URL with sensitive parameters in cleartext. Instead, before printing the URL for manual use, sensitive parameters embedded in the URL (notably client_id, and potentially authorization codes/tokens if present) should be redacted or masked.
The optimal solution is to parse the URL, locate known sensitive query parameters (client_id, client_secret, possibly code and token), and replace their values with placeholders (e.g., '***') before printing.
Edit only the affected region in src/snowflake/connector/auth/oauth_code.py where the URL is printed in _ask_authorization_callback_from_user, adding a small helper method for redaction and changing the print to print the sanitized version.

---

The best way to fix this issue is to parse the potentially returned URL (i.e., c[0][1]) using Python's urllib.parse.urlparse and then check the individual fields (scheme, host, port) for correctness. This avoids confusing "starts with" logic due to userinfo and other URL fields, and directly asserts correct URL composition. Specifically, the assertion in the test should be modified so that for each call in mocked_fetch.call_args_list, the argument at [0][1] is parsed as a URL, and the test asserts that the scheme is "https", host is "test-account.snowflakecomputing.com", and port is 443 (or the absence of port in the netloc is OK if the library omits explicit port 443).

This requires adding from urllib.parse import urlparse if not already imported in this file.
The instrumentation of the assertion should be changed from a startswith check to an explicit dissection and validation of the URL fields.

---

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.