Public visibility should also fit for LFS data regarding pipeline permissions
Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.
Current situation
With GitLab v18, the usage of Job Token allowlists was implemented and can be enforced for a whole instance. Enforcement implements more security but makes it necessary to populate the allowlist even for new projects which come up and use other projects as submodules.
The possibility to set projects to public visibility helps to break this necessity. Public projects (A) are consumable from other projects (B) (as submodules), even if they (B) are not part of the allowlist (of A).
In our company we have a lot of internal "Open Source" projects (called innersource) - developed from our company for the whole company. Therefore the visibility of these projects is always "public" as they can be used by everybody.
So this helped us while enforcing the security that the innersource projects can still be consumed by everybody without any pain and overhead.
Breaking issue
Unfortunately we now noticed that the public visibility does only work for "usual" source data. For LFS data populating the allowlist with consuming projects is still necessary. Otherwise usage of submodules will break for the LFS files.
This means that all projects containing LFS data need to have the allowlist populated and adjusted all the time new projects will be created and want to consume innersource projects.
As the future is to have much more public visible projects, it is fundamental for us, that public visibility does also work for LFS data in case of the job token permissions
Proposal
Please implement the job token feature with respect to LFS data the same way as it is for "normal source data". Public visibility should also count for LFS data.
We work on self-hosted GitLab instances - so this feature should also be available there.