Fix agent handling of 403 Forbidden registration responses

[sarroutbi]

The agent was incorrectly interpreting 403 Forbidden responses from the registrar as API version incompatibility errors. This caused two problems:

1. The agent would try all enabled API versions, even though 403 indicates a permanent security rejection (e.g., TPM identity mismatch during re-registration)

2. The agent would continue running after registration failure, making it appear operational when it was not properly registered

This issue became apparent with the Python keylime registrar security fix for CVE-2025-13609 (duplicate UUID vulnerability), which returns 403 Forbidden when an agent attempts to re-register with a different TPM identity.

The agent will now correctly fail fast when the registrar rejects registration for security reasons, allowing proper error detection in tests and production deployments.

Related: keylime/keylime#1820 (Python registrar UUID spoofing fix)

[codecov]

Codecov Report

❌ Patch coverage is 20.83333% with 19 lines in your changes missing coverage. Please review.
✅ Project coverage is 57.32%. Comparing base (a7cafe7) to head (eab1619).
⚠️ Report is 1 commits behind head on master.

Files with missing lines	Patch %	Lines
keylime/src/registrar_client.rs	29.41%	12 Missing ⚠️
keylime-agent/src/main.rs	0.00%	7 Missing ⚠️

Additional details and impacted files

Flag	Coverage Δ
e2e-testsuite	57.32% <20.83%> (-0.11%)	⬇️
upstream-unit-tests	57.32% <20.83%> (-0.11%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
keylime/src/config/testing.rs	33.81% <ø> (ø)
keylime-agent/src/main.rs	15.28% <0.00%> (-0.29%)	⬇️
keylime/src/registrar_client.rs	75.71% <29.41%> (-3.00%)	⬇️

... and 5 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[sergio-correia]

Calling process::exit directly in the business logic is problematic because it skips resource cleanup (e.g. drop handles will not run, leaving TPM handles, file locks, network connections and other resources unreleased), and it also makes it not testable. You should likely use a more idiomatic pattern of propagating the error via Result and have main() decide to exit.

Something like this (change main() signature to return Result):

  async fn main() -> Result<()> {
      // ... existing code ...

      match keylime::agent_registration::register_agent(aa, &mut ctx).await {
          Ok(()) => (),
          Err(Error::RegistrarClient(
              RegistrarClientError::RegistrationForbidden { message },
          )) => {
              error!("Failed to register agent: Registration forbidden - {message}");
              error!("This indicates a security rejection (403 Forbidden), likely due to TPM identity mismatch or UUID
  spoofing attempt.");
              error!("The existing agent record must be deleted before re-registering with a different TPM.");
              return Err(Error::RegistrarClient(
                  RegistrarClientError::RegistrationForbidden { message },
              ));
          }
          Err(e) => {
              error!("Failed to register agent: {e:?}");
              // Decide: should other registration errors also be fatal?
              return Err(e);
          }
      }

      // ... remaining of main ...

      Ok(())
  }

Note: The Rust runtime automatically converts Err from main() to a non-zero exit code, so the external behavior (process exits with error) remains the same while ensuring proper cleanup.

[sarroutbi]

Regarding the rest of the registration issues, I just wanted to be "as less aggressive as possible". I am not sure we should change Pull Mode agent behavior for registration issues not related to registry duplicate UUID issue.

[sergio-correia]

Thanks, this looks good to me. In the future we can add some testing to cover the new RegistrationForbidden path.