Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 334120

Summary:	[server] How to push Git changes over SSH without storing private key on the Orion server?
Product:	[ECD] Orion	Reporter:	Szymon Brandys <Szymon.Brandys>
Component:	Client	Assignee:	Malgorzata Janczarska <malgorzata.tomczyk>
Status:	RESOLVED FIXED	QA Contact:
Severity:	normal
Priority:	P3	CC:	caniszczyk, john.arthorne, mail, Szymon.Brandys
Version:	0.2
Target Milestone:	0.2
Hardware:	All
OS:	All
Whiteboard:
Bug Depends on:	334775, 335463, 335703, 336222, 336822
Bug Blocks:	334095, 339722, 342731, 343240

Description Szymon Brandys

2011-01-12 10:21:56 EST

SSH is probably the most common transport protocol for Git that allows writing (i.e. pushing local changes to a remote). Since SSH uses public-key approach the EW server needs to sing the push operation with the private key. Normally, the private key is kept in a safe location on disk and we cannot expect someone will upload it on the server, even if the key is protected with a passphrase.

We need to investigate what we can do to make the push operation simple and secure and the same time. Is there a way to leverage OAuth to do that?

Comment 1 Szymon Brandys

2011-01-12 10:23:27 EST

Tomasz Zarna wrote:

Another option, but still far from ideal, is to store the private keys on the Orion server, but protected each of them with a passphrase.

Comment 2 Tomasz Zarna

2011-01-26 07:19:34 EST

With the introduction of Secure Storage saving password or private key + passphrase on the server is no longer a no go. The code I'm currently working on allows GitFileStore to pull/push over ssh asking secure storage for credentials, but it's still missing the following:
* UI for providing credentials and saving them in user profile
* an idea of how to store the above in the secure storage
* making sure the data cannot be accessed by another user
* UI prompts when user hasn't provided required credentials
* UI prompt when accepting a host is required (auto-accept for now)

We will continue to work on those during 0.2 M6. I'll probably file separate bugs for some of the missing bits.

Comment 3 Tomasz Zarna

2011-01-28 11:52:34 EST

(In reply to comment #2)

> * an idea of how to store the above in the secure storage

Here is an excerpt from code in my workspace which shows an initial structure

 SSH_CONFIG
 |_<orionUser>
   |_KNOWN_HOSTS
   |_<uri1>
   | |_USERNAME
   | |_PASSWORD*
   | |_KEYS*
   |   |_<name1>*
   |   | |_PUBLIC_KEY
   |   | |_PRIVATE_KEY
   |   | |_PASSPHRASE*
   |   |_<name2>*
   |     |_...
   |_<uri2>*
     |_...

* optional nodes
<uri>s are encoded with java.net.URLEncoder

> * UI prompt when accepting a host is required (auto-accept for now)

auto-accept new hosts but auto-reject known hosts which signature has changed. This is all for now of course, until we get a proper UI for this.

Comment 4 Tomasz Zarna

2011-02-10 09:12:24 EST

(In reply to comment #3)

> auto-accept new hosts but auto-reject known hosts which signature has changed.
> This is all for now of course, until we get a proper UI for this.

This is now tracked in bug 336822.

Comment 5 Tomasz Zarna

2011-02-10 10:34:03 EST

(In reply to comment #2)
> * UI for providing credentials and saving them in user profile
Tracked by bug 336222.

> * an idea of how to store the above in the secure storage
Fixed in 336704.

> * making sure the data cannot be accessed by another user
Current implementation of IOrionUserProfileService will not return secrets (data required encryption) to the browser.

> * UI prompts when user hasn't provided required credentials
Tracked here bug 336830.

> * UI prompt when accepting a host is required (auto-accept for now)
Again, it's bug 336822.

Comment 6 Szymon Brandys

2011-04-27 09:52:01 EDT

Marking FIXED. New bugs will be opened for firther work and fixes.