Gitea: Repo names are not case-sensitive

[methodbox]

• Gitea version (or commit ref): 1.3.2
• Git version: 2.7.4
• Operating system:
• Database (use [x]):
  
  
  
  • [ ] PostgreSQL
  
  
  • [x] MySQL
  
  
  • [ ] MSSQL
  
  
  • [ ] SQLite
  
  
• Can you reproduce the bug at https://try.gitea.io:
  
  
  
  • [ ] Yes (provide example URL)
  
  
  • [ ] No
  
  
  • [x] Not relevant
  
  
• Log gist:

Description

When new repos are created and a home folder is generated, the naming convention is to name the folder using all lower-case letters.

This is not reflected in the UI.

As an example I created a repo called "fetchDNS".

The created folder on the server was "fetchdns"; this results in an error that the directory doesn't exist.
...

Screenshots

On the server:

:~/repos/methodbox$ ls
total 12K
drwxr-xr-x 3 git git 4.0K May 22 00:50 .
drwxrwxr-x 3 git git 4.0K May 22 00:49 ..
drwxr-xr-x 7 git git 4.0K May 22 00:50 fetchdns.git

[daviian]

@methodbox I think your actual problem was #4013 and not the capitalization of repositories, since this works like a charm. No problems here.

[lunny]

@daviian I think he means why not store the capitalization name on disk.

[mibcat]

yes - the different capitalization on disk and used URL is a problem on my system (#3728)

using the created URL with camel case leads to error:

changing the remote url to lower case (as stored on the disk) works fine:

[daviian]

@mibcat it seems to me as if you don't use the correct url. Why /volume1/gitea/? Usually the urls look like ssh://git@nas2:<user/org>/<repo>.git in your case

[mibcat]

gitea is running on a Synology Diskstation DS116.
/volume1/gitea is the root directory for all my repositories.
I have to put this path to all URL otherwise git access via ssh fails.
Maybe a misconfiguration ??? Any help to get rid of this _pre-path_ is appreciated.

But as I can see this is independent from the capitalize problem.
A push to the correct URL is working as you can see in screen shot above.

[techknowlogick]

@mibcat a response on another issue that @daviian gave a great response to may help you:

To clarify the SSH url: the stuff after the colon is for internal use in gitea. Gitea itself provides the mapping to the actual repository location.
So what you do when using the original path is bypassing gitea, which shouldn’t be possible at all!

One reason this happens is that you set your SSH key in the authorized_keys file yourself with e.g. ssh-copy-id. However that’s wrong and you should definitely let gitea handle this file.
Furthermore everytime a user adds an SSH key via gitea web-UI the authorized_keys file gets overwritten.

Another thing is that usually the user from the SSH url is git or whatever is configured in the app.ini and not the actual gitea-user itself.

The first thing you should try now is to go into the Admin settings on the gitea UI and execute:

Update the ‘.ssh/authorized_keys’ file with Gitea SSH keys. (Not needed for the built-in SSH server.)
Resynchronize pre-receive, update and post-receive hooks of all repositories.

After that you HAVE to set your SSH keys through gitea web-UI.

Hopefully that solves your issue!

[methodbox]

It seems the SSH issue and this issue are kind of related:

If you don’t have a key setup in Gitea UI you can’t use their URL because you can’t connect via their server daemon using SSH.

You can use the default Git path of git://hostname:/literal/path/to/repo if you have a key previously configured in ~/.ssh/authorized_keys.

So this begs the question: does Gitea store keys independently, and if so, why?

It seems the solution would be to at least give the user the option of using the default authorized_keys list. Then have the daemon listen for a request to the shortened URL and know that it’s association is with that given directory.

I fail to see why the shortened “Gitea URL” requires authorization independent of existing keys.

git-daemon can be enabled with the default Git install in Linux and allow this type of URL:

git://hostname/gitparentdir/repodir

You configure an absolute path(s) for the daemon to check (which would be prior to the Git parent in my example like /home/username/gitparent) and the URL is simply the host slash relative repo path.

...and it’s case-sensitive by default and works with existing authorized keys.

It seems like you’ve created your own daemon that doesn’t operate quite the same.

[daviian]

@methodbox I can give you a very concise answer to the question why gitea is keeping track of the keys itself.
If you manage your authroized_keys by yourself, e.g. append your public key, use ssh-copy-id or whatever doesn't prevent the person from actually login into the host via ssh.
Gitea prevents that by only allowing the user to use ssh in combination with git.
So if you've a system with many users (e.g. github) it would be a huge security risk letting everyone connect to your server and play around with folders/files and so on.
Furthermore each user would have access to everyones repositories, as for ssh and the server it is the same user, no matter who is trying to clone.
Gitea instead manages the permissions for each user by differ between ssh keys and giving them accurate permissions.

Oh and one more thing. SSH doesn't have the possibility to differ between hosts like nginx or apache with virtual hosts. It's simply not possible to do that.

By the way it's not only gitea that does it like that. Have a look at github ;-)

[mibcat]

@techknowlogick: thanks for the tip.
I think the problem was that I used the same ssh key for gitea which was previously uploaded via ssh-copy-id for the git user on the machine. gitea added the same key after the already existing key in authorized_keys.
==> If an access to a git repo via ssh take place the first key was taken (not handled by gitea) and therefore the correct full path must be given (including the right capital letters).

The solution for me was to create a new ssh key and upload it to gitea (and removing the git user key)
Then the URL can be something of ssh://git@nas2:<user/org>/<repo>.git
Btw: this solves also the _bare repro issue_ (#3458) ...

But a small drawback remains: using two different keys (for gitea and for git user) leads into problems which depends on the sequence the keys are loaded by ssh-add:

1) if the gitea key was loaded first, I'm not able to login:

michel@ideapad ~/tmp/Crc16 $ ssh git@nas2 PTY allocation request failed on channel 0 Hi there, You've successfully authenticated, but Gitea does not provide shell access. If this is unexpected, please log in with password and setup Gitea under another user. Connection to nas2 closed.
(maybe for the reason daviian mentioned right above this post)

2) if the git user key was loaded first, git is not working due to the wrong URL path and gitea does not get the request

[techknowlogick]

@mibcat Gitea should be the only thing that manages the authorzied_key file, which means you shouldn't be logging into SSH via the git user, if you need to manage the server (in your case your NAS) there should be another user that handles that.

Edit: If you want to clean up the authorized key file there is a quick way to do that in the Gitea admin panel "Update the '.ssh/authorized_keys' file with Gitea SSH keys."

[mibcat]

OK -I see.
Thanks !

[methodbox]

@daviian That makes perfect sense except that it’s incorrect.

With the default Git daemon you can allow Git via Git protocol (using Git:// as I mentioned before) without allowing SSH login.

You can also control SSH in a number of other ways (as you can see Gitea is able to do ;) ) so I’m not sure that’s a truly concise answer but it does explain that Gitea’s approach is to do this by default rather than require additional configuration, which I appreciate.

Thanks!

[techknowlogick]

Closing this thread now