Hi cedric.lamalle, great to hear. Just to let you know the beta version you are refering was created specifically for plugin developers to update their code to be compatible with 2.4. It isn't intended for production installations. 2.4.0 should be out next week.

Cheers,

Jason Hinch
Feature Lead/Stash Developer

Just saw that it will be out in next version. I've downloaded and tested v2.4.0-beta1 and this looks like exactly what we wanted.
Thanks!

Here is one use case: We have project that needs to be worked by different teams at different locations. Part of the code needs to be protected and can only be worked/viewed by US location. This would help me restrict remote site users from accessing a perticular repo of a project. Most companies have this sort of limitations due to goverment and other regulations....
We can't be the only one

I was trying to make the branch permissions do exactly what everyone here is asking, but it doesn't work. Right now, our use case is that we have a slow migration to git from SVN. I have mirrored all of our 12 SVN repos into 5 diferent projects. However, for the first stage of migration, we only want 1 repo exposed, and it's in a project with 2 other repos that we don't want exposed until the next stage. At this point, it seems we have to trust the developers not to push to other repos.

I find it extremely odd that an enterprise product from Atlassian doesn't seem to have any thought for permissions when all other Atlassian products are very well thought out in terms of granular permissions. I'd like this escalated for immediate consideration.

Also, the auditing mentioned by Jerry Qassar above would be extremely helpful as well.

Mr. Mielke is absolutely correct: Auditing is forensics. We need something better than what we have that is visible to stakeholders without the sysadmin team having to parse down a full Tomcat log of all accesses (including people looking at pages or Fisheye/whatever scraping repos every five seconds, which doesn't really help). At least when hosting svn over Apache I can easily pare down to a log of actual operations. Ideally, the logging/auditing UI is going to show interactions with a repository or its settings by user account, with time stamp, through the site UI, and potentially exportable. That means push logging, data changes, so on.

I'm going to put this link up again, because the screens on it are exactly what we need in this regard:
https://support.enterprise.github.com/entries/22260573-audit-logging

In regards to permission schemes, I really do think Stash needs to adopt a scheme similar to JIRA/Confluence. JIRA has the permission schemes that can be applied broadly and customized minutely, and Confluence does the matrix-style permission grant table (and inherited permissions for view/edit). If it were me doing it, I would say:

• You need something at global level, inheritable to projects, which controls the permissions to 'system' functions of a project and its repos.
  o This would include key renames, repo adds/renames/deletions, and project settings changes or deletions.
• You also need a UI-based way to control the ability to do unsafe operations (force pushes, rebases on master, so on).
• You could apply these broadly across projects using the scheme method from JIRA, toggle customization at the project level (admin permission), and let project admins customize it down at the repo level.
• All these actions need to be loggable and viewable.

(I think at this point perhaps the priority should be raised?)

Enterprise level requirements with teams of 100+, we can't rely on audit to prevent problems. Audit is definitely important but usually it is late / after the damage is already done that it is used to figure out what happened, or to ensure that corporate policies are being followed. Enforcement is the requirement.

I think it might be simplest if each repository was either project or repository based permissions. In the case of project it would be "inherit from project" without any need to customize. In the case of per repository permissions, it would ignore the project permissions entirely.

I think this would work best because it makes it simpler to understand and simpler to implement. Crossing the repository permissions with the project permissions is a bit magical and it's not clear that one model would meet all requirements. (Union? Intersection? Some way to define override vs fallback permissions? Yuck...)

The two concepts are only orthogonal under the current security model. The security model is currently muddy because there's a blending of repository and project permissions. There are definitely important permissions needed at the project level (visibility of the project itself is an important one, as well as the typical creating/deleting/renaming repos, changing keys, changing permissions, etc.). But, IMHO, repository permissions should be defined/applied at the repository level.

I would agree with Alex's suggestion: allow defaults to be defined, but those defaults should be "copied down" and applied to each repository when created. I also definitely agree with the desire to keep things easy clear and easy to understand. A project that contains even just several dozen repositories would be difficult to administer (and quickly review or "audit") if you had to visit repositories individually and view the permissions for each. So, a project-level way to view/administer security permissions does makes sense...

Just throwing out one idea: At the project level, imagine a table with repositories along one axis and access groups along the other. In each cell would be a control (drop-down, toggle, other?) to select between the different access levels: commit/read-only/none. It would likely get unwieldy and dense, but it's one solution, right?
A better option might be to display a list of the groups/users associated to a project. As each item is selected in the list, display all of the repositories and permission level associated to each group/user.

The #2 use-case (open ONE) would be accomplished by adding a new group to the project but only applying it to the one (or two) repository(ies).

Just some additional thoughts, FWIW. I have full faith that Atlassian can come up with a feasible solution.

I think the "Restrict ONE" is probably the case that applies more often in a corporate environment. If users want to allow anyone to access a repository then they can just remove all restrictions.

But better still would be to implement what Alex Antonov has suggested.

So would it then make sense to have a one, and simple, model, where you can have a set of permissions per project, which would be inherited by all the repositories in the project, but give an ability to override those on a per-repository level? Or even better yet, to make the access permissions be controlled on a per-repository level, and the project permissions would define who can create repositories and do other administration of the project/containing repositories?

Thanks for the feedback. There seem to be two major use-cases:

1. Restrict ONE (or few) repositories further to trusted individuals while external collaborators have access to the remaining repositories in the project.
2. Open ONE (or few) repositories to external collaborators without granting broad access to the remaining repositories in the project.

These two concepts are orthogonal to each other. One allowing administrators to restrict repositories further while the other one opens up access. Catering for both concepts is almost impossible while maintaining a clear and easy to understand user experience, which is especially important for security features. Whichever use case we pick, it will still be possible to cater for the other one with the inconvenience of maintaining a separate project.

Generally, our goal with Stash is to empower users as much as possible. Auditing is important to ensure that the power comes with the right level of accountability and we have plans to address this in a future release. In the meantime it's worthwhile to note that Stash does record access logs, providing you with details for every single interaction with Stash.