Community
Participate
Working Groups
Build ID: I20070323-1616 Steps To Reproduce: First, generate private/public key pair and install public key to the CVS server (if you haven't done yet). $ ssh-keygen -t dsa Generating public/private dsa key pair. Enter file in which to save the key (/home/username/.ssh/id_dsa): [Type RET] Enter passphrase (empty for no passphrase): [Type some passphrase] Enter same passphrase again: [Type the same passphrase] Your identification has been saved in /home/username/.ssh/id_dsa. Your public key has been saved in /home/username/.ssh/id_dsa.pub. The key fingerprint is: 1f:67:c7:af:24:c2:8b:6a:03:66:b6:53:95:1c:53:eb username@client $ ssh -l cvsuser cvsserver.example.org "cat >>.ssh/authorized_keys" < .ssh/id_dsa.pub Then, run ssh-agent and store the identity in the agent. $ ssh-agent bash $ ssh-add Enter passphrase for /home/username/.ssh/id_dsa: [Here type your passphrase] Identity added: /home/username/.ssh/id_dsa (/home/username/.ssh/id_dsa) Command-line tool can use the identity in the agent to provide repository access without prompting for password. $ cd ~/workspace/someproject $ cvs update [stored identity is used, no ask for passphrase] cvs update: Updating . cvs update: Updating .settings However, eclipse cannot do the same. $ eclipse In resource perspective, right-click a project -> Team -> Update Then "Password Required" dialog box appears and asks for passphrase unneccesarily. More information: When eclipse connects to an sshd server (for example updating cvs extssh repository) with publickey authentication, "Password Required" dialog box is appeared and ask for passphrase of the private key. However, if ssh-agent (SSH authentication agent) is running and the identity is correctly stored, the identity stored in ssh-agent should be used rather than directly uses private key stored in the file. Command-line CVS (that is, internally used /usr/bin/ssh) respects ssh-agent so it is very easy to access repository when ssh-agent is running. Eclipse can do the same. In most X windows environment in modern linux distros, ssh-agent is automatically running in the login step. Thus using the ssh agent is as easy as just run ssh-askpass (a software package for typing passphrase on X) once you've installed the public key.
If we can, it must be nice... The problem is that ssh-agent will use the Unix domain socket to communicate with ssh clients. Unfortunately, there is no method to get accesses to it in pure Java.
Is it the case that the ssh-agent is tightly coupled to the ssh client distributed with Linux? Or, to put it another way, if a different ssh client is used, does it still interact with the ssh-agent? It's tricky because, unless the ssh-agent has a specified API that allows third party interaction, there's not much that can be done. Having said that, it would probably be possible for someone to figure out how to do it from Java. Might make an interesting project for someone to work on if they wanted to contribute a patch ;-)
Putty for windows comes with its own ssh agent called 'pageant'. You can query the agent by sending some window commands to its window and reading from shared memory. The logic can be found in winpgntc.c of the putty source distribution. Although some of the work can be done using standard SWT calls, there would still need to be some custom native code.
(In reply to comment #3) > Putty for windows comes with its own ssh agent called 'pageant'. You can query > the agent by sending some window commands to its window and reading from shared > memory. The logic can be found in winpgntc.c of the putty source distribution. I had checked that source code, and it seems it has been using Win32's messaging system to communicate whith each other. As you know that SWT has allowed us to use some of Win32 API in java, but some Win32 API for such messaings have not been allowed yet, from my recognition. > Although some of the work can be done using standard SWT calls, there would > still need to be some custom native code. I'm not so interested in it, but does Eclipse Platform allow us to include such native code? IMHO, the best solution will be the improvements of Win32 API supports in SWT.
Bug 259671 has a similar request for TM / RSE. While using the agent would certainly be nice, it seems to me that there are two simple workarounds for CVS: (1) With Equinox Secure Storage, can the Team Provider ensure that the passphrase needs to be entered only once per session (or not at all)? Then the agent is not needed. (2) When using the CVS "ext:" method instead of "extssh:" it should be possible to use a command-line CVS client which interacts with the command-line SSH program which can make use of the agent.
I checked, and the passphrase is apparently always cached inside JSch - the key remains open once it was opened with the passphrase. So, after entering the passphrase just once (e.g. for CVS), it'll be used consistently across the Eclipse session including TM Terminal and RSE. One side-effect of this is that when changing any Preferences related to key management (such as the names of keys to use, or the passphrase encrypting them), this has no effect on the open session -- it'll continue re-using the key that it has opened already until Eclipse is quit and restarted. That being said, I think that the need for using an ssh-agent is minimal, and could be made totally unneeded if Equinox Secure Storage can be used to cache the passphrase.
There are two other uses for ssh-agent that weren't discussed in this ticket; together I think it makes agent support more compelling. The first is that the agent may not be on the same machine as the running ssh session. This means that ones keys never need to be put on the host running eclipse, but instead can be kept "close" to the user, and don't need to be stored on the eclipse hosts' disk. This can improve security (by, for example, keeping ones keys on a USB fob, and loading them into the agent once at login time). The other use of an agent is that they support hardware tokens to hold the keys (see http://www.opensc-project.org/opensc/wiki/SecureShell). openssh supports this directly, but if agents were supported in eclipse then jsch could gain access to token based keys without having to support it directly. So: the workarounds described show how to gain access to a log key, but agent support is more about how to avoid having ones keys on the local machine but still enabling secure access.
One option to support this is tunneling all SSH communication through an external SSH program rather than the builtin SSH library. The Eclipse SVN integrations do this - in fact for SVN, any case of tunneling is completely transparent and any kind of tunnel can be supported via any kind of external program. Here is how I have this set up on Windows with the SVN Native connector: - File C:\Documents and Settings\mober\Application Data\Subversion\config [tunnels] ssh = $SVN_SSH "C:/Program Files/TortoiseSVN/bin/TortoisePlink.exe" -l moberhuber -i "D:/home/.ssh/id_dsa.ppk" And immediately, SVN knows the "svn+ssh" protocol where the tunnel name "ssh" could be replaced by any other kind of tunnel name for other external programs / tunneling protocols. For remote terminals, the TM Project now supports this in Helios through its new "Local Terminal" connection, which you can configure to run a program that actually connects to a remote host. For details about this, see https://bugs.eclipse.org/bugs/show_bug.cgi?id=314827
(In reply to comment #8) > One option to support this is tunneling all SSH communication through an > external SSH program rather than the builtin SSH library. The Eclipse SVN > integrations do this - in fact for SVN, any case of tunneling is completely > transparent and any kind of tunnel can be supported via any kind of external > program. Here is how I have this set up on Windows with the SVN Native > connector: I think it would be better to have a java ssh library which supports it. SSHD might be an option. http://mina.apache.org/sshd/index.htm
(In reply to comment #9) > (In reply to comment #8) > > One option to support this is tunneling all SSH communication through an > > external SSH program rather than the builtin SSH library. The Eclipse SVN > > integrations do this - in fact for SVN, any case of tunneling is completely > > transparent and any kind of tunnel can be supported via any kind of external > > program. Here is how I have this set up on Windows with the SVN Native > > connector: > > I think it would be better to have a java ssh library which supports it. > SSHD might be an option. > > http://mina.apache.org/sshd/index.htm Interesting. It seems it has been using org.apache.tomcat.jni.* . If we are allowed to use that JNI in Eclipse, it will be easy to support the requested functionality for the Unices platform. The missing piece is just a lack of the access method to Unix domain socket. By the way, how about the Windows platform? How can we get accesses to Win32 API in pure java? One year ago, I had checked Win32 API support in SWT lib, but it was now enough, at that time.
(In reply to comment #10) > (In reply to comment #9) > > (In reply to comment #8) > > > One option to support this is tunneling all SSH communication through an > > > external SSH program rather than the builtin SSH library. The Eclipse SVN > > > integrations do this - in fact for SVN, any case of tunneling is completely > > > transparent and any kind of tunnel can be supported via any kind of external > > > program. Here is how I have this set up on Windows with the SVN Native > > > connector: > > > > I think it would be better to have a java ssh library which supports it. > > SSHD might be an option. > > > > http://mina.apache.org/sshd/index.htm > > Interesting. It seems it has been using org.apache.tomcat.jni.* . > If we are allowed to use that JNI in Eclipse, it will be easy to support > the requested functionality for the Unices platform. The missing piece is > just a lack of the access method to Unix domain socket. It is using Apache APR for domain sockets. > By the way, how about the Windows platform? > How can we get accesses to Win32 API in pure java? One year ago, I had checked > Win32 API support in SWT lib, but it was now enough, at that time. Not sure.
(In reply to comment #10) > (In reply to comment #9) > > (In reply to comment #8) > > > One option to support this is tunneling all SSH communication through an > > > external SSH program rather than the builtin SSH library. The Eclipse SVN > > > integrations do this - in fact for SVN, any case of tunneling is completely > > > transparent and any kind of tunnel can be supported via any kind of external > > > program. Here is how I have this set up on Windows with the SVN Native > > > connector: > > > > I think it would be better to have a java ssh library which supports it. > > SSHD might be an option. > > > > http://mina.apache.org/sshd/index.htm > > Interesting. It seems it has been using org.apache.tomcat.jni.* . > If we are allowed to use that JNI in Eclipse, it will be easy to support > the requested functionality for the Unices platform. The missing piece is > just a lack of the access method to Unix domain socket. Any update on whether this approach would be possible?
It seems TM TCF has a functionality to handle Unit domain sockets, https://bugs.eclipse.org/bugs/show_bug.cgi?id=331791 By using it, eclipse may be able to use ssh-agent on unices.
I've been using cygwin-ssh + Eclipse combination to be able to write code in Windows and run build jobs on a remote Linux server. It seems that Remote System Explorer provides everything necessary to remove cygwin dependency but unfortunately lacks support for ssh agents. After some investigation, here is what I've found. *** SSH agent protocol *** (In reply to comment #2) > Is it the case that the ssh-agent is tightly coupled to the ssh client > distributed with Linux? Or, to put it another way, if a different ssh client is > used, does it still interact with the ssh-agent? It's tricky because, unless > the ssh-agent has a specified API that allows third party interaction, there's > not much that can be done. Having said that, it would probably be possible for > someone to figure out how to do it from Java. Might make an interesting project > for someone to work on if they wanted to contribute a patch ;-) There are several widespread ssh agent implementations: ssh-agent from OpenSSH, Pageant from Putty, Gnome Keyring SSH Agent, but all of them seem to implement the same spec from OpenSSH, which can be found here: http://api.libssh.org/rfc/PROTOCOL.agent Here is an example of a Python program implementing one part of this spec: http://ptspts.blogspot.com/2010/06/how-to-use-ssh-agent-programmatically.html Implementing this protocol in Java would require some time but is nothing too complex. *** Communication with SSH agents *** As many people have already pointed out the problem is various platform dependent interfaces used by these implementations. ssh-agent and gnome-ssh-agent rely on Unix Sockets, and pageant relies on Win32 messages. Quick search gives a lot of options for using either of these technologies from Java, but I guess the real question is whether platform-specific parts should end up in SWT or rather in Platform components. Anyway, this part of the task looks approachable too. By the way, the functionality provided by Target Communication Framework is implemented in C and therefore is platform-dependent too. I don't think I would have time to work on this any time soon but in case I do, or somebody else becomes interested, I hope this summary would be a good starting point.
At last weekend, I did a quick hack to communicate with Openssh's ssh-agent and I have confirmed that jsch can successfully login with it. # In that hack, I used junixsocket[1], but it is not essential. As a next hack, I'll try to write code to communicate with Pageant if possible. In the future, users of Eclipse, NetBeans, IntelliJ, Ant and Ivy etc.(which is using jsch), may be able to enjoy such a functionality. [1] http://code.google.com/p/junixsocket/
At last weekend, I had tried to get accesses to Pageant in Java(with JNA), and have been succeeded it, at last. As a proof of concepts, if you are interested in it and using Pageant on Windows, download http://www.jcraft.com/jsch/jsch-0.1.46-pageant.jar and replace eclipse/plugins/com.jcraft.jsch_0.1.41.v201101211617.jar with it after saving the original. In every ssh accesses, pageant will be referred to. I guess that jar will applicable to Ant, Ivy, NetBeans, etc,. I'll wrap up that efforts including accesses to OpenSSH's ssh-agent, and try to provide it as a Christmas present to the world under the revised BSD license.
I have pushed jsch-agent-proxy to github[1], which will work as a proxy program for OpenSSH's ssh-agent and Pageant from Putty. As for integration to JSch, please refer to JSchWithAgentProxy.java[2]. The following ssh2 terminal emulator applet http://wiredx.net/jcterm/jcterm-jsch-agent-proxy.php will demonstrate this functionality. Enjoy it! [1] https://github.com/ymnk/jsch-agent-proxy [2] https://github.com/ymnk/jsch-agent-proxy/blob/master/examples/JSchWithAgentProxy.java
Interesting ... thanks ! - I have a couple questions : - The example seems to use JSch-0.1.46-rc1 .. does agent-proxy require JSch-0.1.46 or could it work with JSch-0.1.45 as well ? - The example seems to indicate that agent-proxy can live in the same JVM as JSch, is this correct ? - How would you feel about bundling agent-proxy with JSch in a single Jar ... would that make sense from your point of view, or should they be separate ?
(In reply to comment #18) > Interesting ... thanks ! - I have a couple questions : > > - The example seems to use JSch-0.1.46-rc1 .. does agent-proxy require > JSch-0.1.46 or could it work with JSch-0.1.45 as well ? Unfortunately, it requires JSch-0.1.46. > - The example seems to indicate that agent-proxy can live in the same JVM > as JSch, is this correct ? Yes, it is. > - How would you feel about bundling agent-proxy with JSch in a single Jar ... > would that make sense from your point of view, or should they be separate ? The current implementation depends on JNA, which is LGPL software, # please refer to its README[1] so it may not be acceptable for Eclipse.org project. In the future, it may be possible to implement it by using TM TCF and org.eclipse.swt.internal.win32, but it will not be for a while. Until that, it should be provided as a separate plug-in from third party, IMHO. [1] https://github.com/ymnk/jsch-agent-proxy/blob/master/README#L49
(In reply to comment #19) > Unfortunately, it requires JSch-0.1.46. When are you planning to release JSch-0.1.46 ? I think it's important for Eclipse since the deadline for including new IP into this year's Juno release train is approaching fast. Right now, we're planning for JSch-0.1.45 but no CQ has been opened yet so we could probably go to JSch-0.1.46 right away - see also bug 360663 . > The current implementation depends on JNA, which is LGPL software, > # please refer to its README[1] > so it may not be acceptable for Eclipse.org project. If I got the README right, JNA is only needed on Windows so even without JNA there would be some value on Linux ... right ? Seems to me like the JNA dependency would be a good candidate for making optional. Optional dependencies to LGPL need to be announced by a CQ but aren't completely impossible. Especially if JSch itself as a 3rd party lib distributed via Orbit had that optional dependency. > In the future, it may be possible to implement it by using TM TCF and > org.eclipse.swt.internal.win32, but it will not be for a while. As of today, I don't see much value in "Eclipse specific" code just for the agent connection. I guess that would only make sense to somebody who absolutely can't have LGPL in some offering but still requires the agent connection. I just noticed today that an "Eclipsified" version of JNA-3.2.7 gets installed with SVNKit when you install Subclipse-1.6.x ... so it does exist in the wild as an OSGi bundle already and it's being used with Eclipse (even though not distributed by Eclipse).
(In reply to comment #20) > (In reply to comment #19) > > > Unfortunately, it requires JSch-0.1.46. > > When are you planning to release JSch-0.1.46 ? I think it's important for > Eclipse since the deadline for including new IP into this year's Juno release > train is approaching fast. Right now, we're planning for JSch-0.1.45 but no CQ > has been opened yet so we could probably go to JSch-0.1.46 right away - see > also bug 360663 . We have been planning to release it soon. > > The current implementation depends on JNA, which is LGPL software, > > # please refer to its README[1] > > so it may not be acceptable for Eclipse.org project. > > If I got the README right, JNA is only needed on Windows so even without JNA > there would be some value on Linux ... right ? Yes, if junixsocket[1] is available, it can connect to OpenSSH's ssh-agent. You know that junixsocket has been licensed under Apache License 2.0. [1] http://code.google.com/p/junixsocket/
Created attachment 210707 [details] a patch for o.e.jsch.{core,ui} to use jsch-agent-proxy This is a patch for org.eclipse.jsch.core and org.eclipse.jsch.ui plug-ins to use jsch-agent-proxy. It expects to use following plug-ins, * com.jcraft.jsch.agentproxy * com.jcraft.jsch.agentproxy.eclipse.pageant * com.jcraft.jsch.agentproxy.eclipse.sshagent
The attachment 210707 [details] depends on plug-ins included in http://www.jcraft.com/jsch-agent-proxy/jsch-agent-proxy-eclipse.zip This zip file includes following plug-ins, * com.jcraft.jsch.agentproxy plug-in This plug-in includes code of https://github.com/ymnk/jsch-agent-proxy , but does not include code which depends on JNA and junixsocket * com.jcraft.jsch.agentproxy.eclipse.pageant This plug-in includse some of code from https://github.com/ymnk/jsch-agent-proxy , which depends on JNA, * com.jcraft.jsch.agentproxy.elipse.sshagent This plug-in includes some of code from https://github.com/ymnk/jsch-agent-proxy , which depends on JNA
Created attachment 210708 [details] a screen image of preference page for SSH Agent The attached png image shows a screen image of preference page for SSH-Agent on Eclipse with attachment 210707 [details] . I have confirmed that I can get accesses to http://github.com/ and clone some projects by egit with putty's pageant.
I have updated the following zip file, http://www.jcraft.com/jsch-agent-proxy/jsch-agent-proxy-eclipse.zip This file includes following 4 plug-ins, * com.jcraft.jsch.agentproxy plug-in This plug-in includes code of https://github.com/ymnk/jsch-agent-proxy , but does not include code which depends on JNA and junixsocket * com.jcraft.jsch.agentproxy.eclipse.pageant This plug-in includse some of code from https://github.com/ymnk/jsch-agent-proxy , which depends on JNA, * com.jcraft.jsch.agentproxy.eclipse.sshagent This plug-in includes some of code from https://github.com/ymnk/jsch-agent-proxy , which depends on junixsocket, * com.jcraft.jsch.agentproxy.eclipse.sshagent.jna This plug-in includes some of code from https://github.com/ymnk/jsch-agent-proxy , which depends on JNA As you know that junixsocket is licensed under Apache license 2.0, so this functionality will be available without LGPL on GNU/Linux and Mac OSX. If somebodies think this bugzilla entry should be addressed before Juno release, please review it. I have confirmed that it will work on GNU/Linux and Windows, but not on Mac OSX. PS. it requires jsch-0.1.46 plug-in , and it is available at http://eclipse.jcraft.com/plugins/com.jcraft.jsch_0.1.46.jar
How do I installe these, and which of them do I need? I got eclipse [indigo SR2] to recognize com.jcraft.jsch.agentproxy and jsch-0.1.46, but not com.jcraft.jsch.agentproxy.eclipse.sshagent or com.jcraft.jsch.agentproxy.eclipse.sshagent.jna No additional tab appears in my SSH2 settings in eclipse :(
The source code has been updated. If you are interested in it, try http://www.jcraft.com/jsch-agent-proxy/jsch-agent-proxy-eclipse-0.0.3.zip Import the content of it to the workspace , and Run > "Eclipse Application" . The latest source code depends on jsch-0.1.49, and you can install it at eclipse update site, http://eclipse.jcraft.com/site.xml .
I have deployed source code to the git repository, * https://github.com/ymnk/eclipse.platform.team/tree/bug179924 This is a fork of git://git.eclipse.org/gitroot/platform/eclipse.platform.team.git , and includes changes[1] for org.eclipse.jsch.* plug-ins on bug179924 branch. * https://github.com/ymnk/eclipse-jsch-agent-proxy This project includes plug-ins to use ssh-agent and Pageant on Eclipse. Please try README[2] if you think this bug-entry should be addressed, and any feedback and inputs would be welcome. [1] https://github.com/ymnk/eclipse.platform.team/compare/master...bug179924 [2] https://github.com/ymnk/eclipse-jsch-agent-proxy/blob/master/README.md
(In reply to Atsuhiko Yamanaka from comment #28) > Please try README[2] if you think this bug-entry should be addressed, > and any feedback and inputs would be welcome. Atsuhiko, thanks for this initial implementation. I'm a committer on EGit/JGit and I'd like to find a way to make that available for EGit users. From reading through the docs, it wasn't clear if this also requires a modification to the jsch library. If yes, do you know if those has been merged upstream?
(In reply to Gunnar Wagenknecht from comment #29) > From reading through the docs, it wasn't clear if this also requires a > modification to the jsch library. If yes, do you know if those has been > merged upstream? Yes, jsch is ready for using with jsch-agent-proxy. It will be easy to use that functionality with JGit. As for an example, please refer to https://github.com/ymnk/jsch-agent-proxy/blob/master/examples/src/main/java/com/jcraft/jsch/agentproxy/examples/JSchWithAgentProxy.java
FYI, I found that NetBeans has supported ssh-agent by using jsch-agent-proxy, and there is also an effort to add support ssh-agent to IntelliJ[2] by using it. As I posted a comment[3], I had developed jsch-agent-proxy for "this" bugzilla entry. While this entry has been suspended, jsch-agent-proxy has been adopted by others[4][5][6]. [1] https://netbeans.org/bugzilla/show_bug.cgi?id=218918#c8 [2] https://github.com/JetBrains/intellij-community/pull/140 [3] https://bugs.eclipse.org/bugs/show_bug.cgi?id=179924#c15 [4] https://issues.apache.org/jira/browse/IVY-1421 [5] https://issues.apache.org/jira/browse/VFS-421 [6] https://github.com/ajoberstar/gradle-git/issues/24
That's great news. FWIW, for EGit/JGit I'm currently using a workaroung by setting GIT_SSH. This works pretty well on Mavericks. I'll try to take a look at the patch and convert that into a Gerrit review for the Eclipse Platform team.
What is the status on this? Is it already in Gerrit?
Let's move this to EGit. I see a stronger need for SSH-Agent support there than in Platform CVS. Also, I don't think anyone is maintaining Platform CVS anymore.
could we distribute com.jcraft.jsch.agentproxy.eclipse.pageant including JNA which is LGPL licensed ?
(In reply to Matthias Sohn from comment #35) > could we distribute com.jcraft.jsch.agentproxy.eclipse.pageant including JNA > which is LGPL licensed ? FYI, JNA has changed its license from LGPL to Apache Software License since its version 4.0, and we have confirmed that jsch-agent-proxy will work with it.
(In reply to Atsuhiko Yamanaka from comment #36) > (In reply to Matthias Sohn from comment #35) > > could we distribute com.jcraft.jsch.agentproxy.eclipse.pageant including JNA > > which is LGPL licensed ? > > FYI, JNA has changed its license from LGPL to Apache Software License since > its version 4.0, and we have confirmed that jsch-agent-proxy will work with > it. great Would be great to integrate this into JGit/EGit Is jsch-agent-proxy available for jsch 0.1.50 and 0.1.51 ? We are on the way to update to the latter in Mars. How can I try the eclipse plugins you developed / forked to make this work in Eclipse ? Which parts do you want to contribute ?
(In reply to Matthias Sohn from comment #37) > Is jsch-agent-proxy available for jsch 0.1.50 and 0.1.51 ? We are on the way > to update to the latter in Mars. It will work with jsch 0.1.50 and jsch 0.1.51. > > How can I try the eclipse plugins you developed / forked to make this work > in Eclipse ? I'm the author of jsch, jsch-agent-proxy and org.eclipse.jsch.{ui, core} plugins , and working as a committer at eclipse.org. > Which parts do you want to contribute ? I'm waiting for responses from others about my contributions for long time, but I have received nothing. I'll update pluing-ins to use JNA 4.1.
(In reply to Atsuhiko Yamanaka from comment #38) > (In reply to Matthias Sohn from comment #37) > > Is jsch-agent-proxy available for jsch 0.1.50 and 0.1.51 ? We are on the way > > to update to the latter in Mars. > It will work with jsch 0.1.50 and jsch 0.1.51. > > > > How can I try the eclipse plugins you developed / forked to make this work > > in Eclipse ? > > I'm the author of jsch, jsch-agent-proxy and org.eclipse.jsch.{ui, core} > plugins > , and working as a committer at eclipse.org. you misunderstood my question, I am wondering how I can test what you developed. I guess I need to install the bundles (I am on Mac): - com.jcraft.jsch.agentproxy - com.jcraft.jsch.agentproxy.eclipse.sshagent anything else needed to try this with EGit ? > > Which parts do you want to contribute ? > I'm waiting for responses from others about my contributions for long time, > but I have received nothing. I think the reason for this silence is that there is nobody left maintaining the Eclipse CVS client. Gunnar moved this bug from the orphaned CVS to EGit and as you can see we are keen to get support for ssh-agents in EGit :-) > I'll update pluing-ins to use JNA 4.1. thanks
(In reply to Matthias Sohn from comment #39) > you misunderstood my question, I am wondering how I can test what you > developed. > I guess I need to install the bundles (I am on Mac): > - com.jcraft.jsch.agentproxy > - com.jcraft.jsch.agentproxy.eclipse.sshagent > anything else needed to try this with EGit ? Those plugins expects changes for org.eclipse.jsch.{core, ui}. Check out the followings to the workspace, * bug179924 branch of https://github.com/ymnk/eclipse.platform.team.git , and * master branch of https://github.com/ymnk/eclipse-jsch-agent-proxy.git Run > "Eclipse Application" and visit the preference page, Window > Preferences > General > Network Connections > SSH2 > SSH Agent I have confirmed CVS plug-in on Luna can use ssh-agent and pageant with those plugins. If EGit refers to org.eclipse.jsch.core plugin, it will automagically work for ssh-agent without any changes for EGit.
(In reply to Atsuhiko Yamanaka from comment #40) > If EGit refers to org.eclipse.jsch.core plugin, it will automagically work > for ssh-agent without any changes for EGit. I have confirmed that EGit included in Eclipse Luna on Windows8.1(64bit) can use Pageant with those plug-ins. I hope it will also work with ssh-agent on MacOSX.
(In reply to Atsuhiko Yamanaka from comment #38) > I'm the author of jsch, jsch-agent-proxy and org.eclipse.jsch.{ui, core} > plugins > , and working as a committer at eclipse.org. Are you a committer on the org.eclipse.jsch.* projects?
(In reply to Gunnar Wagenknecht from comment #42) > (In reply to Atsuhiko Yamanaka from comment #38) > > I'm the author of jsch, jsch-agent-proxy and org.eclipse.jsch.{ui, core} > > plugins > > , and working as a committer at eclipse.org. > > Are you a committer on the org.eclipse.jsch.* projects? Yes, I am.
(In reply to Atsuhiko Yamanaka from comment #43) > > Are you a committer on the org.eclipse.jsch.* projects? > > Yes, I am. That is great! So you can actually commit them to those projects. What dependencies do you need for compiling? I can help you with filing the CQs and once they are approved your code can go in.
(In reply to Gunnar Wagenknecht from comment #44) > (In reply to Atsuhiko Yamanaka from comment #43) > > > Are you a committer on the org.eclipse.jsch.* projects? > > > > Yes, I am. > > That is great! So you can actually commit them to those projects. What > dependencies do you need for compiling? I can help you with filing the CQs > and once they are approved your code can go in. The changes for o.e.jsch.{core, ui} do not introduce the new dependencies, but it has added one extension point. The com.jcraft.jsch.agentproxy.eclipse.* plug-ins depend on * jsch-agent-proxy 0.0.8[1][2], * JNA 4.1.0[3] [1] http://www.jcraft.com/jsch-agent-proxy/ [2] https://github.com/ymnk/jsch-agent-proxy [3] https://github.com/twall/jna
(In reply to Atsuhiko Yamanaka from comment #45) > The changes for o.e.jsch.{core, ui} do not introduce the new dependencies, > but it has added one extension point. But the changes are backwards compatible to the current implementation, i.e. it will still work without an extension? In that case I suggest you move ahead and commit those to Git. This way they become available in a new Platform build which can then be consumed by EGit. > The com.jcraft.jsch.agentproxy.eclipse.* plug-ins depend on > * jsch-agent-proxy 0.0.8[1][2], > * JNA 4.1.0[3] We have two options: (a) redistribute them with Eclipse and/or (b) publish a p2 update site with those three bundles. Matthias, is your idea to redistribute them with EGit?
(In reply to Gunnar Wagenknecht from comment #46) > (In reply to Atsuhiko Yamanaka from comment #45) > > The changes for o.e.jsch.{core, ui} do not introduce the new dependencies, > > but it has added one extension point. > > But the changes are backwards compatible to the current implementation, i.e. > it will still work without an extension? In that case I suggest you move > ahead and commit those to Git. This way they become available in a new > Platform build which can then be consumed by EGit. > > > The com.jcraft.jsch.agentproxy.eclipse.* plug-ins depend on > > * jsch-agent-proxy 0.0.8[1][2], > > * JNA 4.1.0[3] > > We have two options: (a) redistribute them with Eclipse and/or (b) publish a > p2 update site with those three bundles. > > Matthias, is your idea to redistribute them with EGit? I think ideally they should be redistributed with o.e.jsch.{core, ui} but if that's not feasable we could redistribute them with EGit, actually if we can make this work with JGit also we should redistribute them with JGit since that's also used in other contexts outside Eclipse.
(In reply to Matthias Sohn from comment #47) > I think ideally they should be redistributed with o.e.jsch.{core, ui} That makes a lot of sense. I assume that o.e.jsch.{core, ui} is currently distributed by the Eclipse Platform?
(In reply to Gunnar Wagenknecht from comment #46) > (In reply to Atsuhiko Yamanaka from comment #45) > > The changes for o.e.jsch.{core, ui} do not introduce the new dependencies, > > but it has added one extension point. > > But the changes are backwards compatible to the current implementation, i.e. > it will still work without an extension? Yes, they are backwards compatible to the current Eclipse, and will not break anything. I had waited for comments, permissions to add it from members at platform.team team. > In that case I suggest you move > ahead and commit those to Git. This way they become available in a new > Platform build which can then be consumed by EGit. I had committed code for those plugins when they were hosted at CVS repository, but I have not yet since it has been moved to git.eclipse.org, because it is not clear for me about the development work flow at eclipse.platform.team.git repository. It seems nobody has created topic branches on it. This is the reason why I have been using github. If it is allowed, I'll commit those to eclipse.platform.team.git repo.
(In reply to Matthias Sohn from comment #47) > I think ideally they should be redistributed with o.e.jsch.{core, ui} but if > that's not feasable we could redistribute them with EGit, actually if we can > make this work with JGit also we should redistribute them with JGit since > that's also used in other contexts outside Eclipse. As for JGit in other contexts outside Eclipse, jsch-agent-proxy has been available at central maven repo[1], so JGit does not have to take care for the redistribution of it. [1] http://mvnrepository.com/artifact/com.jcraft/jsch.agentproxy
(In reply to Atsuhiko Yamanaka from comment #49) > (In reply to Gunnar Wagenknecht from comment #46) > > (In reply to Atsuhiko Yamanaka from comment #45) > > > The changes for o.e.jsch.{core, ui} do not introduce the new dependencies, > > > but it has added one extension point. > > > > But the changes are backwards compatible to the current implementation, i.e. > > it will still work without an extension? > > Yes, they are backwards compatible to the current Eclipse, > and will not break anything. I had waited for comments, permissions to add > it > from members at platform.team team. > > > In that case I suggest you move > > ahead and commit those to Git. This way they become available in a new > > Platform build which can then be consumed by EGit. > > I had committed code for those plugins when they were hosted at CVS > repository, > but I have not yet since it has been moved to git.eclipse.org, > because it is not clear for me about the development work flow at > eclipse.platform.team.git repository. It seems nobody has created > topic branches on it. This is the reason why I have been using github. > If it is allowed, I'll commit those to eclipse.platform.team.git repo. eclipse.platform.team seems to use Gerrit for code review https://git.eclipse.org/r/#/q/status:open+project:platform/eclipse.platform.team,n,z so I'd recommend you push your changes there to get them reviewed by team committers. https://wiki.eclipse.org/Platform_UI/How_to_Contribute#Creating_a_Gerrit_review_or_a_patch http://www.vogella.com/tutorials/EclipsePlatformDevelopment/article.html#eclipsegerritcontribution https://wiki.eclipse.org/Gerrit let me know if you need help with pushing to Gerrit
(In reply to Atsuhiko Yamanaka from comment #49) > Yes, they are backwards compatible to the current Eclipse, > and will not break anything. I had waited for comments, permissions to add > it > from members at platform.team team. As Matthias said, you should push a review to Gerrit for people to review. Please keep in mind that the Platform team is very constraint on available capacity. But they are fairly active on Gerrit reviews. In any case, I can also provide feedback if you don't get any.
Please review https://git.eclipse.org/r/36569 .
(In reply to Gunnar Wagenknecht from comment #34) > ... Also, I don't think anyone is maintaining Platform CVS > anymore. We do maintain CVS if there are severe issues, but there's no feature development in that component at the moment. The main focus from an Eclipse POV is Git. (In reply to Atsuhiko Yamanaka from comment #40) > (In reply to Matthias Sohn from comment #39) > > you misunderstood my question, I am wondering how I can test what you > > developed. > > I guess I need to install the bundles (I am on Mac): > > - com.jcraft.jsch.agentproxy > > - com.jcraft.jsch.agentproxy.eclipse.sshagent > > anything else needed to try this with EGit ? > > Those plugins expects changes for org.eclipse.jsch.{core, ui}. > Check out the followings to the workspace, > * bug179924 branch of https://github.com/ymnk/eclipse.platform.team.git , > and > * master branch of https://github.com/ymnk/eclipse-jsch-agent-proxy.git > > Run > "Eclipse Application" and visit the preference page, > Window > Preferences > General > Network Connections > SSH2 > SSH Agent > > I have confirmed CVS plug-in on Luna can use ssh-agent and pageant with > those plugins. > If EGit refers to org.eclipse.jsch.core plugin, it will automagically work > for ssh-agent without any changes for EGit. Given it works for CVS, and we already distribute JSch in the platform, we should also consider shipping the new parts, assuming the CQs get approved. I'll take that up with the PMC this week.
Hi, there! (In reply to Dani Megert from comment #54) > Given it works for CVS, and we already distribute JSch in the platform, we > should also consider shipping the new parts, assuming the CQs get approved. > I'll take that up with the PMC this week. It here any good news?
(In reply to Atsuhiko Yamanaka from comment #55) > Hi, there! > > (In reply to Dani Megert from comment #54) > > Given it works for CVS, and we already distribute JSch in the platform, we > > should also consider shipping the new parts, assuming the CQs get approved. > > I'll take that up with the PMC this week. > > It here any good news? Yes, there is. The PMC agrees to put this into the Platform if the CQs get approved.
(In reply to Dani Megert from comment #56) > (In reply to Atsuhiko Yamanaka from comment #55) > > Hi, there! > > > > (In reply to Dani Megert from comment #54) > > > Given it works for CVS, and we already distribute JSch in the platform, we > > > should also consider shipping the new parts, assuming the CQs get approved. > > > I'll take that up with the PMC this week. > > > > It here any good news? > > Yes, there is. The PMC agrees to put this into the Platform if the CQs get > approved. nice :-)
(In reply to Dani Megert from comment #56) > Yes, there is. The PMC agrees to put this into the Platform if the CQs get > approved. Can you provide links or CQ numbers?
(In reply to Szymon Ptaszkiewicz from comment #58) > (In reply to Dani Megert from comment #56) > > Yes, there is. The PMC agrees to put this into the Platform if the CQs get > > approved. > > Can you provide links or CQ numbers? I don't think CQs have been filed yet, right Atsuhiko? First, we can review the change: https://git.eclipse.org/r/36569. Then we need to file CQs for the new plug-in(s), both for Orbit and for the Platform.
(In reply to Dani Megert from comment #59) > I don't think CQs have been filed yet, right Atsuhiko? First, we can review > the change: https://git.eclipse.org/r/36569. Yes, the changes reviewed at https://git.eclipse.org/r/36569 has not introduced any new dependencies nor references to third party libraries. So, CQs will not be required, I think. > Then we need to file CQs for the new plug-in(s), both for Orbit and for the > Platform. As Gunnar Wagenknecht has suggested, > We have two options: (a) redistribute them with Eclipse and/or (b) publish a p2 > update site with those three bundles. The option 'b' will not require any new CQs?
Don't we need CQs for: > > - com.jcraft.jsch.agentproxy > > - com.jcraft.jsch.agentproxy.eclipse.sshagent ?
(In reply to Atsuhiko Yamanaka from comment #60) > (In reply to Dani Megert from comment #59) > > I don't think CQs have been filed yet, right Atsuhiko? First, we can review > > the change: https://git.eclipse.org/r/36569. > > Yes, the changes reviewed at https://git.eclipse.org/r/36569 has not > introduced > any new dependencies nor references to third party libraries. So, CQs will > not > be required, I think. CQs are not required for merging https://git.eclipse.org/r/36569. But they are required for providing the full functionality for Putty as well as SSH Agent out of the box in Eclipse. I had a look at the additional plug-ins that are required: (1) com.jcraft.jsch.agentproxy (2) com.jcraft.jsch.agentproxy.eclipse.pageant (3) com.jcraft.jsch.agentproxy.eclipse.sshagent (4) com.jcraft.jsch.agentproxy.eclipse.sshagent.jna A few comments: - There seems to be another dependency embedded in (3): junixsocket. Is that correct? - Do (3) and (4) provide the same functionality - one using junixsocket and the other one using JNA? Given that we should not include (3) at all but just use (4). - (2) and (3) include JNA. Is this the one from https://github.com/twall/jna? Thus, I believe as minimum JNA is required: - CQ JNA required for Platform - ATO CQ for JNA - JNA repackaged as bundle added to Orbit - JNA consumed by Platform Now there is some flexibility with (1), (2) and (4). I'm not sure (2) and (4) should go into Orbit. (1) probably should because it's and extension the JSch. However, (2) and (4) are specific to the the extension point in org.eclipse.jsch.core. Thus, they should probably be added to Platform as org.eclipse.jsch.core.pagent and org.eclipse.jsch.core.sshagent. Or they can even be merged into one bundle or become part of org.eclipse.jsch.core. Thus, here is the remaining action: - CQ for (1) for Platform - ATO CQ for (1) - (1) added as bundle to Orbit - (2) and (4) refactored into org.eclipse.jsch.core namespace and provided as new Gerrit review (no CQ required because Atsuhiko is a committer and can Sign-Off the review).
(In reply to Gunnar Wagenknecht from comment #62) > But they are required for providing the full functionality for Putty as well > as SSH Agent out of the box in Eclipse. > > I had a look at the additional plug-ins that are required: > (1) com.jcraft.jsch.agentproxy > (2) com.jcraft.jsch.agentproxy.eclipse.pageant > (3) com.jcraft.jsch.agentproxy.eclipse.sshagent > (4) com.jcraft.jsch.agentproxy.eclipse.sshagent.jna The latest version is available at https://github.com/ymnk/eclipse-jsch-agent-proxy and please refer to their MANIFEST.MF[1][2]. > A few comments: > - There seems to be another dependency embedded in (3): junixsocket. Is that > correct? > - Do (3) and (4) provide the same functionality - one using junixsocket and > the other one using JNA? Given that we should not include (3) at all but > just use (4). Yes, you are right. The junixsocket had been required for accessing Unit domain sockets without LGPL, but JNA has changed its license and we can use it for that purpose under the Apache Software license. > - (2) and (3) include JNA. Is this the one from https://github.com/twall/jna? Yes, its 4.1.0 has been used. I have gotten those jar files from the maven central repository[3][4]. [1] https://github.com/ymnk/eclipse-jsch-agent-proxy/blob/master/com.jcraft.jsch.agentproxy.eclipse.pageant/META-INF/MANIFEST.MF [2] https://github.com/ymnk/eclipse-jsch-agent-proxy/blob/master/com.jcraft.jsch.agentproxy.eclipse.sshagent/META-INF/MANIFEST.MF [3] http://central.maven.org/maven2/net/java/dev/jna/jna/4.1.0/jna-4.1.0.jar [4] http://central.maven.org/maven2/net/java/dev/jna/jna-platform/4.1.0/jna-platform-4.1.0.jar
(In reply to Gunnar Wagenknecht from comment #62) > Now there is some flexibility with (1), (2) and (4). I'm not sure (2) and > (4) should go into Orbit. (1) probably should because it's and extension the > JSch. I agree. > However, (2) and (4) are specific to the the extension point in > org.eclipse.jsch.core. Thus, they should probably be added to Platform as > org.eclipse.jsch.core.pagent and org.eclipse.jsch.core.sshagent. Or they can > even be merged into one bundle or become part of org.eclipse.jsch.core. Fully agree. The existing dependency chain is a bit comlicated: org.eclipse.jsch.core depends on com.jcraft.jsch and provides extension point in the org.eclipse.* namespace which is then implemented by com.jcraft.jsch.agentproxy.eclipse.pageant (2) and com.jcraft.jsch.agentproxy.eclipse.sshagent.jna (4) which are expected to be included in the Platform either way. I think it would be much cleaner if (2) and (4) could be refactored into org.eclipse.jsch.core namespace if there are no legal issues and if Atsuhiko is willing to contribute it that way. Atsuhiko, what do you think?
(In reply to Szymon Ptaszkiewicz from comment #64) > Fully agree. The existing dependency chain is a bit comlicated: > org.eclipse.jsch.core depends on com.jcraft.jsch and provides extension > point in the org.eclipse.* namespace which is then implemented by > com.jcraft.jsch.agentproxy.eclipse.pageant (2) and > com.jcraft.jsch.agentproxy.eclipse.sshagent.jna (4) which are expected to be > included in the Platform either way. I think it would be much cleaner if (2) > and (4) could be refactored into org.eclipse.jsch.core namespace if there > are no legal issues and if Atsuhiko is willing to contribute it that way. > Atsuhiko, what do you think? There is no problem for us to refactor them com.jcraft.jsch.agentproxy.eclipse.* into org.eclipse.jsch.core namespace.
(In reply to Atsuhiko Yamanaka from comment #65) > (In reply to Szymon Ptaszkiewicz from comment #64) > > Fully agree. The existing dependency chain is a bit comlicated: > > org.eclipse.jsch.core depends on com.jcraft.jsch and provides extension > > point in the org.eclipse.* namespace which is then implemented by > > com.jcraft.jsch.agentproxy.eclipse.pageant (2) and > > com.jcraft.jsch.agentproxy.eclipse.sshagent.jna (4) which are expected to be > > included in the Platform either way. I think it would be much cleaner if (2) > > and (4) could be refactored into org.eclipse.jsch.core namespace if there > > are no legal issues and if Atsuhiko is willing to contribute it that way. > > Atsuhiko, what do you think? > > There is no problem for us to refactor them > com.jcraft.jsch.agentproxy.eclipse.* > into org.eclipse.jsch.core namespace. Great! So now the remaining questions is whether these should be two separate bundles or the code should be integrated directly into the org.eclipse.jsch.core bundle?
(In reply to Atsuhiko Yamanaka from comment #53) > Please review https://git.eclipse.org/r/36569 . Fixed in master with: http://git.eclipse.org/c/platform/eclipse.platform.team.git/commit/?id=7066a7209a9d2f386d2c3dd51d30f60cf5964a2e The remaining work to do is refactoring com.jcraft.jsch.agentproxy.eclipse.* to org.eclipse.* namespace. I thought about it last night and I think a good way to do that would be to make them fragments on top of org.eclipse.jsch.core with dependency on com.jcraft.jsch.agentproxy which would be consumed from Orbit (as well as other dependencies like JNA and others it there are any). This way org.eclipse.jsch.core would be still usable without agent fragments and without dependency on com.jcraft.jsch.agentproxy. Atsuhiko, what to you think?
(In reply to Szymon Ptaszkiewicz from comment #67) > (In reply to Atsuhiko Yamanaka from comment #53) > > Please review https://git.eclipse.org/r/36569 . > > Fixed in master with: > > http://git.eclipse.org/c/platform/eclipse.platform.team.git/commit/ > ?id=7066a7209a9d2f386d2c3dd51d30f60cf5964a2e > > The remaining work to do is refactoring com.jcraft.jsch.agentproxy.eclipse.* > to org.eclipse.* namespace. I thought about it last night and I think a good > way to do that would be to make them fragments on top of > org.eclipse.jsch.core with dependency on com.jcraft.jsch.agentproxy which > would be consumed from Orbit (as well as other dependencies like JNA and > others it there are any). This way org.eclipse.jsch.core would be still > usable without agent fragments and without dependency on > com.jcraft.jsch.agentproxy. Atsuhiko, what to you think? As you have suggested, I'll change those plug-ins to fragments and locate them under org.eclipse.jsch.core.agentproxy namespace.
(In reply to Atsuhiko Yamanaka from comment #68) > As you have suggested, I'll change those plug-ins to fragments and > locate them under org.eclipse.jsch.core.agentproxy namespace. We have just entered M6 which would be a good moment to start finishing this if we plan to have a complete solution for Mars in June. Atsuhiko, do you have any update?
Created attachment 250465 [details] fragments for using pageant and ssh-agent This zip file includes fragments, * org.eclipse.jsch.core.agentproxy.pageant, * org.eclipse.jsch.core.agentproxy.ssh-agent
(In reply to Szymon Ptaszkiewicz from comment #69) > (In reply to Atsuhiko Yamanaka from comment #68) > > As you have suggested, I'll change those plug-ins to fragments and > > locate them under org.eclipse.jsch.core.agentproxy namespace. > > We have just entered M6 which would be a good moment to start finishing this > if we plan to have a complete solution for Mars in June. Atsuhiko, do you > have any update? Sorry for my delay. I have attached a zip file, attachment 250465 [details]. That zip file has included two fragments for using pageant and ssh-agent. * I have confirmed they are working on Eclipse Mars M4. * Those plugins has included jna-plaform-4.1.0.jar[1] and jar files of jsch-agent-proxy 0.0.8. * Where should they be located at? Under eclipse.platform.team/bundles ? [1] http://central.maven.org/maven2/net/java/dev/jna/jna-platform/4.1.0/jna-platform-4.1.0.jar
(In reply to Atsuhiko Yamanaka from comment #71) > Sorry for my delay. I have attached a zip file, attachment 250465 [details]. > That zip file has included two fragments for using pageant and ssh-agent. > ... > * Those plugins has included jna-plaform-4.1.0.jar[1] and jar files of > jsch-agent-proxy 0.0.8. > * Where should they be located at? Under eclipse.platform.team/bundles ? Thanks for response! Can you please push it as a Gerrit change for review? The new fragments should be located under eclipse.platform.team/bundles. External dependencies like jna or jsch-agent-proxy should be consumed from Orbit in the same way as it is already done with com.jcraft.jsch bundle. Then, we need only an entry in MANIFEST.MF that certain fragment requires some 3rd part bundle and that bundle will come from Orbit. From a quick look at the code in the attached zip file, I see there is only one class in each fragment and there is no API defined there. In such case, it would be good to put this class in an internal package so that if we decide to change it later on, we won't get API violation errors. > * I have confirmed they are working on Eclipse Mars M4. Thanks, that's good to know!
New Gerrit change created: https://git.eclipse.org/r/41838
(In reply to Eclipse Genie from comment #73) > New Gerrit change created: https://git.eclipse.org/r/41838 For reference, here is the list of CQs needed for this change: http://dev.eclipse.org/ipzilla/show_bug.cgi?id=9291 http://dev.eclipse.org/ipzilla/show_bug.cgi?id=9292 http://dev.eclipse.org/ipzilla/show_bug.cgi?id=9293 http://dev.eclipse.org/ipzilla/show_bug.cgi?id=9294 http://dev.eclipse.org/ipzilla/show_bug.cgi?id=9295 http://dev.eclipse.org/ipzilla/show_bug.cgi?id=9296 http://dev.eclipse.org/ipzilla/show_bug.cgi?id=9297
(In reply to Eclipse Genie from comment #73) > New Gerrit change created: https://git.eclipse.org/r/41838 Atsuhiko, I saw on maven central that the latest version of jsch-agent-proxy jars is 0.0.9. Wouldn't it be better to use the latest version rather than 0.0.8 which is used in this change?
(In reply to Szymon Ptaszkiewicz from comment #75) > (In reply to Eclipse Genie from comment #73) > > New Gerrit change created: https://git.eclipse.org/r/41838 > > Atsuhiko, I saw on maven central that the latest version of jsch-agent-proxy > jars is 0.0.9. Wouldn't it be better to use the latest version rather than > 0.0.8 which is used in this change? Yes, it is better to use the latest version, even if 0.0.8 is enough for Eclipse. FYI, here is diff between 0.0.8 and 0.0.9, https://github.com/ymnk/jsch-agent-proxy/compare/ef491c2592f183f7a67a60d47cbdd107571e88ed...12c3d64fc2b0a4fd37659369edfdee26e48954e2
(In reply to Atsuhiko Yamanaka from comment #76) > Yes, it is better to use the latest version, even if 0.0.8 is enough for > Eclipse. > > FYI, here is diff between 0.0.8 and 0.0.9, > > https://github.com/ymnk/jsch-agent-proxy/compare/ > ef491c2592f183f7a67a60d47cbdd107571e88ed... > 12c3d64fc2b0a4fd37659369edfdee26e48954e2 Thanks, I will transform CQs to 0.0.9.
Unfortunately, based on CQ 9291 and CQ 9292, we are unable to move forward with the request to include JNA libraries as both provenance and license cannot be resolved to a level satisfactory for Eclipse distribution. Therefore, I have abandoned the Gerrit change https://git.eclipse.org/r/41838 since there is nothing more that we can do with it right now. The API needed to plug it into Eclipse is already released (see comment 67) but we cannot release the implementation that would make use of the new API and use the JNA libraries. However, anyone is allowed to plug it on their own by implementing the API using the JNA libraries in a similar way as shown in the Gerrit change https://git.eclipse.org/r/41838 or provide an alternative implementation without the JNA libraries that could be released with Eclipse.
Atsuhiko, I'm sorry the Gerrit change https://git.eclipse.org/r/41838 cannot be shipped with Eclipse. I am not 100% sure if this is allowed, but I think that you as the author could publish the ssh-agent implementation using Eclipse marketplace or your webpage so that anyone willing to use ssh-agent could install it locally.
I suggest we open a CQ for junixsocket. If we use the junixsocket version of jsch-agent-proxy (JUnixDomainSocketFactory) we lose the Windows (pageant) support but it would still work on Unix.
(In reply to Roland Schulz from comment #80) > I suggest we open a CQ for junixsocket. If we use the junixsocket version of > jsch-agent-proxy (JUnixDomainSocketFactory) we lose the Windows (pageant) > support but it would still work on Unix. As for ssh-agent, we have options to use junixsocket or 'nc'[1][2] command. I have recognized that 'nc' command has been included in Mac OSX by the default since its Tiger version, so Mac OSX users will be happy with it. As for pageant, I'm thinking of using org.eclipse.swt.internal.win32.OS. We need to get accesses to following Win32 APIs[3], FindWindow() GetCurrentThreadId() CreateFileMapping() MapViewOfFile() MemMove() SendMessage() UnmapViewOfFile() CloseHandle(), and 'OS' class has supported almost all of them, but it seems CreateFileMapping() has not bee supported yet. Is it possible to ask SWT win32 team for supporting CreateFileMapping()? [1] http://linux.die.net/man/1/nc [2] https://github.com/ymnk/jsch-agent-proxy/blob/master/jsch-agent-proxy-usocket-nc/src/main/java/com/jcraft/jsch/agentproxy/usocket/NCUSocketFactory.java [3] https://github.com/ymnk/jsch-agent-proxy/blob/master/jsch-agent-proxy-pageant/src/main/java/com/jcraft/jsch/agentproxy/connector/PageantConnector.java
(In reply to Szymon Ptaszkiewicz from comment #79) > I am not 100% sure if this is allowed, but I think > that you as the author could publish the ssh-agent implementation using > Eclipse marketplace or your webpage so that anyone willing to use ssh-agent > could install it locally. If it is required, we will.
Just FYI there is CQ open for jnr-unixsocket (which should serve same puprose). https://dev.eclipse.org/ipzilla/show_bug.cgi?id=9089
jnr-unixsocket is being proposed as it's now a dependency of the java docker-client library ( https://github.com/spotify/docker-client/issues/98 ) which we intend to use for the Docker management UI that will be added in the Linux Tools Project. At the time jnr-unixsocket had not seen a release in a few years and was inactive. The JNR project on the other hand seems to be what http://openjdk.java.net/jeps/191 will be based upon. You could take a look at https://github.com/jnr/jnr-unixsocket and see if this satisfies what you need.
(In reply to Roland Grunberg from comment #84) > jnr-unixsocket is being proposed as it's now a dependency of the java > docker-client library ( https://github.com/spotify/docker-client/issues/98 ) > which we intend to use for the Docker management UI that will be added in > the Linux Tools Project. At the time jnr-unixsocket had not seen a release > in a few years and was inactive. The JNR project on the other hand seems to > be what http://openjdk.java.net/jeps/191 will be based upon. > > You could take a look at https://github.com/jnr/jnr-unixsocket and see if > this satisfies what you need. Thank you for information. I'll check jnr-unixsocket.
(In reply to Atsuhiko Yamanaka from comment #82) > (In reply to Szymon Ptaszkiewicz from comment #79) > > I am not 100% sure if this is allowed, but I think > > that you as the author could publish the ssh-agent implementation using > > Eclipse marketplace or your webpage so that anyone willing to use ssh-agent > > could install it locally. > > If it is required, we will. FYI, we have deployed those plugins at our Eclipse update site, http://eclipse.jcraft.com/ Choose one of them, JSch Agent Proxy Plug-in JSch Agent Proxy Plug-in for Pageant using JNA JSch Agent Proxy Plug-in for ssh-agent using JNA Those plugins expect to be installed into Eclipse 4.5(Mars) M6. After installing it successfully, don't forget to check pageant or ssh-agent at Window > Preferences > General > Network Connections > SSH2 > SSH Agent
(In reply to Atsuhiko Yamanaka from comment #85) > (In reply to Roland Grunberg from comment #84) > > jnr-unixsocket is being proposed as it's now a dependency of the java > > docker-client library ( https://github.com/spotify/docker-client/issues/98 ) > > which we intend to use for the Docker management UI that will be added in > > the Linux Tools Project. At the time jnr-unixsocket had not seen a release > > in a few years and was inactive. The JNR project on the other hand seems to > > be what http://openjdk.java.net/jeps/191 will be based upon. > > > > You could take a look at https://github.com/jnr/jnr-unixsocket and see if > > this satisfies what you need. > > Thank you for information. I'll check jnr-unixsocket. We have confirmed that jnr-unixsocket works well with jsch-agent-proxy[1]. We will try to integrate it into the eclipse plug-in, and deploy it to our eclipse plug-ins site. If CQ9089 is approved, we will move it under org.eclipse.jsch.core as soon as possible. [1] https://github.com/ymnk/jsch-agent-proxy/commit/dc3c05ddcfd4de96d9329b6e7fe6734969ef7b97 [2] https://dev.eclipse.org/ipzilla/show_bug.cgi?id=9089
+1 I am really looking forward to this extension which will improve my SSH experience notably with TCF terminals.
(In reply to Atsuhiko Yamanaka from comment #87) > If CQ9089 is approved, we will move it under org.eclipse.jsch.core as soon > as possible. FYI: CQ9089 is approved. Should be possible to get a re-use approval for platform.
(In reply to Szymon Ptaszkiewicz from comment #78) > Unfortunately, based on CQ 9291 and CQ 9292, we are unable to move forward > with the request to include JNA libraries as both provenance and license > cannot be resolved to a level satisfactory for Eclipse distribution. > > Therefore, I have abandoned the Gerrit change > https://git.eclipse.org/r/41838 since there is nothing more that we can do > with it right now. CQ 9291 and CQ 9292 are now approved. I will restore the Gerrit change so that we can try to push it for 4.6.
To cross-reference, I have added the Orbit Piggy back CQs and listed them in the Orbit bug 488321.
Created attachment 259972 [details] jdeps output ran on proposed jars These jars appear to use "JDK internals". I am not sure if there is a "better" solution, but after I visually examined the proposed jars, I ran 'jdeps' against them to see if they were using "internal VM" APIs. And they seem to be, based on the output of ${JAVA_HOME}/bin/jdeps -classpath ${JAVA_HOME}/lib/tools.jar:${PWD} -jdkinternals Where JAVA_HOME was a recent Java 8 VM and PWD was where I downloaded all the jars. (See bug 470723 for some small amount of related info). So ... please confirm this is something we want to introduce this release. Is there a plan for when we move to Java 9? What will the impact be? Or, am I misinterpreting the output of 'jdeps'?
(In reply to David Williams from comment #92) > Where JAVA_HOME was a recent Java 8 VM and PWD was where I downloaded all > the jars. > (See bug 470723 for some small amount of related info). > > So ... please confirm this is something we want to introduce this release. > Is there a plan for when we move to Java 9? What will the impact be? For what it is worth, I also tried running jdeps from a recent Java 9 Early Access JDK and below was the only output. Not sure if that means there was only one problem ... or if it stopped at the first problem found? Perhaps the wiki referred to in the "Warning" message would help get rid of the JDK Internals, but I did not look at it too closely. It does mention "java.awt.peer" but not sure it applies to this specific code. = = = = = = = = $ cat jdeps9.out.txt jna-platform-4.1.0.jar -> java.desktop com.sun.jna.platform.WindowUtils$MacWindowUtils$1 (jna-platform-4.1.0.jar) -> java.awt.peer.ComponentPeer JDK internal API (java.desktop) Warning: JDK internal APIs are unsupported and private to JDK implementation that are subject to be removed or changed incompatibly and could break your application. Please modify your code to eliminate dependency on any JDK internal APIs. For the most recent update on JDK internal API replacements, please check: https://wiki.openjdk.java.net/display/JDK8/Java+Dependency+Analysis+Tool
(In reply to David Williams from comment #92 and comment #93) I don't know the internal implementation of the new libraries so I am not able to answer your question. Atsuhiko, can you please clarify the concerns raised in comment 92 and comment 93?
How would this affect non-Oracle JVMs ? OpenJDK? IBM JVMs?
(In reply to Alexander Kurtakov from comment #95) > How would this affect non-Oracle JVMs ? OpenJDK? IBM JVMs? Remarkably, in the past, at least, many of the commonly used 'internals' were the same, in my experience, though not always, such as with Xerces and Xalan related packages). But Oracle has been warning everyone that using JDK internals will not work well with Java 9 because I assume they anticipate a lot of changes to JDK Internals in Java 9. Presumably, they will be renamed, or removed, or made to be "not visible". (Just guessing). So I think the long-term concern is will our code run on Java 9. Even if, let's say, we fixed in Neon.1 or Neon.2, then in Neon.3 (currently anticipated to be "the Java 9 release", that many users will still be on June's Neon and try to run on Java 9. If the code fails gracefully, I guess that would kind of be ok (in the sense they would lose that function -- and, at least, not be "dead in the water"-- but I just thought it best to point out this complication and ask what the team wanted to do about it.
(In reply to David Williams from comment #96) > (In reply to Alexander Kurtakov from comment #95) > > How would this affect non-Oracle JVMs ? OpenJDK? IBM JVMs? > > Remarkably, in the past, at least, many of the commonly used 'internals' > were the same, in my experience, though not always, such as with Xerces and > Xalan related packages). > > But Oracle has been warning everyone that using JDK internals will not work > well with Java 9 because I assume they anticipate a lot of changes to JDK > Internals in Java 9. Presumably, they will be renamed, or removed, or made > to be "not visible". (Just guessing). > > So I think the long-term concern is will our code run on Java 9. Even if, > let's say, we fixed in Neon.1 or Neon.2, then in Neon.3 (currently > anticipated to be "the Java 9 release", that many users will still be on > June's Neon and try to run on Java 9. If the code fails gracefully, I guess > that would kind of be ok (in the sense they would lose that function -- and, > at least, not be "dead in the water"-- but I just thought it best to point > out this complication and ask what the team wanted to do about it. Can we get some comment from the contributors of this change for what their plan/testing is regarding Java 9/internals usage? How gracefully potential failure would be and etc.?
For the records, I have sent a private email to Atsuhiko asking him to provide his input regarding concerns raised in comment 92 and comment 93.
(In reply to Szymon Ptaszkiewicz from comment #98) > For the records, I have sent a private email to Atsuhiko asking him to > provide his input regarding concerns raised in comment 92 and comment 93. Frankly to say, I could not understand what is the problem. >$ cat jdeps9.out.txt >jna-platform-4.1.0.jar -> java.desktop > com.sun.jna.platform.WindowUtils$MacWindowUtils$1 (jna-platform-4.1.0.jar) > -> java.awt.peer.ComponentPeer JDK internal API (java.desktop) JNA may depend on java.awt.peer.ComponentPeer, but jsch.agentproxy must not refer to GUI APIs.
Alex, David, does comment 99 answer your questions?
(In reply to Szymon Ptaszkiewicz from comment #100) > Alex, David, does comment 99 answer your questions? Not really. It appears "internals" are used (by using "jdepends") so what happens if those internals are not available?
(In reply to David Williams from comment #101) > (In reply to Szymon Ptaszkiewicz from comment #100) > > Alex, David, does comment 99 answer your questions? > > Not really. It appears "internals" are used (by using "jdepends") so what > happens if those internals are not available? The class WindowUtils uses AWT internals. It will likely be broken with Java 9. However, from my understanding, WindowUtils it not used for thus. Thus, we should be good.
(In reply to Gunnar Wagenknecht from comment #102) > (In reply to David Williams from comment #101) > > (In reply to Szymon Ptaszkiewicz from comment #100) > > > Alex, David, does comment 99 answer your questions? > > > > Not really. It appears "internals" are used (by using "jdepends") so what > > happens if those internals are not available? > > The class WindowUtils uses AWT internals. It will likely be broken with Java > 9. However, from my understanding, WindowUtils it not used for thus. Thus, > we should be good. I don't understand. Two things. If WindowsUtils is not used, why is it "in there"? Second, from the attachment in comment 92 there are several dozen "internal uses". I've always assumed my attempt to use Java 9, where only one 'internal' was found, must have been faulty. Has anyone tried to replicate the analysis? Lastly, I think the "cure" for this is a commitment that "class not found" sort of errors (or classNotDefined, or whatever they are) will be detected, and degrade gracefully. Sorry to seem "picky". I'll admit my reasons are selfish. I do not want to waste my time putting these in orbit if they are not the right solution, simply because whatever time I spend on it means something else won't get done. So, I was just looking for a positive confirmation these were the right solution, and so far the response seems to be "probably".
(In reply to Atsuhiko Yamanaka from comment #86) > FYI, we have deployed those plugins at our Eclipse update site, > http://eclipse.jcraft.com/ > > Choose one of them, > JSch Agent Proxy Plug-in > JSch Agent Proxy Plug-in for Pageant using JNA > JSch Agent Proxy Plug-in for ssh-agent using JNA > > Those plugins expect to be installed into Eclipse 4.5(Mars) M6. I've tried this with Eclipse Neon. Installation went ok. However, there is nothing showing up here: > After installing it successfully, don't forget to check pageant or ssh-agent > at > Window > Preferences > General > Network Connections > SSH2 > SSH Agent Does it need an update for Neon?
I got it working in Neon. Details here: https://eclipseguru.github.io/eclipse-jsch-agent-proxy/
Atsuhiko, the feature no longer works smoothly on macOS Sierra. Due to some changes to the SSH setup, Eclipse with the ssh-agent extension no longer has access to the keys. Accessing Git fails with "JSchException: Auth fail". The CLI SSH client had the same issue. I was able to make SSH auto-load keys by setting AddKeysToAgent in ~/.ssh/config.
Atsuhiko, the feature no longer works smoothly on macOS Sierra. Due to some changes to the SSH setup, Eclipse with the ssh-agent extension no longer has access to the keys. Accessing Git fails with "JSchException: Auth fail". The CLI SSH client had the same issue. I was able to make SSH auto-load keys by setting AddKeysToAgent in ~/.ssh/config. Thus, before being able to push/pull from within Eclipse I have to perform a git push/pull from command line first. This auto-populates ssh-agent with the key. macOS used to do it automatically during login. That's no longer the case.
No way! 10 years and still no working ssh-agent nor native ssh support?! You gotta be kidding me.. can you just take a look at Intellij to see how that should look and work? How about we can add this variable somewhere in eclipse configuration - that seems to work.. GIT_SSH=/usr/bin/ssh
Negative. GIT_SSH does not work as well on macOS 10.12. Please make Eclipse work with ssh-agent in order to use git and smartcards.. passwords are good but smartcards are better :-)
(In reply to Tomasz CEDRO from comment #109) > Negative. GIT_SSH does not work as well on macOS 10.12. Please make Eclipse > work with ssh-agent in order to use git and smartcards.. passwords are good > but smartcards are better :-) FWIW, setting GIT_SSH still works. Just make sure you are setting it the correct way. ~/.profile or ~/.bash* doesn't work for macOS apps started via Dock/Finder/etc. https://wiki.eclipse.org/EGit/FAQ#Store_SSH_Key_Passphrase_in_Mac_Keyring
I could not get it to work with GIT_SSH=/usr/bin/ssh as environment variable in Mac OS X 10.13.2. All git operations with EGit run into a timeout then. Neither does the mechanism from https://eclipseguru.github.io/eclipse-jsch-agent-proxy/ work (it just keeps asking for the passphrase). Even the native support for passphrase authentication is much worse since the upgrade to Oxygen.2 (4.7.2) EGit keeps asking for the passphrase for each operation (it does not cache it). Does anyone have it working in Mac OS High Sierra with 4.7.2?
(In reply to Konrad Windszus from comment #111) > I could not get it to work with GIT_SSH=/usr/bin/ssh as environment variable > in Mac OS X 10.13.2. All git operations with EGit run into a timeout then. > Neither does the mechanism from > https://eclipseguru.github.io/eclipse-jsch-agent-proxy/ work (it just keeps > asking for the passphrase). Even the native support for passphrase > authentication is much worse since the upgrade to Oxygen.2 (4.7.2) EGit > keeps asking for the passphrase for each operation (it does not cache it). > Does anyone have it working in Mac OS High Sierra with 4.7.2? This is probably bug 529173 which was fixed recently on the master branch [1]. Could you retry with the latest nightly build from http://download.eclipse.org/egit/updates-nightly ? [1] https://git.eclipse.org/r/#/c/115294/
(In reply to Konrad Windszus from comment #111) > I could not get it to work with GIT_SSH=/usr/bin/ssh as environment variable > in Mac OS X 10.13.2. All git operations with EGit run into a timeout then. I can confirm this behavior on macOS High Sierra and recent Eclipse EGit versions. I have not figured out exactly when it broke but it's definitely not working anymore for me either. > Neither does the mechanism from > https://eclipseguru.github.io/eclipse-jsch-agent-proxy/ work (it just keeps > asking for the passphrase). Yes, this solution also broke at some point. It does not currently work for me anymore. However, I haven't had time yet to investigate which Eclipse/EGit release broke it.
(In reply to Matthias Sohn from comment #112) I just updated to the linked EGit nightly and this solved the issue for me. I am using Gunnar's jsch-agent-proxy on Ubuntu 18.04.
Is GIT_SSH environment variable working for somebody in Eclipse Photon (v4.8.0)? I set it like this: GIT_SSH=C:\Cygwin\bin\ssh.exe but it seems to have no effect. At least would be nice to see that in log (see bug#489871), or maybe have this option configurable via interface (bug#355744)? org.eclipse.egit (5.0.0.201806131550-r) "Git integration for Eclipse" org.eclipse.jgit (5.0.0.201806131550-r) "JGit Core" org.eclipse.platform (4.8.0.v20180611-0656) "Eclipse Platform"
I'm trying to use eclipse-jsch-agent-proxy with Eclipse 2019-03 on EL7 but not having any luck. I'm trying to checkout a gitlab URL like: ssh://git@HOST:51424/USER/PROJECT.git but it simply fails with 'No more authentication methods available'. Tried to update from Egit nightly but that appears to be incompatible. Setting GIT_SSH=/usr/bin/ssh works.
Let's be realistic. It doesn't look like anyone is going to work on this. The support/progress/state of jsch raised some eyebrows in the past. EGit is likely moving away from it. If someone is interested in helping EGit with SSH agent integration please visit bug 541274. I recommend closing this as WONTFIX from a Platform Team perspective given that CVS would be the only plug-in benefiting from it.
