Community
Participate
Working Groups
On preference page Team - CVS - SSH2 Connection Method - Key Management there are two buttons ("Generate DSA Key..." and "Generate RSA Key...") which both are creating an ssh key pair. When using without a password it all works fine, but using a passphrase doesn't. I used "Save Private Key..." (which stores both public and private key - should be renamed to "Save Keys...", but it's another feature request) to store the keys. I copied the public key to the server and tried to connect with the private key: the one without a password was working, the other one didn't. I verified this behaviour with the generated keys with normal ssh (cygwins openssh) and got the same results (without password: OK, with password: failed). It failes for both DSA and RSA key generation. It seems to be a problem with the passphrase protection algorithm on Team CVS SSH2 preference page.
Hi, I'm a commiter who has implemented that functionality. (In reply to comment #0) > I copied the public key to the server and tried to connect with the private > key: the one without a password was working, the other one didn't. > I verified this behaviour with the generated keys with normal ssh (cygwins > openssh) and got the same results (without password: OK, with password: > failed). > It failes for both DSA and RSA key generation. I have tried above operation, but I can not reproduce such a problem on Eclipse SDK 3.2.1. I mean that after generating key-pair on WinXP with cygwin environment, I have done following steps and I can successfully login to the remote host. $ cd /cygdrive/c/Documents\ and\ Settings/XXXXX/ssh $ ls id* id_dsa id_dsa.pub $ head -3 id_dsa -----BEGIN DSA PRIVATE KEY----- Proc-Type: 4,ENCRYPTED DEK-Info: DES-EDE3-CBC,14DD270BFFCC83EF $ cat ./id_dsa.pub | ssh XXXX@YYYYYY "cat - >> .ssh/authorized_keys" XXXX@YYYYYY's password: $ ssh -i ./id_dsa XXXX@YYYYYY Enter passphrase for key './id_dsa': I'll wait for feedbacks from others.
Thanks for your fast reply. Additional comments: Generated DSA key with "Generate DSA Key...", pressed "Save Private Key..." (saved as 'id_dsa' and 'id_dsa.pub'). Tried connection with cygwin ssh. (Note: only private/public key login and protocol version 2 is allowed) $ ssh -v -i id_dsa [user]@[host] OpenSSH_4.4p1, OpenSSL 0.9.8d 28 Sep 2006 debug1: Connecting to [host] [ip] port 22. debug1: Connection established. debug1: identity file id_dsa type 2 debug1: Remote protocol version 1.99, remote software version OpenSSH_3.7.1p2 debug1: match: OpenSSH_3.7.1p2 pat OpenSSH_3.* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_4.4 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: server->client aes128-cbc hmac-md5 none debug1: kex: client->server aes128-cbc hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug1: Host '[host]' is known and matches the RSA host key. debug1: Found key in [path]/known_hosts:2 debug1: ssh_rsa_verify: signature correct debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: SSH2_MSG_SERVICE_REQUEST sent debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue: publickey debug1: Next authentication method: publickey debug1: Offering public key: id_dsa debug1: Server accepts key: pkalg ssh-dss blen 434 debug1: PEM_read_PrivateKey failed debug1: read PEM private key done: type <unknown> Enter passphrase for key 'id_dsa': debug1: PEM_read_PrivateKey failed debug1: read PEM private key done: type <unknown> Enter passphrase for key 'id_dsa': debug1: PEM_read_PrivateKey failed debug1: read PEM private key done: type <unknown> Enter passphrase for key 'id_dsa': debug1: No more authentication methods to try. Permission denied (publickey). Same test with same result on OpenSSH_3.8.1p1 Debian-8.sarge.4 pat OpenSSH_3.* Same result with "Generate RSA Key..."
Is your pass-phrase in ASCII characters?
Yes, used password "test" for test purposes, but others failed, too.
I can not reproduce your problem and there is no clue to guess what happens on your environment, fankly to say. After generating and saving the key on Team - CVS - SSH2 Connection Method - Key Management , can you load that key by Team - CVS - SSH2 Connection Method - Key Management - Load Existing Key... ?
Created attachment 55473 [details] Screenshot: ssh key generation with eclipse
Created attachment 55474 [details] Example: generated keys (DSA+RSA)
Detailed steps to reproduce the problem: I generated a key with "Generate DSA Key...", typed a passphrase "test" and confirmed (see screenshot Eclipse-SSH-Keygen.png). I pressed "Save Private Key..." and saved the key as 'id_dsa_test'. Attached you can find two keys (RSA+DSA) generated with "Generate DSA/RSA key...", password: test I copied 'id_dsa_test.pub' to 'authorized_keys' on a server. But the error appears when ssh is trying to read the private key: $> ssh -v -i id_dsa_test user@server [...] debug1: Offering public key: id_dsa_test debug1: Server accepts key: pkalg ssh-dss blen 434 debug1: PEM_read_PrivateKey failed debug1: read PEM private key done: type <unknown> > After generating and saving the key on > Team - CVS - SSH2 Connection Method - Key Management > , can you load that key by > Team - CVS - SSH2 Connection Method - Key Management - Load Existing Key... Yes, I can load the keys in eclipse. When I load it, I'm asked for a password and the key is displayed. I can continue working with this key, e.g. I can save the key without a password and then it works. My test environments: Windows XP, Eclipse 3.2.1 Debian, Eclipse 3.1.2 SSH: OpenSSH_4.4p1, OpenSSL 0.9.8d Note: When I look at the eclipse-generated keys I see a difference from keys generated by ssh-keygen: At the end of an encrypted key from ssh-keygen I can always see "==", but I can't find equal signs on eclipse-generated keys.
(In reply to comment #7) > Created an attachment (id=55474) [details] > Example: generated keys (DSA+RSA) On WindowsXP and with Cygwin, $ unzip test_keys.zip $ ssh -v -i ./id_dsa_test xxxx@yyyy OpenSSH_4.2p1, OpenSSL 0.9.8 05 Jul 2005 debug1: Connecting to yyyy [zzzz] port 22. debug1: Connection established. debug1: identity file ./id_dsa_test type -1 debug1: Remote protocol version 2.0, remote software version OpenSSH_4.2 debug1: match: OpenSSH_4.2 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_4.2 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: server->client aes128-cbc hmac-md5 none debug1: kex: client->server aes128-cbc hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug1: Host YYYY and matches the RSA host key. debug1: Found key in /home/ymnk/.ssh/known_hosts:2 debug1: ssh_rsa_verify: signature correct debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: SSH2_MSG_SERVICE_REQUEST sent debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue: publickey,gssapi-with-mic,password debug1: Next authentication method: publickey debug1: Trying private key: ./id_dsa_test debug1: PEM_read_PrivateKey failed debug1: read PEM private key done: type <unknown> Enter passphrase for key './id_dsa_test': debug1: read PEM private key done: type DSA With the passphrase "test", it has been successfully decrypted. There must be a problem on your cygwin environment. How about using ssh client on Debian?
Yes, I agree with you, it seems to be something in the environment, but I don't have a clue what it could be. It is definitly a problem when reading/decrypting the private key: I tried to use ssh-agent, but ssh-add gave an error when trying to read the private key with password. I did some experiments and found out that it doesn't work on my machines installed Cygwin: OpenSSH_4.4p1, OpenSSL 0.9.8d 28 Sep 2006 Ubuntu/Debian: OpenSSH_4.2p1 Debian-7ubuntu3.1, OpenSSL 0.9.8a 11 Oct 2005 but it was working on an old SuSE Linux: SuSE: OpenSSH_3.7.1p2, SSH protocols 1.5/2.0, OpenSSL 0.9.7b 10 Apr 2003 The funny thing is, that you use the same SSH version as I have on Ubuntu/Debian - on yours it's working, but not on mine. Do you have any idea what the reason could be? The only difference I could find in the debug log: debug1: Server accepts key: pkalg ssh-dss blen 434 right before I'm asked for a password when I'm not able to read the private key. Could it be a option when compiling ssh client (and if so, what option)? Can anybody else reproduce this behaviour?
Some tries with the key I sent: $ openssl version OpenSSL 0.9.7e 25 Oct 2004 $ openssl dsa -in id_dsa_test -noout read DSA key Enter PEM pass phrase: $ ---------- $ openssl version OpenSSL 0.9.8d 28 Sep 2006 $ openssl dsa -in id_dsa_test -noout read DSA key Enter PEM pass phrase: unable to load Key 192:error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad decrypt:evp_enc.c:461: 192:error:0906A065:PEM routines:PEM_do_header:bad decrypt:pem_lib.c:425: $ ---------- OpenSSL 0.9.7b 10 Apr 2003 OK OpenSSL 0.9.7e 25 Oct 2004 OK OpenSSL 0.9.8d 28 Sep 2006 FAILED Which openssl version are you using?
Hi, I could also reproduce your problem! (In reply to comment #11) > OpenSSL 0.9.7b 10 Apr 2003 OK > OpenSSL 0.9.7e 25 Oct 2004 OK > OpenSSL 0.9.8d 28 Sep 2006 FAILED > Which openssl version are you using? As you have written, it seems there are changes in 'PEM_read_PrivateKey' of OpenSSL. OpenSSL 0.9.7f OK OpenSSL 0.9.8a FAILED I'll check what has happed. Thank you for your feedback!
(In reply to comment #12) > Hi, > I could also reproduce your problem! > (In reply to comment #11) > As you have written, it seems there are changes in 'PEM_read_PrivateKey' of > OpenSSL. By the way, this problem is not related to the problem that you can not use encrypted key on Eclipse, because it is not using OpenSSL. Are you explicitly registering your generated key to Window > Preferences... > Team > CVS > SSH2 Connection Method > General > Private Keys ?
> I could also reproduce your problem! Oh, it was hard work to convince you - it's a tricky problem! I had serious doubts about myself. > By the way, this problem is not related to the problem that you can not use > encrypted key on Eclipse, because it is not using OpenSSL. > Are you explicitly registering your generated key to > Window > Preferences... > Team > CVS > SSH2 Connection Method > General > > Private Keys Yes, you are right :-) I'm using SVN and was looking for a nice solution for my clients to generate keys without installing cygwin-ssh (Putty is not an option because they store the keys in yet another format). But there is no key management in subversion yet. I don't know how they handle key reading, but it is not possible to connect via ssh+svn with eclipse-cvs generated keys with passwords. Seeing that I tried with original SSH and it failed, too. That's how I came to that problem. Maybe you can share your knowledge with the guys from subversion and go together in the future?
(In reply to comment #12) > As you have written, it seems there are changes in 'PEM_read_PrivateKey' of > OpenSSL. > OpenSSL 0.9.7f OK > OpenSSL 0.9.8a FAILED > I'll check what has happed. I found the problem in jsch, which is ssh2 client included Eclipse SDK, and have fixed it. The problem exists in the padding for ciphered private key. OpenSSL 0.9.8a(and later) has checked its correctness strictly. Now, jsch has implemented PKCS#5 padding and it will be accpeted by every OpenSSL version. If you are interested in trying fixed version, you can update jsch plug-in at the update site, http://eclipse.jcraft.com/ # FYI, I don't know the reason, but after update operation, # I needed to delete 'plugins/com.jcraft.jsch_0.1.28.jar' to enable # updated version. Please note that it is the informal version and it is not from Eclipse.Org.
(In reply to comment #14) > Maybe you can share your knowledge with the guys from subversion and go > together in the future? Of course, if I can contribute something for them(Subclipe or Subversive?), it is my greate pleasure.
It's working perfectly! Thank you very much! Shall I close this bug or is it your task when the fix has been taken to the eclipse main trunk?
(In reply to comment #17) > It's working perfectly! > Thank you very much! Thank you for your testing. > Shall I close this bug or is it your task when the fix has been taken to the > eclipse main trunk? Please keep it to be opened. IMHO, this issue should be fixed, because it is true that Eclipse SDK has generated garbages for some environment (,where OpenSSL 0.9.8a is used), however I don't have the right to update jsch version in Eclipse SDK. I'll wait for comments from others who have the right and can make decisions on this issue.
I will start the process of getting approval for this. To begin, I need to know which version of Jsch has the fix. Please let me know when a version with the fix is available. Also, instead of getting approval for the Platform, I am going to investigate getting approval to put Jsch into the Orbit project. Orbit is the newly created Eclipse project for third party content. This will give other Eclipse projects access to Jsch as well.
(In reply to comment #19) > I will start the process of getting approval for this. To begin, I need to know > which version of Jsch has the fix. Please let me know when a version with the > fix is available. I have been preparing for the next release. This release has included some new functionality and I need to continue some testing before its release. Anyway, I'll be able to release it in a few days. > Also, instead of getting approval for the Platform, I am > going to investigate getting approval to put Jsch into the Orbit project. Orbit > is the newly created Eclipse project for third party content. This will give > other Eclipse projects access to Jsch as well. According to Orbit faq[1], jsch has been managed in Orbit already, but from my understandig[2], I guess that the approval for including updated jsch verion into the Platform must be required. [1] http://wiki.eclipse.org/index.php/Orbit_Faq#Which_libraries_are_managed_in_Orbit [2] http://wiki.eclipse.org/index.php/Orbit_Faq#Does_Orbit_replace_or_affect_the_Eclipse_Foundation_legal_process.3F
*** Bug 169435 has been marked as a duplicate of this bug. ***
Yamanaka, I would like to get the Eclipse IP process started for this but I can't find the release on the JCraft site (i.e. I assume the release I need will be 0.1.31). Will this be available soon? Also, the Contribution Questionnaire asks for the approximate number of lines of code. Can you give me that number?
(In reply to comment #20) > I have been preparing for the next release. This release has included some > new functionality and I need to continue some testing before its release. > Anyway, I'll be able to release it in a few days. FYI, I have released jsch 0.1.31. #Sorry for my delay, I had received some bug reports from users #after comment #20.
Oops, I had missed to check comment #22.... (In reply to comment #22) > Also, the Contribution > Questionnaire asks for the approximate number of lines of code. Can you give me > that number? The "wc" command says as folllows about jsch-0.1.31 source code, $ wc `find jsch-0.1.31/src/com/jcraft/jsch -name "*java"`|tail -1 16240 50127 523132 total
I have submitted the contribution questionnaire for this. Here are the resulting IPZilla links: https://dev.eclipse.org/ipzilla/show_bug.cgi?id=1152 https://dev.eclipse.org/ipzilla/show_bug.cgi?id=1153
Moving to M6 since we need to wait for the results of the contribution submission and that will probably not come back in time for M5.
I have done some asking around and found out about the following post: http://dev.eclipse.org/mhonarc/lists/eclipse.org-planning-council/msg00310.html It sounds like it would be helpful if the projects that require an upgraded Jsch make this requirement known to the emo in order to ensure that the contribution submission be given an appropriate priority for 3.3 (Europa).
Is it possible to estimate when we will be allowed to upgrade it? I have been really worried about the problems like bug 139739, which was found in the critical timing. If possible, I hope somebody try the latest version of jsch, which is available at the Eclipse Plug-in Update site, http://eclipse.jcraft.com/ Of course, I have tried the latest version by myself whenever it is released and I have not found the problem yet, but my testing must not be enough. Note: Jar files at that site have been digitally signed, and Eclipse SDK 3.3M4, 3.3M5 can not install them due to bug 176357 .
I've been using jsch-0.1.31 for about a month now without problems, and as far as I know, Michael V is also using 0.1.31 for internal testing. We have both compiled 0.1.31 ourselves for testing. Note that the version scheduled for Eclipse 3.3 is jsch-0.1.31 whereas on your update site, you ship 0.1.32. Since we cannot officially ship 0.1.31 from Eclipse.org before legal review is complete, it would be great if you could also serve 0.1.31 from your update site, such that more users can try it out and test -- particularly with features like proxies that we cannot easily test.
(In reply to comment #29) > it would be great if you could > also serve 0.1.31 from your update site, such that more users can try it out > and test -- particularly with features like proxies that we cannot easily test. Thank you for the suggestion. The older versions including 0.1.31 have been also provided at that site, but users may miss to find it becuase "Show the latest version of a feature only" has been checked in the Update plug-in by the default. So, from the point of view for testing Eclipse SDK 3.3, should we delete the version 0.1.32 from that site to push 0.1.31 to Eclipse 3.3 testers?
Ah, you are right. I think it is sufficient to give clear instructions on this bug report. Instructions to install jsch-0.1.31 into Eclipse 3.3M6 are: WITH Update Manager: -------------------- Help > Software Udpates > Find and Install... Search for New Features to Install, Next New Remote Site: Name="JCraft", URL="http://eclipse.jcraft.com/", OK Select the new site, Finish Disable "Show the latest version of a feature only" Expand "JSch Plug-in", select "JSch Plug-in 0.1.31", Next Accept License, Next Keep standard location, Next Install WITHOUT Update Manager: ----------------------- Download http://eclipse.jcraft.com/plugins/com.jcraft.jsch_0.1.31.jar And place it into your Eclipse/plugins folder Thanks for making this available. I encourage everyone interested in CVS-SSH or plain SSH to upgrade to Jsch-0.1.31 as soon as possible, so we find potential issues before we need to freeze that version due to legal review deadline. YMNK: The feature update license text is a bit strange: "The Eclipse Foundation makes available..." - I thought that JCraft, Inc makes available? Also, when I go to Help > About in Eclipse, select Jsch-0.1.31 and choose "Legal Info", I see something referring to Jsch-0.1.28. But I guess that will need to be sorted out at Eclipse.org after EMO review is complete.
(In reply to comment #31) > YMNK: The feature update license text is a bit strange: "The Eclipse Foundation > makes available..." - I thought that JCraft, Inc makes available? Also, when I > go to Help > About in Eclipse, select Jsch-0.1.31 and choose "Legal Info", I > see something referring to Jsch-0.1.28. But I guess that will need to be sorted > out at Eclipse.org after EMO review is complete. You are right. Those texts are not reasonable. I have modified descriptions included jsch jars at http://eclipse.jcraft.com/ Thank you for suggestions. By the way,... > go to Help > About in Eclipse, select Jsch-0.1.31 and choose "Legal Info", I > see something referring to Jsch-0.1.28. In my case, after restarting Eclipse SDK3.3M6, "Legal Info" for jsch-0.1.31 will correctly refer to "about.html" included in "com.jcraft.jsch_0.1.31.jar", but I have found that "Legal Info" for jsch-0.1.28 will also refer to "about.html" in "com.jcraft.jsch_0.1.31.jar". I think this is a bug. And also, I have found one more bug. Help > Software Updates > Manage Configurations on Eclipse SDK 3.3M6 will throw the following exception, java.util.MissingResourceException: java.util.MissingResourceException: Can't find resource for bundle com.ibm.icu.impl.ICUResourceBundleImpl$ResourceTable, key line at com.ibm.icu.text.BreakIteratorFactory.createBreakInstance(BreakIteratorFactory.java:129) at com.ibm.icu.text.BreakIteratorFactory.createBreakIterator(BreakIteratorFactory.java:68) ..... If it is not a known bug, there should be a Bugzilla entry for it.
(In reply to comment #32) > but I have found that "Legal Info" for jsch-0.1.28 will also refer to > "about.html" in "com.jcraft.jsch_0.1.31.jar". I think this is a bug. > If it is not a known bug, there should be a Bugzilla entry for it. Did you file a bug for these two?
(In reply to comment #33) > (In reply to comment #32) > > but I have found that "Legal Info" for jsch-0.1.28 will also refer to > > "about.html" in "com.jcraft.jsch_0.1.31.jar". I think this is a bug. > > > > If it is not a known bug, there should be a Bugzilla entry for it. > > Did you file a bug for these two? As for the second problem, I have filed it as bug 180871, but I have not yet for the first one, because I have not understood yet what is the reason; is it general problem or only specific to jsch?
I have found that this problem does not occur on 3.3M4, but 3.3M5 and 3.3M6 have it. And also, I have found that I can not open 'plugin.xml' file on 3.3M6 due to similar icu4j error. I guess that the problem has come from org.eclipse.ui.forms and almost of all plug-ins which depend on org.eclipse.ui.forms will not work on 3.3M6. It is nightmare. I have checked the source code of org.eclipse.ui.forms and, from my understanding, this problem must depend on the locale. In the method 'org.eclipse.ui.internal.forms.widgets.TextSegment.computeTextFragments' has defined as follows, private void computeTextFragments(GC gc) { if (textFragments != null) return; ArrayList list = new ArrayList(); BreakIterator wb = BreakIterator.getLineInstance(); wb.setText(getText()); According to the stack-trace, the exception has been thrown from 'BreakIterator.getLineInstance()' and it has defined as follows, public static BreakIterator getLineInstance(){ return getLineInstance(ULocale.getDefault()); } I'm living in Japan and the value 'ULocale.getDefault()' must be different from US environment.
(In reply to comment #35) > I have found that this problem does not occur on 3.3M4, but 3.3M5 and 3.3M6 > have it. ... Please ignore this comment. I had indented to post it to bug 180871. I apologize my carelessness.
Still waiting for approval but that won;t happen in time for M7.
0.1.31 is now in the latest integration builds. There's still a few things that need to happen before I can close the bug but for all intents and purposes, it is fixed.
I have conformed that 0.1.31 is in the latest RC2 candidate build.
Verified in I20070525-0010
I spoke to soon. It looks like the Update manager doesn't like how the JAR was signed (see bug 189000). We'll need to pull the JAR for RC2 and address the signing problem for RC3.
Created attachment 69074 [details] This plugin includes updated about.html and is singed by JCraft,Inc. This is a response to the following message from Michael, > I don't think that having the JSch JAR itself unsigned is a big deal since > only the signing on the Runtime JAR is verified when Eclipse is launched. > However, if you prefer that the JAR be signed, could you please add the > new about.html, resign the JAR and attach it to bug 165432. I also think that unsigned jar is not a big deal, but users may worry about it. By the way, I have one concern about including attached jar file in Eclipse SDK. Our certificate will expire at July 2008 and the problem may appear in the future. What happens if Eclipse finds the expired jar file? Will Eclipse reject to run?
It was never a problem with Eclipse in general (i.e. Eclipse ran fine). The problem was that the Update Manager crashed when it encountered a JAR with an invalid signature. I suspect that the handling of a JAR with an expired signature would be a different code path (although I suspect it is a code path that has been equally poorly tested). I will check with the PMC to determine how they would like to proceed. My preference would be to use the signed JAR. On a side note, is the expiration of the signature embedded in the signature itself or is this just a problem if JCraft does not renew it's signature?
Can't we just explode the Jar and sign it with the Eclipse certificate? That way we'd verify that it's the authentic version distributed by Eclipse.org. Jeff McAffer suggested such an approach at the Orbit newsgroup a while ago.
I've talked to Jeff and it turns out I was confusing "conditioning of a JAR" and "signing of a JAR". The statement is that we do not "condition" (i.e. PACK, etc.) JARs that we do not build ourselves. That does not mean we won't sign them but there is some uncertainty as to whether the current build infrastructure can support signing without conditioning. I will follow up with Kim to determine whether signing without conditioning is possible.
I'm wondering how we could ever put anything on the Europa update site without conditioning it? The Europa site is packed by definition, as far as I know. Though it might not be an issue for Jsch, because it is part of the Platform runtime binary so it won't ever be retrieved from an update site, right?
Yes, this it is possible to do this. The change to exclude prebuilt bundles from packing and signing is in bug 187024 which I hope to release for RC3.
(In reply to comment #43) > On a side note, is the expiration of the signature embedded in the signature > itself or is this just a problem if JCraft does not renew it's signature? Our certificate was issued by Thawte[1] and it will be expired at July 2008. You can check such an information with following command, jarsigner -verify -verbose -certs com.jcraft.jsch_0.1.31.jar # FYI, it seems that Eclipse.Org's certificate will expire at April 2009. And, of course, we will renew our certificate before its expiration for our customers. In fact, we had already renewed it 3 times. [1] http://www.thawte.com/
JSch 0.1.31 is in the latest integration build. For those that have been following the discussion, it will be signed by Eclipse.
