5 ms·

Curious why you say this isn't suitable for authN? This seems maximally suited for processes where changes (or more likely, additions) in a split out system (au

by hirsin 4y ago

Curious why you say this isn't suitable for authN? This seems maximally suited for processes where changes (or more likely, additions) in a split out system (authn, authz) may immediately rely on behavior or interface changes elsewhere.

mh- 4y ago
I interpreted that to be an example reason, not an example workload.
aseipp 4y ago
I just mean that, I don't see how to properly integrate the josh-server with my SSH keys to do access, how to apply basic roles of who can push/read to what workspace, etc. If I wanted to do this at work "How does it integrate with authentication" is like a #1 concern from an infosec team who'd sign off. If the answer is "It doesn't, use something in front of it" that might be OK too. In fact I think authenticating and authorizing access to components of a monorepo is definitely in scope for its design, and could allow really powerful and cool things. But I just don't think it does that yet. Maybe it shouldn't. That's all I mean. It's not like a hard rule. There were some other things that I thought might hold me up, but I can't remember them now... Not sure if you've ever used it but there's some self-hosted software out there called 'gitolite' that does a lot of this. Perhaps they can be made to work together seamlessly...
- vlad_ivanov 4y ago
  ACLs are in the works https://github.com/josh-project/josh/pull/561 https://github.com/josh-project/josh/pull/561 That being said, the overall scope of permissions and authentication is more complicated, more improvements is definitely needed
- chrschilling 4y ago
  The whole topic of access control is way more work than you might expect: There is already an idea and initial implementation of path based ACLs for Josh. However, even if that concept was perfect and already implemented, it would be kind of useless. Why? To be useful in practice we would need a UI for code review in a monorepo. This UI would need to aware of the "workspaces" and ACLs in the repo and respect them when showing files and diffs to the users. As it stands now, Josh is used together with either Gerrit or GitHub (or similar). Patches or PRs are always being reviewed in the context of the full backing monorepo. As long as those are the only options to do code review, I don't see the value of having access control at the Git level. That being said, I am planing to create a new code review tool that does support these things, but it has a long way to go before it will be a serious alternative to the common tools used today.

by hirsin 4y ago

mh- 4y ago

I interpreted that to be an example reason, not an example workload.

aseipp 4y ago

I just mean that, I don't see how to properly integrate the josh-server with my SSH keys to do access, how to apply basic roles of who can push/read to what workspace, etc. If I wanted to do this at work "How does it integrate with authentication" is like a #1 concern from an infosec team who'd sign off. If the answer is "It doesn't, use something in front of it" that might be OK too. In fact I think authenticating and authorizing access to components of a monorepo is definitely in scope for its design, and could allow really powerful and cool things. But I just don't think it does that yet. Maybe it shouldn't. That's all I mean. It's not like a hard rule. There were some other things that I thought might hold me up, but I can't remember them now... Not sure if you've ever used it but there's some self-hosted software out there called 'gitolite' that does a lot of this. Perhaps they can be made to work together seamlessly...

vlad_ivanov 4y ago
ACLs are in the works https://github.com/josh-project/josh/pull/561 https://github.com/josh-project/josh/pull/561 That being said, the overall scope of permissions and authentication is more complicated, more improvements is definitely needed
chrschilling 4y ago
The whole topic of access control is way more work than you might expect: There is already an idea and initial implementation of path based ACLs for Josh. However, even if that concept was perfect and already implemented, it would be kind of useless. Why? To be useful in practice we would need a UI for code review in a monorepo. This UI would need to aware of the "workspaces" and ACLs in the repo and respect them when showing files and diffs to the users. As it stands now, Josh is used together with either Gerrit or GitHub (or similar). Patches or PRs are always being reviewed in the context of the full backing monorepo. As long as those are the only options to do code review, I don't see the value of having access control at the Git level. That being said, I am planing to create a new code review tool that does support these things, but it has a long way to go before it will be a serious alternative to the common tools used today.