There might be some security implications to this.
Why is this needed?

In D25926#24890, @avivey wrote:

There might be some security implications to this.
Why is this needed?

It is useful for logged-out users to know some more info about repositories, including but not limited to:

• Repository management log;
• Default language and encoding;
• Staging and automation;
• Repository limits;
• ...and so much more as read-only

Why would a logged-out user (who does not want to or cannot create an account) want to know about Repository management log or Repository limits? I don't see how that's their business (or interest)?

In D25926#24895, @aklapper wrote:

Why would a logged-out user (who does not want to or cannot create an account) want to know about Repository management log or Repository limits? I don't see how that's their business (or interest)?

I think repository log is only for possible breaking changes (ie. (dis)allowing large and dangerous changes, or even [rarely] changing the repo name). Fetch timeout (on limits) can be useful on rare cases (such as troubleshooting clone/fetch problems if it's not their end).

Uhm. Good points:

• this may be in line with the Phorge UX policy of "don't hide unavailable features" (but just disable them) - and I generally appreciate this in Phorge (while not fully relevant worth mentioning)
• I think that Phorge may have the technical possibility to do this in a safe way (if we test it better...), while other competitors work more like "security through secrecy" so if you can see the Settings you can edit the Settings, and Phorge is interestingly better in this

Bad points:

• more search engine rabbit holes (but maybe not that bad)
• finding this kind of pages on search engines is a bit scaring (maybe more a perceived problem)
• being able to visit that page without even registering sounds a bit scaring to normal users (again, more perceived problem)
• I'm very very scared about possible consequences too lol :D Heavy test plan really needed

In D25926#24898, @valerio.bozzolan wrote:

• more search engine rabbit holes (but maybe not that bad)

robots.txt can have the solution for that (see below).

• finding this kind of pages on search engines is a bit scaring (maybe more a perceived problem)

Agree with you, especially if the sysadmin doesn't care about robots.txt

• being able to visit that page without even registering sounds a bit scaring to normal users (again, more perceived problem)

But any click results in a Login Required dialog. It does indeed look scary (especially destroy, which actually doesn't work on the web interface)

• I'm very very scared about possible consequences too lol :D Heavy test plan really needed

For search engines, the solution is to add this to robots.txt:

Disallow: /source/*/manage/

Note that I don't know a lot about the right syntax for robots.txt, but what I shown above does not apply if the file already contains Disallow: /source/

As for possibly being scary to visit the repo management, no one should truly worry as there is nothing they can change (anything shows Login Required)
Actually, Edit Menu in the Home app initially sounded scary to me and I though what I would do applies to everyone before properly understanding that is is personal and not global.

In D25926#24899, @Cigaryno wrote:

robots.txt can have the solution for that (see below).
[...]
For search engines, the solution is to add this to robots.txt:

In theory yes if everyone behaved. In practice, robots.txt is ignored and LLM/AI crawlers are ruthless. (For example, GNOME GitLab admins recently installed Anubis to run background checks on your machine.)

Can this be further reviewed?

What is there to "further review"? It's two lines...

In D25926#25064, @aklapper wrote:

What is there to "further review"? It's two lines...

I mean if someone is ready to accept this revision.