Secure ROCm apt repo setup in build_cmake workflow

[sanjay20m]

Summary

This PR hardens the ROCm apt repository setup in the build_cmake GitHub Actions workflow to prevent potential supply chain attacks.

Changes Made

• Enforced HTTPS for ROCm repository URLs
• Removed insecure flags:
  • --allow-insecure-repositories
  • --allow-unauthenticated
• Replaced deprecated apt-key usage with signed-by keyring method
• Added SHA256 checksum verification for ROCm GPG key before adding
• Scoped GPG key trust to ROCm repository only, reducing risk of key misuse

Security Impact

These changes:

• Prevent possible MITM attacks by requiring TLS for repo communication
• Ensure ROCm packages are verified via a trusted, scoped GPG key
• Avoid bypassing signature and authentication checks in CI builds

Rationale

GitHub-hosted workflows that install packages from third-party repos must ensure:

• The repo is served over HTTPS
• Keys are verified and scoped to the intended repository
• No flags weaken apt’s security model

This change addresses a potential supply chain vulnerability in the GitHub Actions workflow by enforcing secure package verification.

[meta-cla]

Hi @sanjay20m!

Thank you for your pull request and welcome to our community.

Action Required

In order to merge any pull request (code, docs, etc.), we require contributors to sign our Contributor License Agreement, and we don't seem to have one on file for you.

Process

In order for us to review and merge your suggested changes, please sign at https://code.facebook.com/cla. If you are contributing on behalf of someone else (eg your employer), the individual CLA may not be sufficient and your employer may need to sign the corporate CLA.

Once the CLA is signed, our tooling will perform checks and validations. Afterwards, the pull request will be tagged with CLA signed. The tagging process may take up to 1 hour after signing. Please give it that time before contacting us about it.

If you have received this in error or have any questions, please contact us at [email protected]. Thanks!

[mnorris11]

@ItsPitt

[meta-cla]

Thank you for signing our Contributor License Agreement. We can now accept your code for this (and any) Meta Open Source project. Thanks!

[sanjay20m]

Hi, can I know what further changes I will have to make, like any tweaks required ??

[mnorris11]

Hi, can I know what further changes I will have to make, like any tweaks required ??

Our friends at AMD are best equipped to review this one @ItsPitt (when you have time)

[sanjay20m]

After a long time, just to ask if any changes are required, please tell me :)

[ItsPitt]

Hi, can I know what further changes I will have to make, like any tweaks required ??

Our friends at AMD are best equipped to review this one @ItsPitt (when you have time)

I think this looks good from our side!

[junjieqi]

@sanjay20m looks there is a build failure, could you help take a look? Thanks! After everything is green, I will import the change

[sanjay20m]

Done ! @junjieqi

[facebook-github-bot]

@junjieqi has imported this pull request. If you are a Meta employee, you can view this in D82143282.

[junjieqi]

@sanjay20m looks like there is another failure on arm64 SVE

[sanjay20m]

Hi @junjieqi

Thanks for reviewing! I wanted to clarify that the change in this PR is strictly scoped to hardening the ROCm apt repository setup (HTTPS, signed-by keyring, checksum verification, removal of insecure flags).

The current build failure is happening in the Conda environment step, where the solver is revising libblas/libcblas/liblapack and exiting with code 1:

The following packages will be REVISED:
libblas 3.9.0-35 → 3.9.0-31
libcblas 3.9.0-35 → 3.9.0-31
liblapack 3.9.0-35 → 3.9.0-31

This looks like a Conda dependency resolution issue unrelated to the apt repo setup.
The security hardening applied here is valid and independent of that failure.

If needed, I can help pin the BLAS/LAPACK versions in the workflow or enable strict channel priority to resolve it, but I think it makes sense to review/merge the security fix separately since the two are orthogonal.

[junjieqi]

Hi @junjieqi

Thanks for reviewing! I wanted to clarify that the change in this PR is strictly scoped to hardening the ROCm apt repository setup (HTTPS, signed-by keyring, checksum verification, removal of insecure flags).

The current build failure is happening in the Conda environment step, where the solver is revising libblas/libcblas/liblapack and exiting with code 1:

The following packages will be REVISED: libblas 3.9.0-35 → 3.9.0-31 libcblas 3.9.0-35 → 3.9.0-31 liblapack 3.9.0-35 → 3.9.0-31

This looks like a Conda dependency resolution issue unrelated to the apt repo setup. The security hardening applied here is valid and independent of that failure.

If needed, I can help pin the BLAS/LAPACK versions in the workflow or enable strict channel priority to resolve it, but I think it makes sense to review/merge the security fix separately since the two are orthogonal.

Hi @sanjay20m , thanks for the reply. I'm wondering if we need to pin the BLAS/LAPACK first before this one. Once we pin them, and we could rebase current pr with master to resolve the build failure

[sanjay20m]

Hi! @junjieqi, now I think it may satisfy you ...

[junjieqi]

Hi! @junjieqi, now I think it may satisfy you ...

Thank you for your prompt response! Looks the linuxx86_64 still failed and it is related with the latest change. Thank you for your patience again!