Skip to content

Do not expose GPG exception details in HTTP 500 responses#3

Open
flightlesstux wants to merge 1 commit intomasterfrom
fix/gpg-exception-information-disclosure
Open

Do not expose GPG exception details in HTTP 500 responses#3
flightlesstux wants to merge 1 commit intomasterfrom
fix/gpg-exception-information-disclosure

Conversation

@flightlesstux
Copy link
Copy Markdown
Owner

Problem

GpgAuthenticator::_initKeyring() appends the raw GPG library exception message directly into the InternalErrorException that propagates as an HTTP 500 response:

// Before
$msg = __('The OpenPGP server key defined in the config cannot be used to decrypt.') . ' ';
$msg .= $exception->getMessage();
throw new InternalErrorException($msg, 500, $exception);

GPG library error strings routinely contain internal details that should not reach HTTP clients:

  • Absolute file system paths (keyring location, socket paths)
  • GPG key IDs and fingerprint fragments
  • Passphrase error hints
  • GnuPG agent status information

Fix

Log the exception detail internally using CakePHP's Log facade and throw the InternalErrorException with only the static, safe message string:

// After
Log::error('GpgAuthenticator: ' . $exception->getMessage());
throw new InternalErrorException(
    __('The OpenPGP server key defined in the config cannot be used to decrypt.'),
    500,
    $exception
);

Operators retain full observability through the application log. The original exception is still passed as the third argument to InternalErrorException so it remains available in the exception chain for debugging.

Impact

  • HTTP 500 responses no longer include GPG internals
  • No change to logging behaviour — detail is preserved at error level
  • No functional change to authentication flow

_initKeyring() appended the raw GPG library exception message
directly to the InternalErrorException message string:

    $msg .= $exception->getMessage();

GPG library errors can contain internal file paths, keyring
locations, key IDs, and passphrase hints that should not be
visible in HTTP responses. The exception is re-thrown as a
500, which CakePHP can surface in API error responses.

Log the exception detail at error level via CakePHP's Log
facade so operators retain full observability, and throw the
InternalErrorException with only the static, safe message.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant