#356 No anonymous https access to git repos

[OnyxG7]

It would be great to have a secure option when cloning git repositories anonymously.
Even better would be to use the same url everywhere (as on GitHub).

The docs page at http://sourceforge.net/p/forge/documentation/Git/ also needs to be updated (RW and RO sections), because it isn't clear what password to use for authenticated https access, and unauthenticated ssh clearly won't work.

[Zangune]

Hi, this seems a feature request to me.

What does it mean "It would be great to have a secure option when cloning git repositories anonymously."?

Here a random project git page (PDFedit), the recommended clone command is:

git clone git://git.code.sf.net/p/pdfedit/git pdfedit-git

git check the files

$ git clone git://git.code.sf.net/p/pdfedit/git pdfedit-git
Cloning into 'pdfedit-git'...
remote: Counting objects: 25991, done.
remote: Compressing objects: 100% (5811/5811), done.
remote: Total 25991 (delta 20297), reused 25542 (delta 19999)
Receiving objects: 100% (25991/25991), 21.08 MiB | 344.00 KiB/s, done.
Resolving deltas: 100% (20297/20297), done.
Checking connectivity... done.
Checking out files: 100% (1425/1425), done.

so git itself checks for files corruption.
What kind of security do you need?

Even better would be to use the same url everywhere

Are you talking about sf.net and sourceforge.net? /p/ and /projects/ in URLs?
They should be intercheangable.

it isn't clear what password to use for authenticated https access

Your SourceForge account password.
Under 'Accessing the repository via the shell' you can read:

Direct access to the bare repository is also available via [SSH], when logged into the shell, it will be available at:

/home/git/p/PROJECTNAME/MOUNTPOINT.git/

In the linked SSH page you can read

To get interactive access to SourceForge.net host, you must generate and post your SSH key and then use an SSH client to login to the host. This process varies depending on what client you are using. Graphical clients typically have fields that need such information as:

port: 22
hostname: cvs.sourceforge.net OR shell.sourceforge.net
protocol: SSH2 or SSH1 (SSH2 preferred)
username: Your SourceForge.net username
password: Your SourceForge.net password

anyway you are right: documentation needs to be updated.
In this case the SSH page needs a table of contents and it would be better if the Git page will link this URL fragment in that page.

[John Barrett]

Ticket moved from /p/forge/site-support/9216/

Can't be converted:

• _page: http://sourceforge.net/p/forge/documentation/Git/
• _related: all

[Anonymous]

-removed by author-

[Daniel M. Weeks]

Based on the recent history of RCEs in git (CVE-2015-7545, CVE-2016-2324, CVE-2016‑2315) I believe it is absolutely imperative for Sourceforge to implement a secure anonymous channel to protect users from malicious traffic injection during clone/fetch.

[Paul Wise]

I just discovered SF doesn't support anonymous encrypted git checkouts. Please add this, there are a variety of attacks where lack of encryption is a problem.

[Alec Leamas]

I would say this is a plain bug. The current documentation at [1] says

The read/write protocols detailed above can also be used for 
read-only access (just remove the "USERNAME@" portion).
...
The read-only access does not prompt for a password.

The last statement is wrong: an anonymous link like [2] doesn't work, it prompts for a password.

The importance of this bug is highlighted by the fact that standard Debian packaging tools warns about using anonymous git urls (the only viable option today) for retreiving code [3]

[1] https://sourceforge.net/p/forge/documentation/Git/
[2] https://git.code.sf.net/p/lirc/git
[3] https://mentors.debian.net/package/lirc

[Robert James Clay]

I also consider this a bug, rather than just a feature-request; both in the documention (in that attempting to clone a 'https://git-code.sf.net/p/PROJECTNAME/REPOSITORY/ URI results in a prompt for a 'Username') and in that the capability itself for a secure anonymous access to a git respository does not appear to be present.

[Rebecca Palmer]

This now appears to have been fixed (https read access now works without a password).