A version tag like @v1 or a branch like @master is a movable pointer:
whoever controls the action repository can re-point it, and the next
run executes whatever it points at. Several of these actions run in
jobs whose outputs ship to users: build-release.yml creates the GitHub
release with the downloadable binaries, and build-windows-hosts.yml
holds the SignPath signing token, so a re-pointed tag there could ship
a tampered or wrongly signed release. This is exactly how the
tj-actions/changed-files compromise propagated (CVE-2025-30066).
Pinning by full commit SHA makes the reviewed code the code that runs,
the same way docker/setup-qemu-action is already pinned in
build-linux-vms.yml. Refs that pointed at master (cross-platform-actions,
setup-alpine, get-latest-release) are pinned to their latest release
tag. Every pin keeps a version comment, and each SHA was resolved from
the upstream repository and cross-checked against its release tag.
* CI: add loong64 build workflow
Add reusable workflow for building fastfetch on LoongArch 64-bit
architecture using QEMU user-mode emulation + Docker container
(lcr.loongnix.cn/debian:14). Integrate into CI pipeline and
release dependencies.
* CI (loong64): pin docker/setup-qemu-action to full commit SHA
Pin to 06116385d9baf250c9f4dcb4858b16962ea869c3 (v4.1.0) for
immutable action reference as required by Codacy.
```
kde-output-device-v2-client-protocol.h:257:9: error: implicit declaration of function 'wl_proxy_marshal_flags'; did you mean 'wl_proxy_marshal_array'? [-Werror=implicit-function-declaration]
257 | wl_proxy_marshal_flags((struct wl_proxy *) kde_output_device_registry_v2,
| ^~~~~~~~~~~~~~~~~~~~~~
| wl_proxy_marshal_array
```
Thibaud-Vdb