Summary: | ssh: support reading encrypted new-style OpenSSH private keys, especially encrypted ed25519 keys | ||
---|---|---|---|
Product: | [Technology] JGit | Reporter: | Thomas Wolf <twolf> |
Component: | JGit | Assignee: | Project Inbox <jgit.core-inbox> |
Status: | RESOLVED FIXED | QA Contact: | |
Severity: | enhancement | ||
Priority: | P3 | CC: | matthias.sohn |
Version: | 5.2 | Keywords: | noteworthy |
Target Milestone: | 5.4 | ||
Hardware: | All | ||
OS: | All | ||
See Also: |
https://git.eclipse.org/r/141356 https://git.eclipse.org/c/jgit/jgit.git/commit/?id=c33d2bfb9f5d0f407bb736fafe2fa8ff93309e93 |
||
Whiteboard: | |||
Bug Depends on: | 541272, 541425 | ||
Bug Blocks: | 518745 |
Description
Thomas Wolf
2018-11-29 10:01:38 EST
The sshj version apparently comes from a fork of Damien Miller's jBCrypt at https://github.com/kruton/jbcrypt/commit/37a5a774565b7eaf9e58f0fadba1291a3a06649f . The changes were never merged back into Damien's version; see https://github.com/kruton/jbcrypt/issues/1 . Kruton (Kenny Root) has published this as maven artifact org.connectbot.jbcrypt:jbcrypt:1.0.0. See https://mvnrepository.com/artifact/org.connectbot.jbcrypt/jbcrypt/1.0.0 . The license has been left unchanged (still ISC). So one way forward here might be to use org.connectbot.jbcrypt. It contains the required implementation of bcrypt_pbkdf. Now before I create a pull request for upstream Apache MINA sshd implementing this based on this org.connectbot.jbcrypt artifact it would be good if we already knew if we could have that in Orbit. So we'd need a CQ for org.connectbot.jbcrypt:jbcrypt:1.0.0. My analysis of the source repo at https://github.com/kruton/jbcrypt makes me think that this is indeed just the ISC-licensed original from Damien Miller from https://github.com/djmdjm/jBCrypt, with original input done by Kenny Root at https://github.com/kruton/jbcrypt/commit/37a5a774565b7eaf9e58f0fadba1291a3a06649f and still ISC licensed. I have verified that using this library we can build an OpenSSH key file parser that can successfully read and decrypt encoded OpenSSH ed25519 keys. But doing this in either JGit or in upstream Apache MINA sshd is moot unless we get this into Orbit. I think your proposal to contribute a PR for mina SSHD using org.connectbot.jbcrypt:jbcrypt:1.0.0 sounds good, I'd aim at including the source code into mina SSHD if they agree to avoid adding another library containing only a single implementation class. Before we do this ask the legal team if we then can consume this implementation from mina SSHD regarding its license and provenance. Can you create a CQ to get advise from the legal team on this topic? (In reply to Matthias Sohn from comment #2) > I think your proposal to contribute a PR for mina SSHD using > org.connectbot.jbcrypt:jbcrypt:1.0.0 sounds good, I'd aim at including the > source code into mina SSHD if they agree to avoid adding another library > containing only a single implementation class. Before we do this ask the > legal team if we then can consume this implementation from mina SSHD > regarding its license and provenance. > > Can you create a CQ to get advise from the legal team on this topic? I can try. As for copying the source of this BCrypt directly into Apache MINA sshd: don't know. We would have to check with the Apache people first what they would prefer. I'll ask Lyor in SSHD-708.[1] [1] https://issues.apache.org/jira/browse/SSHD-708 (In reply to Thomas Wolf from comment #3) > (In reply to Matthias Sohn from comment #2) > > I think your proposal to contribute a PR for mina SSHD using > > org.connectbot.jbcrypt:jbcrypt:1.0.0 sounds good, I'd aim at including the > > source code into mina SSHD if they agree to avoid adding another library > > containing only a single implementation class. Before we do this ask the > > legal team if we then can consume this implementation from mina SSHD > > regarding its license and provenance. > > > > Can you create a CQ to get advise from the legal team on this topic? > > I can try. As for copying the source of this BCrypt directly into Apache > MINA sshd: don't know. We would have to check with the Apache people first > what they would prefer. I'll ask Lyor in SSHD-708.[1] > > [1] https://issues.apache.org/jira/browse/SSHD-708 if they don't like this we will live with another tiny dependency I followed the instructions on the Legal Process poster[1] which says to contact the legal team by e-mail, and explained the issue. Sharon looked at it and doesn't see any problem with including the Bcrypt source directly in upstream Apache MINA sshd. So I created the pull request at [2]. We'll have to remember when we create a CQ for using an Apache MINA sshd version that does include this PR or that otherwise includes this Bcrypt source that we (Sharon and I) already discussed this by e-mail. I guess that Apache MINA sshd version will be 2.2.0. I'll check with Lyor when that is planned to be released; hopefully in time for Egit 5.3.0. [1] https://www.eclipse.org/legal/EclipseLegalProcessPoster.pdf [2] https://github.com/apache/mina-sshd/pull/81 (In reply to Thomas Wolf from comment #5) > So I created the pull request at https://github.com/apache/mina-sshd/pull/81 This is in upstream Apache MINA sshd now. It got somewhat transmogrified in the process, but the functionality is there, and BCrypt.java is included. It's commits 5bbd2840, 9d00a1bc, and 969f3cab in Apache MINA sshd.[1] [1] https://github.com/apache/mina-sshd/commits/master New Gerrit change created: https://git.eclipse.org/r/141356 Gerrit change https://git.eclipse.org/r/141356 was merged to [master]. Commit: http://git.eclipse.org/c/jgit/jgit.git/commit/?id=c33d2bfb9f5d0f407bb736fafe2fa8ff93309e93 |