Replaced the gitmodule addresses to use HTTPS instead of SSH

[Irubataru]

I believe that the module paths should be updated from using SSH to use the HTTPS as this has been the github standard for quite a while (see my Issue #8).

I recently tried installing the library on JUQUEEN. I got a:

Permission denied (publickey)

error when I did

git submodule update --init --recursive

to pull down the submodules. Updating the gitmodules paths fixes this issue as github has set up the HTTPS protocol for pulling and cloning while SSH is intended for write-access, hence the permission denied.

[bjoo]

Hi, This is tricky for me to decide as some sites support both SSH and HTTPS access and some support SSH only, and some support HTTPS only. So we left them as SSH as that was most convenient for us.

You can always check out qdpxx nonrecursively and then edit the .git modules file to change submodules URLs to HTTPS prior to executing the

git submodules update --init --recursive.

Note that the QIO submodule, has submodules of its own which are independent of how qdpxx-s submodules are handled.

Best, B

On July 4, 2016 12:55:10 PM EDT, Jonas Rylund Glesaaen notifications@github.com wrote:

I believe that the module paths should be updated from using SSH to use the HTTPS as this has been the github standard for quite a while (see my Issue #8).

I recently tried installing the library on JUQUEEN. I got a:

Permission denied (publickey)

error when I did

git submodule update --init --recursive

to pull down the submodules. Updating the gitmodules paths fixes this issue as github has set up the HTTPS protocol for pulling and cloning while SSH is intended for write-access, hence the permission denied. You can view, comment on, or merge this pull request online at:

https://github.com/usqcd-software/qdpxx/pull/12

-- Commit Summary --

• Replaced the gitmodule addresses to use HTTPS instead of SSH

-- File Changes --

M .gitmodules (8)

-- Patch Links --

https://github.com/usqcd-software/qdpxx/pull/12.patch https://github.com/usqcd-software/qdpxx/pull/12.diff

---

You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/usqcd-software/qdpxx/pull/12

Bálint Joó, Scientific Computing Group, Jefferson Lab Email: bjoo@jlab.org Tel: +1 757 269 5339 Sent from a mobile device

[Irubataru]

Hello,

Maybe one should add a section about this on the README page in that case. I actually am not a user of qdpxx myself, I have mostly been involved through helping less experienced colleagues when they compile, and it is they who run into this problem and have no idea what is going on.

On the other hand I guess you could argue that in this case they should simply download the release tarballs and not look to the git repo. Regardless, if they ever end up here for one reason or another, it would be good to give a pointer.

I have always been of the opinion that one should pull through https whenever possible, which is also what github recommends. I have installed it on multiple servers by now and I have yet to find one that has problems with https, however ssh seems to pose problems. Of course, this is only my limited experience.

Cheers, Jonas

[martin-ueding]

There is a really simple workaround for this SSH issue:

1. Generate an SSH key pair on the machine that you want to compile on (ssh-keygen ...)
2. Create some dummy repository on your GitHub account.
3. Go to the “Settings” of that repository and then to the “Deploy Keys”.
4. Add the public SSH key from the machine there. You do not need to give push or write permissions.

Now the machine has a key registered with GitHub. You can now pull all the public git repositories over SSH just fine.

This is something that each developer has to do for each machine to build on. But it does not require any changes to any of the repositories.

[Irubataru]

Sure, I know that you can do that, but most people who clone qdpxx to compile on their system does not have a github account. That is the difference between being a user and a developer. Developers use the SSH address because it makes it easier to cache credentials through SSH key pairs, and sometimes it is necessary due to firewall restrictions on your clusters, and I understand that that is convenient. However, you would think that there are more users than developers out there, so I would naturally assume that the situation of having problems with the SSH far outnumbers the problems encountered with HTTPS.

Also, how often do you push to your submodules? If you develop the modules separately from this project you would never need to authenticate in the first place.

[bjoo]

Hi All, From my point of view, the real issue is that of the submodules. We would need to make sure to ensure that they are all available via HTTPS as well, otherwise you can get stuck. Until recently we primarily used SSH and I think this worked for all the submodules. Let me check into this, but it is not a high priority, since anyone can create a github account and get an SSH key uploaded.

Best, B

On Apr 4, 2017, at 3:08 PM, Jonas Rylund Glesaaen notifications@github.com wrote:

Sure, I know that you can do that, but most people who clone qdpxx to compile on their system does not have a github account. That is the difference between being a user and a developer. Developers use the SSH address because it makes it easier to cache credentials through SSH key pairs, and sometimes it is necessary due to firewall restrictions on your clusters, and I understand that that is convenient. However, you would think that there are more users than developers out there, so I would naturally assume that the situation of having problems with the SSH far outnumbers the problems encountered with HTTPS.

Also, how often do you push to your submodules? If you develop the modules separately from this project you would never need to authenticate in the first place.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

---

Dr Balint Joo High Performance Computational Scientist Jefferson Lab 12000 Jefferson Ave, Suite 3, MS 12B2, Room F217, Newport News, VA 23606, USA Tel: +1-757-269-5339, Fax: +1-757-269-5427 email: bjoo@jlab.org

[Irubataru]

Hi,

I totally agree that it is not a high priority issue, it is mostly that I have had to help multiple coworkers with this issue over the years, and I just wanted to point out that I personally believe it would be more user friendly with https. The permission denied error message you get when you run

git submode update --init --recursive

is a bit cryptic if you are new to git and just want to download and compile the library.

Cheers, Jonas

[bglaessle]

Hi,

just to offer another alternative, git supports relative submodule urls: e.g. for libintrin

    url = ../libintrin.git

works (fine for us). Depending on how you checked out qdp++ ssh or https will be used.

Regards, Ben

[martin-ueding]

This issue has again hit somebody. The git clone --recursive has failed due to the the SSH access. Can we please point those repositories to protocol relative URLs? Then we can have SSH or HTTPS and everyone should be happy.