Hi hut inhabitants!
Like many of you, I store my dotfiles and machine configs on git.sr.ht,
but lately I've been trying to improve the separation between work and
personal machines for privacy and security reasons.
One brute force way would be to make untrusted machines pull-only and
export only the config they need with CI at a known URL, or push to a
different repo, but that means I can't sync back config changes from
them, also I don't think it's currently possible to grant access only to
a specific repo.
So I think my requirements are:
- store configs centrally
- nodes (machines, VMs, containers) can pull up to date configs and data
- nodes can't pull anything they shouldn't be able to see
- nodes can push changes that only affect them (maybe optional, but
highly desirable)
One way I can imagine doing this is with multiple Git repositories that
are tied together into submodules, since ACL within a single repo is not
really possible with Git's design.
There are two problems with this:
- there is no way to restrict SSH keys at all
- OAuth tokens can be restricted, but not to specific repos
- using OAuth for pushes would be cumbersome
- using multiple sr.ht accounts would work, but would require logging in
with multiple accounts at the same time, can't have subset relationships
on rights, billing for CI would also get confusing
I imagine these features would be even more desirable for bigger teams.
Are there any options I haven't considered? Are features like this
planned or even possible?
A previously proposed and approved feature request is to add SSH deploy
keys to git repositories, wherein you can add a specific SSH key to a
repo with read-only or read/write access rather than only granting
access to users.
Would that support your use-case?
On 2024-12-09 14:05, Drew DeVault wrote:
> A previously proposed and approved feature request is to add SSH deploy> keys to git repositories, wherein you can add a specific SSH key to a> repo with read-only or read/write access rather than only granting> access to users.> > Would that support your use-case?
Thanks for the scarily quick reply. :D
Found the discussion:
https://lists.sr.ht/~sircmpwn/sr.ht-discuss/%3C88e9bcb0-9f79-b3a8-73f7-10f2cf64a602@bpiotrowski.pl%3E
Yep, that seems to be the SSH key based solution I was thinking of, I
didn't know it had a name. That would work!
Great! The feature has been accepted for a long time but no one has come
forward to implement it. We might do it internally at Some Point™ but
the surest way to get it done is to send a patch.
On 2024-12-09 15:15, Cayetano Santos wrote:
>>lun. 09 déc. 2024 at 13:01, raingloom@riseup.net wrote:> >> Are there any options I haven't considered? Are features like this>> planned or even possible?> > Would guix authenticate be an option for you ?> > https://guix.gnu.org/manual/devel/en/html_node/Invoking-guix-git-authenticate.html> > --> Cayetano Santos> GnuPG Key: https://meta.sr.ht/~csantosb.pgp> FingerPrint: CCB8 1842 F9D7 058E CD67 377A BF5C DF4D F6BF 6682
No, that's only useful for checking commit authenticity, not access
control.