I noticed in the following commit that now if a build is submitted by
git.sr.ht on a repo where multiple people have access, then instead of
the repo owner executing the build job, the pusher will:
https://git.sr.ht/~sircmpwn/git.sr.ht/commit/59efc979876f01d701e321e38d45c3147fb5f290
I understand the security concern (even though I'd say giving full
read/write access to a repo is a very broad permission in of itself),
but considering that organizations are not implemented yet, this poses
a bit of a problem, since if I understand correctly, only paid accounts
to which one has manually shared the secret from the organization
account are able to submit jobs for repos to which they just contribute
to, which is a partial solution at best.
Am I missing something here or was this an oversight?
>This is by design -- sharing secrets is the intended approach now.
I see, fair enough, but until organizations are implemented what about the case of collaborator accounts?
IIUC, it's not only related to secrets (which indeed can be shared), but
also to the current usage of sharing a repository in an
organization-like account and using that repository to run CI jobs with
a common paying account (as suggested at
https://man.sr.ht/ops/builds.sr.ht-migration.md).
So previously, if ~user (identified by their SSH key) pushed to
~org/repo, the job was run with ~org account. Now it is run with ~user
account. So, previously, this worked as ~org is paying, but now it does
not as ~user is not paying.
>IIUC, it's not only related to secrets (which indeed can be shared), but also to the current usage of sharing a repository in an organization-like account and using that repository to run CI jobs with a common paying account (as suggested at https://man.sr.ht/ops/builds.sr.ht-migration.md).>>So previously, if ~user (identified by their SSH key) pushed to ~org/repo, the job was run with ~org account. Now it is run with ~user account. So, previously, this worked as ~org is paying, but now it does not as ~user is not paying.
Yes indeed basically
Also sidenote but wouldn't this make build lists disjointed resulting in
build status images not reporting the correct status? If so maybe a
more elaborate collaborator check would have to be implemented