Ensure SSL_CERT_DIR messages are always shown and check for existing value#13
Conversation
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Code Review by Qodo
1. Wrong path comparison uses $HOME
|
| ? Path.Combine("$HOME", certDir[homeDirectoryWithSlash.Length..]) | ||
| : certDir; | ||
|
|
||
| if (TryGetOpenSslDirectory(out var openSslDir)) | ||
| var hasValidSslCertDir = false; | ||
|
|
||
| // Check if SSL_CERT_DIR is already set and if certDir is already included | ||
| var existingSslCertDir = Environment.GetEnvironmentVariable(OpenSslCertificateDirectoryVariableName); | ||
| if (!string.IsNullOrEmpty(existingSslCertDir)) | ||
| { | ||
| var existingDirs = existingSslCertDir.Split(Path.PathSeparator); | ||
| var certDirFullPath = Path.GetFullPath(prettyCertDir); | ||
| var isCertDirIncluded = existingDirs.Any(dir => | ||
| { | ||
| if (string.IsNullOrWhiteSpace(dir)) | ||
| { | ||
| return false; | ||
| } | ||
|
|
||
| try | ||
| { | ||
| return string.Equals(Path.GetFullPath(dir), certDirFullPath, StringComparison.OrdinalIgnoreCase); | ||
| } |
There was a problem hiding this comment.
1. Wrong path comparison uses $home 📘 Rule violation ✓ Correctness
• The code computes certDirFullPath from prettyCertDir, which may contain the literal $HOME (a display string), not a real filesystem path. • This can cause false negatives when checking whether SSL_CERT_DIR already contains the certificate directory, leading to incorrect guidance and a spurious trust failure. • The compliance checklist requires explicit handling of edge cases and actionable, correct behavior in failure/decision points.
Agent prompt
## Issue description
`prettyCertDir` is a display string that may contain `$HOME`, but it is used for `Path.GetFullPath(...)` and equality checks against `SSL_CERT_DIR` entries. This can cause incorrect detection and guidance.
## Issue Context
`prettyCertDir` is derived specifically to print `$HOME/...` instead of the absolute home directory path, so it should not be used for filesystem comparisons.
## Fix Focus Areas
- src/Shared/CertificateGeneration/UnixCertificateManager.cs[350-408]
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
| sawTrustFailure = !hasValidSslCertDir; | ||
| } |
There was a problem hiding this comment.
2. Trust failure state overwritten 🐞 Bug ✓ Correctness
• TrustCertificateCore accumulates failures across multiple steps (.NET store, OpenSSL rehash, NSS DB), but later overwrites the failure state based only on SSL_CERT_DIR validation. • This can incorrectly report TrustLevel.Full even when earlier steps failed (e.g., NSS trust failures), misleading users and downstream logic. • The bug is caused by using assignment instead of combining with the existing failure state.
Agent prompt
### Issue description
`TrustCertificateCore` accumulates failures across multiple trust mechanisms, but later overwrites the `sawTrustFailure` flag based solely on SSL_CERT_DIR validation. This can incorrectly return `TrustLevel.Full` even when earlier trust steps failed.
### Issue Context
The SSL_CERT_DIR validation should contribute to trust outcome, but must not discard failures from .NET/OpenSSL/NSS steps.
### Fix Focus Areas
- src/Shared/CertificateGeneration/UnixCertificateManager.cs[358-414]
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
| var listener = new ReporterEventListener(reporter); | ||
| if (verbose.HasValue()) | ||
| { | ||
| var listener = new ReporterEventListener(reporter); | ||
| listener.EnableEvents(CertificateManager.Log, System.Diagnostics.Tracing.EventLevel.Verbose); | ||
| } | ||
| else | ||
| { | ||
| listener.EnableEvents(CertificateManager.Log, System.Diagnostics.Tracing.EventLevel.LogAlways); | ||
| } |
There was a problem hiding this comment.
3. Event 111 format mismatch 🐞 Bug ⛯ Reliability
• Program.cs now enables the EventSource listener even when not running with --verbose, so LogAlways
events are formatted and printed by default.
• Event(111) uses a message template containing "{2}" but only provides two payload parameters;
formatting this message with string.Format can throw and potentially crash the listener path.
• The listener currently does not guard string.Format with error handling, so a single malformed
event message can take down the tool execution.
Agent prompt
### Issue description
Event(111) message formatting is inconsistent with its payload (uses `{2}` but only passes 2 args). With the new default listener enabling LogAlways events, this can now surface as a runtime formatting exception.
### Issue Context
ReporterEventListener formats all received events via `string.Format` without exception handling.
### Fix Focus Areas
- src/Shared/CertificateGeneration/CertificateManager.cs[1307-1309]
- src/Tools/dotnet-dev-certs/src/ReporterEventListener.cs[21-35]
- src/Tools/dotnet-dev-certs/src/Program.cs[125-135]
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
Benchmark PR from agentic-review-benchmarks#3