Since the last update all groups are listed on the "Explore Groups"-page (https://gitlab.com/explore/groups) for non-registered users. I think groups that only contain private or internal projects should be hidden from this page if the user doesn't have permissions to see them.
Yeah just noticed this myself and it's not great to have private groups all browseable as anon. users - means that a private gitlab repo server exposes not only the group names but also the number of projects in those groups.
It's intentionally not okay. It means you cannot host a GitLab server on a public network without exposing Groups and the Number of repositories they have to all anonymous browsers / search engines.
@vsizov@yorickpeterse group names are public however showing number of projects and users should be hidden. I think we should make a fix that hide information related to users/projects on Explore groups page.
@lpackham i dont see anything wrong about showing such groups. Assuming names are public we dont leak any information. And its simple from implementation perspective
I remember having a similar discussion quite a while ago, so let me chime in with why group pages were made public in the first place.
The original Problem was this:
Before group pages which didn't have any public projects were private and would result in a 404 when an anoymous user tried to access them directly.
But because the namespaces in gitlab are unique you'd already get the error message that the group already exists when you'd try to create a new group with the same name.
This lead to some confusion for Users.
On the one hand you get a 404 page, on the other hand a message that the group exists.
My sugestion for the current problem would be to:
hide groups that don't contain any public/internal projects from the explore page
There isn't anything to explore on those pages for the average user anyway
hide groups that don't contain any public/internal projects from the search
keep the group page itself public when being accessed directly
Simply to avoid the confusion in the case I described above.
Also note that github does this the same way
I guess if anyone thinks the group page still displays to many information we could talk about this as well.
The only thing set in stone is the group name I think because of the technical requirements.
edit: public group pages where introduced in 8.0
In GitLab 8.0 all users and groups will have a publicly visible profile page. This removes some complexity and makes it clear why you can’t claim a name (which previously allowed you to find out what names existed). Private and internal projects will not be shown on these profile pages unless you’re allowed to see them.
@Hannes, agree with you, in summary: 'consumer need' is that private groups should hide. We have the technical challenges, so I guess it will take some time and creativity as it doesn't seem easy to solve with current architecture.
Hope @developers find a way, me as consumer can only say thank you in advance,
i dont see anything wrong about showing such groups. Assuming names are public we dont leak any information. And its simple from implementation perspective
It exposes the names of our clients in our case. Sure the names itself are public, but not the fact that we are working for them.
We're 14 days into this bug and the GitLab company response is nothing more than 'meh, it's this way'. For a product with such commercial offerings I'm feeling a bit like they're not taking customers seriously. Yes this is CE but these are the guys that buy EE. @dzaporozhets what's the ETA here on getting this sorted and can we please get a response that actually listens to customers on this thread.
I'd fork/fix myself but really that just causes problems then with later releases. Let's get this fixed please.
I like @haynes's proposal, and a few weeks ago I actually started to work on a solution to modify the "Explore Groups" page only to show groups that had public projects until I read the discussion in #3549 (closed). The fact that users keep creating new issues complaining about exposing groups seems reason enough to either revert the change or improve upon it.
There's no misunderstanding. It shouldn't of been done. Remember that the majority of users do not monitor merge requests and so would not of known (like me) that this was happening at all.
All you're saying there is the equiv. of Hitchhikers when they point out that we could of contested the destruction of our planet by visiting a place we wouldn't of known to.
As you are the actual author of the change - I actually had a look at the Merge Request and it gave NO REASON as to why it was done - other than a link to a private issue that we can't see. Thanks - so that just creates more 'misunderstanding'.
Thanks @stanhu for taking a look at an actual solution - but the Gitlab guys should really just be listening to their users - as you point out; users keep creating issues around this.
@lpackham You don't have to monitor merge requests, it's enough to read a Changelog or release blog post. What about linking a private issue, we don't use private GitLab anymore so now it's much easier. Sorry for that. We listen to our customers but believe it's not easy to satisfy all of them. But we are trying...
@lpackham With all due respect....
You sound incredible rude.
Please keep in mind that we need a solution that works for everybody. Not just for you.
After the last post from @dzaporozhets the only thing I saw from you was you getting rude.
You didn't even properly respond to his last comment.
Please take @luispa and @t-munk as a good example.
They are not happy with the change either, but they still can communicate their opinions without getting rude.
That's my personal opinion and no, I don't work for gitlab.
Now for solving the actual problem:
The public group pages were introduced because of this:
In GitLab 8.0 all users and groups will have a publicly visible profile page. This removes some complexity and makes it clear why you can’t claim a name (which previously allowed you to find out what names existed).
For more information and our discussion about this, please read the comments in !1219 (merged).
Mentioned Problems with the current implementation so far:
@lpackham:
Yeah just noticed this myself and it's not great to have private groups all browseable as anon. users - means that a private gitlab repo server exposes not only the group names but also the number of projects in those groups.
@t-munk:
It exposes the names of our clients in our case. Sure the names itself are public, but not the fact that we are working for them.
hide groups that don't contain any public/internal projects from the explore page
There isn't anything to explore on those pages for the average user anyway
hide groups that don't contain any public/internal projects from the search
keep the group page itself public when being accessed directly
Simply to avoid the confusion in the case I described above.
Also note that github does this the same way
@dzaporozhets:
group names are public however showing number of projects and users should be hidden. I think we should make a fix that hide information related to users/projects on Explore groups page.
@luispa:
I suggest implementing a "Private" option for groups, like you have for projects.
Apologies @haynes the notification came through at a moment where I got annoyed but I also got irritated about the fact that I was being linked to things with even less information with some @ Gitlab actually creating more confusion rather than less.
Thanks for the summary there - let's hope we get this sorted.
I don't think we need to overcomplicate a solution - some people want public, some people want the old way of hiding things and an option works just fine here.
@lpackham
While an option sounds easy, it's probably the one with the most implications technical wise.
I'm not saying that it's impossible, but it's quite complex.
For example:
You can link to groups in posts like this: @haynes-test
If we implement an option to allow some private groups, some links in a conversation suddenly give you a 404 page.
That's very confusing for the average user.
Also you can still check for existing groups as long as the signup is enabled because users and groups share the same namespace.
In that case you get the message that the name is already taken, but when you go to the url directly you get a 404 page.
Which message is the correct one?
@t-munk a 401, a 403 or the login page would leak the existence of the group the same way as the public group page.
If we want to do that we can just as well show an empty group page with just the name.
@Haydn first, if the private groups are not publicily listed in the search or explore page, i think it fine to report a 401 or a 403 since to end up on that page, you need to know the existance of it at the first place.
At least, it does not leak any sensitive information as it does now.
@Sadortun which sensitive information does the current group page leak?
Afaik it currently shows the group name (which you'd know even if you display an error page)
and the group avatar.
My point is, that it would be less confusing to render a group page that shows next to no information than an error page.
@haynes My point with the error codes was, that this is a source of the confusion. When accessing a group detail page, which is not public and the user is not logged in, he is not authorized to view it. But seeing a 404 says it's not there at all.
Usually we send a 401 if the user is a guest and a 403 if the logged-in user is not allowed to view a page.
About the sensitive information, I was merely talking about the group list page. But for the detail page, I'd says is less confusing to see an error page with the "correct" error code.
@iheart2code That sounds like an understandable workaround and highlights the need to revise this change. It looks like this would only cause an error if a user clicked on the "Explore groups" button or if a non-logged in user attempted to access a group.
I would also propose that the /explore UI should be a feature that can be enabled/disabled in Admin settings or in the GitLab settings file.
I manage an EE installation for a design agency. We have employees, contractors, and clients on the system. I really don't want anyone poking around in things they aren't explicitly members of.
I have successfully implemented a workaround for this bug with the following in /etc/gitlab/gitlab.rb:
## Block access to /explore to prevent anonymous users from## seeing a listing of all groups.## For more details on this issue, see:## https://gitlab.com/gitlab-org/gitlab-ce/issues/12658nginx['custom_gitlab_server_config'] = "location /explore {\ndeny all;\n}\n"
Make sure to run gitlab-ctl reconfigure after making this change.
This is fairly hacky, but it's upgrade-proof and it does work.
We tried something similar, but this doesn't fully fix the issue. If an anonymous user looks at the activity of a public project, they can click any user, and view all the groups they have access to in the same way as via the explore page.
So the main issue is that people who could register or create groups have always been able to find out if a group by a certain name exists via the "path already exists" error, but now ALL users get that information handed to them for free, regardless of their being signed in or not, the GitLab instance being open for registration at all, or the user being able to create groups.
Our original thinking was that group existence was already technically being leaked to users, so it wouldn't hurt (and would greatly simplify code around this area) to just make all groups public.
I think that all of the comments and issues stated earlier show that this change was not thought all the way through, and deserves more consideration, and either tweaking of access to private-ish groups or addition of a new configuration option.
While it is true that the group name checker does technically leak information, it leaks in a way that has a MUCH higher barrier to entry than just making all groups public by default. It's like you saw a spider in your house and, instead of deciding to kill the spider, you moved out and made your home into a spider refuge.
We work around that minor leak issue by placing a semi-random number at the beginning of each group name. For example, if GitLab were our client, the group name would be 12345-GitLab-Site-Redesign or something similar. We can also prevent clients & contractors from creating groups.
While it is true that the group name checker does technically leak information, it leaks in a way that has a MUCH higher barrier to entry than just making all groups public by default.
@iheart2code I completely agree! This was poorly thought out by us, and we will do something about it.
We have resorted to a very ugly and plain "do not allow any unauthenticated users" hack (patch file below, surely not idiomatic Ruby; the offsets might be slightly different for you because we have some other patches applied also) that simply redirects all anonymous requests to the login page (besides the login and "Forgot password?" pages).
Note that this is will not work if you have any public projects or want your users information to be public (we do not want either; our Gitlab installation is publicly accessible simply because we have external but private collaborations), they will be inaccessible after.
So far, it works for us (it would be great if Gitlab would support some kind of private mode out of the box):
Please not that the only way to completly hide the existence would be to render a 404 page.
Everything else (401, 403, login page, group page with name and avatar) still leaks the existence of the page to anonymous users.
Rendering a 404 page has it's own consequences.
Maybe we could:
hide private groups from the search and the explore page
Change the 404 page text to something like:
Make sure the address is correct, you have the neccessary access rights and that the page hasn't moved.
Simply not render links to private groups (in group mentions).
This way the text stays the same for all users and we avoid leading people to a 404 page.
Of course the drawback is that there might be some confusion why one group is being linked and another is not.
As far as I understand Rails, the :force_authenticated_user! method from our patch above triggers before any controller does its own content rendering/creating, and thus also overwrites 401/403/404 error pages (at least trying to access some non-existing resources results in a redirect to /users/sign_in) . Therefore, it should not leak the mere existence of anything to the outside world.
@caovc Thanks, but (unfortunately) we do have public projects.
@haynes I'd be fine with showing a 403 / 401 error in those cases. It means you "know" the URL already, and it's clear why something is failing. Just listing for everyone is what we have issue with.
@DouweM I think there is no win solution here. Adding private flag will make it annoying if you want every group to be private. Auto detection based on public projects wont work because group visibility depends on membership too. Performance wise detecting group visibility to certain user is expensive. Bringing extra config options also bad from complexity and code support. My proposal is either remove groups page from public access or implementing some global flag that affects whole instance: group visibility, user visibility etc.
From what I read the main problem is that the groups are now listed on the explore page and that the page leaks the number of members and projects.
So let's try to fix that first and then decide what to do with the group pages themself.
Performance wise detecting group visibility to certain user is expensive.
Would a boolean flag on the group itself work? We could set it to true as soon as at least one public/internal project is created.
I propose to limit the Explore groups page to only display groups with the public flag.
This list would be the same for all users.
We already have a tab to display all other groups the user is a member of.
So no need to change anything there.
@haynes agree lets fix exposing projects & members count first. Your idea with boolean flag is nice and simple but it brings some extra problem of informing people when group becomes visible and how to hide it again. Any ideas on it?
@dzaporozhets hmm... Maybe an email to the group owners and masters when the visibility changes?
To hide it again people would simply need to change the visibility of all projects in the group to private.
The Mail when it changes to public could have a text like:
The visibility of the group XY has been changed to public because the project XY has been created with the visibility set to public.
If you want to keep your group visibility private, make sure it doesn't contain any public projects.
We could also show an icon on the Your Projects tab next to the group.
Can we use visibility level on group, like we do on project, and automatically set it to the most-public of its child projects when the visibility level there changes/is set? We have a restriction for visibility levels on the application setting level already, which would also apply to groups.
To make it clear that the group is public, we can add the visibility level icons like we have on the top left of https://gitlab.com/gitlab-org/gitlab-ce.
@dzaporozhets I will schedule it for 8.6, with a large chance that that will change or that other stuff will be moved out of 8.6. I'm in the middle of bringing order to the milestones so until I get to go through 8.6 thoroughly, it is too full on purpose :)
@dblessing Seems serious, would be good to implements @DouweM his solution in 8.6. Maybe backporting is hard due to the database migration this will cause.
They would have to downgrade all the way to 7.14 and I'm sure there would be data-loss associated because they would have to restore an older db backup. If we can guarantee 8.6, that's probably sufficient.
I have been pointed here from another issue that I raised (#13964 (closed)), unfortunately I didn't find this issue when I searched before creating mine.
I see a lot of discussion around anonymous users, will the proposed fix (!3051 (closed)) cover the alternative use case of authorised users being able to see projects they don't have access to?
We provide logins for our clients but we don't want them to be able to see the groups for other clients we may work with; preventing authenticated users from seeing groups they don't have permission for is the main issue we have.
A temporary but immediate workaround if your organization requires confidentiality:
# /etc/nginx/sites-enabled/gitlab (...) location / { # serve static files from defined root folder;. # @gitlab is a named location for the upstream fallback, see below try_files $uri $uri/index.html $uri.html @gitlab; } location /explore { deny all; } (...)
Then:
$ sudo service nginx restart * Restarting nginx nginx [ OK ]```This will send a 403 error.
@Germain-Italic only denying /explore does not fix the issue in respect to confidentiality.
There are various other pages that still leak information (e.g., the group ones).
If you want to deny all access to any public information, the following ugly patch works (it currently applies with some fuzzy chunks but without issue; you need to restart unicorn after):
For my 2 cents worth, if a Group contains a public project it should be visible when not logged in. If a Group is empty or contains non-public projects (internal and / or private) then it should not be visible unless logged in. The page displayed should simply state that this is a protected page with a link to the login. This is not a 404 situation since the page does exist, it is simply a protected page.