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

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.

For us, the problem with letting project administrators do whatever they want as far as modifying keys is that it can break the resources of other teams or other sites over which they do not have control. And yes, the little problem about being able to delete repositories without sysadmin approval is a little problematic in an enterprise environment. :/ We have to be able to be accountable for all actions taken, especially in a situation where an outgoing person may feel motivated to make 'interesting' changes.

I definitely do not want to have to be the single project administrator for all Stash projects just to control this. As Mr. Feldhacker is saying, I want people to feel like they have control over the composition of their project--but to the extent offered by our enterprise. JIRA does this extremely well by using permission schemes, and only allowing system administrators to delete projects.

In our organization, one Stash project = one development team, as a general rule. A Stash project groups a set of related repositories (related in terms of ownership), and each repository contains one application (or "deployable unit"). If a development team expects to have so many repositories as to make managing them under a single project cumbersome (25-ish?), then multiple projects might be created for a team to logically group repositories by domain or functional area.

We use branch permissions to restrict access to the "master" branch, or any other branches intended to be stable. Only the individuals that are trusted enough to process pull requests and do code reviews are permitted access to these branches.

So, our need for repository permissions would fall into two categories:
1) Even though a development team might work on various applications / repositories, ONE of those repositories might be a security component (containing sensitive credentials, private keys, whatever) that needs even more restricted access. While we might like to give contractors and consultants access (read and probably commit) to the Stash project overall, we don't want them to have access to the security component (not even read access). But, to create a new Stash project that contains one repository just to setup security differently doesn't seem appropriate. (I would call a project with one repository an anti-pattern.)

2) Sometimes development teams need help. Additional resources (might be just 1 or 2 people) are brought in to assist for a relatively short period of time. While the development team might own and be responsible for 20-some different repositories, the "extra" resources should only have access to the 1 or 2 repositories that they need to work in. (The temporary resources should not even have read-access to the other repositories owned by the team.) It shouldn't be necessary to open up broad access and/or create new projects to accomplish this.

We like the Project concept in Stash – it allows us to empower users, within a certain scope. Development team leads create new applications / components all the time, and they shouldn't have to wait for an Admin to create a new repository. This would be even more common once forking comes along (as would deleting repositories). But, I agree to an extent what Jerry Qassar is saying: it would be nice if a bit more control was provided around what actions can/cannot be performed by admins at the project level (good auditing/logging at a bare minimum). If an admin can create a repository, I can see how they certainly should have the ability to "correct" a repo key and delete a repository altogether when it's no longer needed. I definitely think destructive operations should be made safer (don't delete a repository, archive it!), but in general we would still choose to "empower" our trusted users as much as possible.

Our main requirement will be the same use case mentioned by ISG Support above and we also have the same concerns and uses cases as mentioned by Jerry Qassar.

An example in our organisation is that one product = one stash project. We then split a product into several repositories within the project. Some of these repos for example need to be secured so that only certain users can access (such as secuirty specific stuff. Another example of this is external consultants only having access to certain repositories with a project. The only way of securing this right now is to create a new project for each of these repositories that need a differnet permission set.

On a side note, it would be useful for a project admin to be able to view the members of a group that he/she can assign to their project....

Thanks

Mirroring the capabilities of other enterprise Git offerings in regard to permission classes and auditing capabilities would be a huge start (https://gitent-scm.com/gitent/doc/GitEnterprise/Security.html, https://support.enterprise.github.com/entries/22260573-audit-logging).

Project administrators actually have far too much power in the current Stash model:

• They can freely change their project keys
• They can rename or delete repositories without any oversight
• These operations are not logged in an obvious, clearly visible way

It feels like the current Stash model is geared towards 'mini-enterprises' rather than central control by one enterprise. There are truly very few enterprises (especially ones with compliance standards) that would be okay with this model. In an enterprise environment, the idea that a project lead has the ability to move or delete repositories from the standard UI is extremely difficult to accept. As the system administrator who has to explain where repositories go, it's pretty much untenable.

In general:

• Privileged users cannot be easily prevented from doing 'ill-considered' operations.
• Pushes are not logged, audited, or directly traceable back to the account that performed them (STASH-2642).
• Stash doesn't actually use the details from user directories you authenticate against. I can make pushes (vis-a-vis commits) that show commits as being done by Mickey Mouse. Yes, this is a git 'feature', but any interaction I perform that modifies a Stash repository should have some way of be displaying the credentials of the account I used, my name and email from that account, and when I did it. (Going back to displaying push history,

Stash needs to have some sort of intermediate role...well, really, all roles need to be fully configurable just like JIRA's...but it needs to have a role appropriate for tech leads that we can configure, so that we can control things like who can add repos, rename them, delete them, force push, so on. gitolite, Git Enterprise, and other offerings are able to do this and it would be great if Stash could do the same.

We are starting work on this feature soon and would love to know what use-cases you have for repository permissions.

We have a project with different modules (repos) being developed by different companies. This feature would be very useful on this situation.

This is a big feature we need also. The ability to group repositories into Projects is wonderful, but not being able to put permissions on the individual repos is unfortunate.

Now that STASH-2481 is implemented in Stash 2.0, addressing this issue will provide a comprehensive solution for permissioning. I hope this gets considered for the next release.

When do you plan do introduce this? In any corporate environment this is important. Large projects, when you don't want to trust everyone (perhaps hundreds of developers) with a specific repository. We are on the fence about buying Stash 500 Users License because of this.

We do have plans to implement finer grained permissions in the future. I've renamed to title to better describe the feature request.