FSKY Foundry is now Gitfield. All users, organizations, repos, and other things remain. Update your remote URLs, container image tags, and logins from foundry.fsky.io to gitfield.org.
The service-hardening section says the example unit applies a restrictive umask, but contrib/systemd/gibcert.service contains no UMask= directive. The changelog explicitly records removal of the former UMask=0077, so the current guide overstates the shipped unit's protections.
Make the security guidance match the actual service. Either restore a restrictive umask after checking its effect on deploy hooks and generated files, or remove the claim and describe the protections the unit really enables. Do not leave an inaccurate hardening claim.
Acceptance: documentation and shipped unit agree on umask behavior, with any chosen setting covered by an operational check for private key/state and deployed-file permissions.
The service-hardening section says the example unit applies a restrictive umask, but `contrib/systemd/gibcert.service` contains no `UMask=` directive. The changelog explicitly records removal of the former `UMask=0077`, so the current guide overstates the shipped unit's protections.
Relevant files: `docs/systemd.md:70-79`, `contrib/systemd/gibcert.service:7-31`, `CHANGELOG.md:25-30`.
Make the security guidance match the actual service. Either restore a restrictive umask after checking its effect on deploy hooks and generated files, or remove the claim and describe the protections the unit really enables. Do not leave an inaccurate hardening claim.
Acceptance: documentation and shipped unit agree on umask behavior, with any chosen setting covered by an operational check for private key/state and deployed-file permissions.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
The service-hardening section says the example unit applies a restrictive umask, but
contrib/systemd/gibcert.servicecontains noUMask=directive. The changelog explicitly records removal of the formerUMask=0077, so the current guide overstates the shipped unit's protections.Relevant files:
docs/systemd.md:70-79,contrib/systemd/gibcert.service:7-31,CHANGELOG.md:25-30.Make the security guidance match the actual service. Either restore a restrictive umask after checking its effect on deploy hooks and generated files, or remove the claim and describe the protections the unit really enables. Do not leave an inaccurate hardening claim.
Acceptance: documentation and shipped unit agree on umask behavior, with any chosen setting covered by an operational check for private key/state and deployed-file permissions.