Community
Participate
Working Groups
The current process for storing a committer's SSH keys on git.eclipse.org is a little arcane and labour intensive as it depends on providing shell access - see https://bugs.eclipse.org/bugs/show_bug.cgi?id=312034#c3. Other git hosting solutions such as gitorious provide a web UI for uploading SSH keys. Something similar should be provided in Eclipse, especially as increasing numbers of projects are likely to turn to git in the future. Perhaps this would also apply to other eclipse.org servers which support ssh access.
Great idea, and it's simple to implement. Thanks for the suggestion.
Hi Denis, Any chance of this 'simple' implementation being reified in the near future? We have a lot of new committers on the virgo/gemini projects who had this problem, and it is likely to happen again.
As much as I'd love to, we seem to have our hands tied with all the Hudson issues that just keep cropping up.
It seems that you need to prioritise---certain admin tasks (like having to restart slaves and accepting ssh keys) could be automated, or delegated, giving you LOTS of free time to fix the real bugs. Incidentally, the REAL Denis Roy is supposed to be "on leave 'til Jan24" -- so who are you and WHAT HAVE YOU DONE WITH HIM?
Restarts are the least of my worries. Automating them requires custom setups which will break with future Hudson versions. I'd be no further ahead, really. I learned a long time ago that once you get into IT, you cannot LEAVE. Ever :)
Some notes to self: security is a concern for me here, since the Eclipse login session is allowed to persist across non-SSL sites such as www.eclipse.org. To enable this, we'd either need to require a re-login before uploading the key to be reasonably sure that we're not dealing with a session highjack, or confirm the uploaded key via email to the committer. Or both.
Worth pointing out that if Gerrit were available in Eclipse (bug 283749) then you'd fix all these problems, and more. Instead of needing SSH access to the server and a real shell, you could SSH into the Gerrit instance which provides a locked down shell. And since Gerrit allows users to remotely manage the keys themselves, you wouldn't have to be involved in this process or elevated access to the main git server in any way. Finally, Gerrit may solve some of the legal issues with DVCS by requiring that a terms of use agreement is accepted prior to uploading. Android does this in its gerrit instance (https://review.source.android.com/) and we could do the same to ensure that users have accepted the terms of use agreement. Then a git push into gerrit would be equivalent to a bugzilla attachment in terms of agreements. It's worth pointing out that Shawn suggests it's possible to use the Gerrit instance to configure authentication against the bugzilla username/password over LDAP, so we don't even need to worry about creating new users. And if the projects are maintained in LDAP groups, it should be possible to bulk-configure access to projects as well. I mention this here because time invested in Gerrit is likely to have a much better impact and subsumes this bug than time creating a specific UI to upload specific keys.
And, of course, our CDT committers are hitting this head on. What makes it worse is that egit isn't storing the passwords in secure store properly. Any thoughts on how to mitigate this, like allowing vi as one of the commands in the restricted shell?
(In reply to comment #7) > Worth pointing out that if Gerrit were available in Eclipse (bug 283749) then > you'd fix all these problems, and more. Instead of needing SSH access to the > server and a real shell, you could SSH into the Gerrit instance which provides > a locked down shell. And since Gerrit allows users to remotely manage the keys > themselves, you wouldn't have to be involved in this process or elevated access > to the main git server in any way. Frankly, the way Gerrit is implemented currently on egit.eclipse.org is a no-go for Eclipse.org infrastructure. The web ui is served over an un-encrypted connection. Passwords are send unencrypted over the wire. Even worse, they are also displayed in plain text on the web ui, which indicates that they aren't hashed properly in the database but stored as is so that any admin can read them. The SSH management facility is nice. But in terms of security it's a no-go currently.
(In reply to comment #9) > (In reply to comment #7) > > Worth pointing out that if Gerrit were available in Eclipse (bug 283749) then > > you'd fix all these problems, and more. Instead of needing SSH access to the > > server and a real shell, you could SSH into the Gerrit instance which provides > > a locked down shell. And since Gerrit allows users to remotely manage the keys > > themselves, you wouldn't have to be involved in this process or elevated access > > to the main git server in any way. > > Frankly, the way Gerrit is implemented currently on egit.eclipse.org is a no-go > for Eclipse.org infrastructure. The web ui is served over an un-encrypted > connection. Passwords are send unencrypted over the wire. Even worse, they are > also displayed in plain text on the web ui, which indicates that they aren't > hashed properly in the database but stored as is so that any admin can read > them. > > The SSH management facility is nice. But in terms of security it's a no-go > currently. So sort out a standard Gerrit instance that is backed by the ldap auth and run it over https, like bugs.eclipse.org. That's what Android does for their review instance. The reason it's not over https at the moment is because of restrictions in the VM and routing, not a fault of Gerrit. If the Eclipse webmasters owned the Gerrit instance and configured it to use decent auto backend as well as https then this would fix both of these problems. As noted in comment 7, Gerrit is setup in this way because of restrictions in place that indirectly come from webmasters constraints. Only they can fix that problem. The insecure password in database is a workaround because the secure password (using kdap for auth
... Wasn't permitted at the time by webmasters.) So please don't prevent a proper configuration and then use that as an excuse to claim that it does t support proper configuration.
(In reply to comment #11) > So please don't prevent a proper configuration and then use that as an excuse > to claim that it does t support proper configuration. I'm not sure I understand. SSL is configured in a web server and that seems to be running on egit.eclipse.org which isn't manages by webmasters. Storing passwords unencrypted in a database because of a missing LDAP connection also seems like an excuse to me. Frankly, I might have mixed up the login password with an HTTP push password. That seems to be another one. Anyway, if those issues can be addressed, than an SSH key management UI comes for free with Gerrit. Does that work on Gerrit only or can it be synced to Eclipse.org servers?
The SSH management for Gerrit only applies to Gerrit. Since the credentials for Gerrit don't tie up with the Eclipse infrastructure at the moment, I don't think it's practical/sensible to tie them together. In the interim, those wishing to upload SSH keys without having to go through the upgraded shell process (and in the absence of a UI) can do: mkdir eclipse/.ssh cat my.key.pub >> eclipse/.ssh/authorized_keys chmod -R go-wx eclipse/.ssh scp -r -p eclipse/ git.eclipse.org:
(In reply to comment #13) Thanks Alex. I noted your technique here http://wiki.eclipse.org/Git#Setting_up_ssh_keys
I don't think this is needed. AFAIK pushing the ssh public key via Eclipse UI is not blocked. One of my team members who does not have shell access just did this successfully. For details see: http://help.eclipse.org/indigo/index.jsp?topic=%2Forg.eclipse.platform.doc.user%2Freference%2Fref-ssh2-preferences.htm Webmaster, can you confirm this?
(In reply to comment #15) > For details see: > http://help.eclipse.org/indigo/index.jsp?topic=%2Forg.eclipse.platform.doc.user%2Freference%2Fref-ssh2-preferences.htm > > > Webmaster, can you confirm this? Do you mean the Export via SFTP button from that help page? PW
(In reply to comment #16) > (In reply to comment #15) > > For details see: > > http://help.eclipse.org/indigo/index.jsp?topic=%2Forg.eclipse.platform.doc.user%2Freference%2Fref-ssh2-preferences.htm > > > > > > Webmaster, can you confirm this? > > Do you mean the Export via SFTP button from that help page? > > PW Yes, that's what Deepak used.
> Webmaster, can you confirm this? Well I'll be darned -- I didn't know Eclipse could do this. It worked for me with and without the shell. I've included this procedure in our various docs: http://wiki.eclipse.org/IT_Infrastructure_Doc#SSH http://wiki.eclipse.org/Git#Setting_up_ssh_keys
