Process exits with status 0 even when collection fails

[p0dalirius]

Summary

Every error path in main() uses return to abort, which leaves the process exit code at 0. As a result, callers (CI pipelines, shell scripts, orchestration tooling) cannot distinguish a successful collection from a failure such as a bad LDAP credential, an unreachable DC, or a failed file write.

Location

• File(s): main.go
• Line(s) / function(s): main() error branches at L85, L100, L105, L119, L130, L135

Category

api-contract

Severity

medium

Impact: silent failures in automated environments. Pipelines that gate on ./KeyCredentialHound ... will treat every failed run as a success and continue downstream steps on stale or missing output.

Reproduction / Evidence

Verified by code analysis:

• main.go:82–86 (credentials), L97–L100 (session creation), L102–L105 (connect), L116–L119 (query), L127–L130 (serialize), L132–L135 (write): every error branch invokes logger.Warn(...) followed by return. None call os.Exit(1) or otherwise propagate a non-zero exit code.

Reproducible at runtime:

$ ./KeyCredentialHound -dc 127.0.0.1 -u u -p p -d example.com
[WARN] Error connecting to LDAP: ...
$ echo $?
0

Expected Behavior

A non-zero exit status (e.g., 1) when the collection cannot complete successfully.

Actual Behavior

Always exits with status 0, even when the LDAP connection fails or the output file cannot be written.

Root Cause

Error branches use return from main() rather than os.Exit(non-zero) or a top-level error propagated up.