Use psycopg.conninfo.make_conninfo() to create PostgreSQL connection string

[jsf9k]

🗣 Description

This pull request modifies the Python code to use psycopg.conninfo.make_conninfo() to create the PostgreSQL connection string.

💭 Motivation and context

If the PostgreSQL password, for example, contains a literal backslash (\) character then we do not want it to be interpreted as the first character in a Python string escape sequence.

It is highly unlikely that anyone would choose a host name, database name, username, or password that genuinely contains special characters like \n, \t, etc.; therefore, it should be safe to treat all backslashes in the PostgreSQL connection string as literal backslashes.

🧪 Testing

All automated tests pass.

✅ Pre-approval checklist

• This PR has an informative and human-readable title.
• Changes are limited to a single goal - eschew scope creep!
• All relevant type-of-change labels have been added.
• I have read the CONTRIBUTING document.
• These code changes follow cisagov code standards.
• All new and existing tests pass.
• Bump version.

✅ Pre-merge checklist

• Finalize version.

✅ Post-merge checklist

• Create a release.

[coveralls]

Pull Request Test Coverage Report for Build 21264655225

Details

• 0 of 0 changed or added relevant lines in 0 files are covered.
• 8 unchanged lines in 1 file lost coverage.
• Overall coverage remained the same at 83.946%

---

Files with Coverage Reduction	New Missed Lines	%
guacscanner.py	8	82.61%

Totals
Change from base Build 21194023395:	0.0%
Covered Lines:	225
Relevant Lines:	272

---

💛 - Coveralls

[dv4harr10]

Hi Shane @jsf9k , just one comment, in the src/guacscanner/guacscanner.py file the instances where cursor.execute(ENTITY_COUNT_QUERY, (entity_name, entity_type)) is used these are examples of string concatenation which is a possible vulnerability for SQL injection. What's your thoughts?

[jsf9k]

Hi Shane @jsf9k , just one comment, in the src/guacscanner/guacscanner.py file the instances where cursor.execute(ENTITY_COUNT_QUERY, (entity_name, entity_type)) is used these are examples of string concatenation which is a possible vulnerability for SQL injection. What's your thoughts?

In this project I think it's OK. The values being concatenated do not originate from users but from the AWS API, and the latter is a trusted source.

[dav3r]

Makes sense, but we should still test that this actually works as intended.

[jsf9k]

Makes sense, but we should still test that this actually works as intended.

The only real way to test is to add a backslash to the PostgreSQL password in, say, our dev-a COOL environment. I will get @dav3r's assistance with that when we finish up the current cisagov/skeleton-packer Lineage wave.

[Copilot]

Pull request overview

Updates PostgreSQL connection string construction to use a raw f-string, aiming to avoid accidental escape-sequence interpretation when credentials contain backslashes.

Changes:

• Switched the DSN construction from an f-string to a raw f-string (rf"")
• Added an explanatory comment about backslashes in passwords

Comments suppressed due to low confidence (1)

src/guacscanner/guacscanner.py:772

• This comment states the raw string is needed to avoid Python string escape handling due to backslashes in the password, but that isn’t accurate for f-string interpolation (the password is a runtime value). Consider updating the comment to describe the actual escaping/quoting concern (conninfo parsing), or remove it if you switch to passing connection parameters instead of building a DSN string.

    # We use a raw string here since the password, in particular, could contain
    # a literal backslash.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated 2 comments.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.