gitToolName
to be an optional argument and to use default if an invalid value is provided. See MarkEWaite/git-plugin@4f8e4d8
doFillGitToolItems
in GitSCM provides us with names of the git tools available for the user to choose from. Could we use the same logic but return a gitTool instance instead and check it's type and decide on whether to proceed authentication or not, will it still require resolveGitTool
method usage. When using resolveGitTool
method we check for a node specific gitTool but if the user is the one selecting the gitTool then would it be too assumptious to say that they must have configured it on the agents as well.
Thanks @arpoch . All my functionality tests are passing. I pushed one change to remove a spurious warning from the user interface. Would be nice if you could merge the master branch into that development branch so that I can use an incremental build in my test setup.
I think we're very near to releasing the username / password binding. I need to investigate a behavior related to tool installation frequency on Windows agents. I don't know if the behavior is new in the current development or is a behavior that we've had since last year. I don't think it is related in any way to your changes, but I'm hesitant to merge your changes and release the plugin until I understand when that behavior was introduced
@rishabhBudhouliya , I was using the sshj library to accomplish the task for ssh authentication for private keys in openssh format, sadly I couldn't achieve the desired results , so I am using the
maverick-synergy which works great, I am attaching the code below to show what the I have been working with
public static void main(String[] args) throws IOException, InvalidPassphraseException {
File f = new File("auth.key");
String s;
//TODO METHOD-1
OpenSSHKeyV1KeyFile o = new OpenSSHKeyV1KeyFile();
char[] arr = new char['passphase'];
// o.init(ECDSA_Joined,"",new Pass(arr));
// PrivateKey p = o.getPrivate();
// String format = p.getFormat();
// byte[] c = p.getEncoded();
// PKCS8EncodedKeySpec pk = new PKCS8EncodedKeySpec(c);
//TODO METHOD-2
// OpenSSHKeyV1KeyFile o = new OpenSSHKeyV1KeyFile();
// o.init(UNENCRYPTED_KEY,"");
// OpenSSHPrivateKeySpec kp = new OpenSSHPrivateKeySpec(o.getPrivate().getEncoded());
//TODO METHOD-3
// byte[] dec = Base64.decode(RSA_Joined);
// AsymmetricKeyParameter p = OpenSSHPrivateKeyUtil.parsePrivateKeyBlob(dec);
SshKeyPair key = SshKeyUtils.getPrivateKey(en_RSA,"Jenkins");
s = SshKeyUtils.getFormattedKey(key,"");
// String s = Base64.toBase64String(new OpenSSHPrivateKeyFile(key.getPrivateKey().getJCEPrivateKey().getEncoded()).getFormattedKey());
//TODO BASE64-ENCODED
FileWriter fo = new FileWriter(f);
// s =Base64.toBase64String(c);
fo.write(s);
fo.close();
//TODO PEM ENCODED
// PemObject po = new PemObject("",c);
// PemWriter pw = new PemWriter(new OutputStreamWriter(new FileOutputStream(f)));
// pw.writeObject(po);
// pw.close();
//TODO notes[SPECIFY PATH OF SSH IN WINDOWS PROPERLY]
}
static class Pass implements PasswordFinder {
char[] p;
Pass(char[] passForKey){
this.p = passForKey;
}
@Override
public char[] reqPassword(Resource<?> resource) {
return p;
}
@Override
public boolean shouldRetry(Resource<?> resource) {
return false;
}
}
}
The problem that I faced with sshj and even with bouncycastle was, the decrypted key generated is altered and isn't matching with the public key . I know this shouldn't happen may I need to dig a bit more on that.
Also I am a bit concerned about the license of
maverick-synergy maybe @MarkEWait could shed some light on that?
I don't understand the problem of the decrypted key not matching with the public key
I think my poor choice of words might have caused some confusion, what I meant was when converting an openssh formatted private key to PEM or Base64 PKCS#8 encoded format, the private key generated when used to connect to the server(github.com) returns git@github.com: Permission denied (publickey).
which I think is caused due the rejection of this key because the key generated is not a valid or is being altered in the process of decryption or altered in the process while converting into a new File Format (PEM)[Higly likely] thus not forming an invalid keypair with the public key on the server.
getSSHExecutable
method 's scope is limited/package-private need to make it pulblic, specific to windows usecase.
java.lang.NoSuchMethodError: No such DSL method 'GitUsernamePassword' found among steps
it seems like the binding is not present, I encountered similar issue with the forked git-plugin as well, I have been working on this the whole day, I couldn't figure it out it, although when I checkout out to revision 2b5cfd1d0939a97f20c248d096f5ceeb7f76512f
in my forked-git-plugin the binding is working.$ git checkout master
$ git pull --all
$ git merge upstream/master
$ git push origin
a707434c10bdfedcd87e7c9ca2341f1182709de1
(upstream/master in my repository)$ mvn clean -Dtest=GitUsernamePasswordBindingTest test
origin/master
and upstream/master
in sync so that I can refer to 'master' in diff and have it match the upstream repository. I know others who are more rigorous and they don't bother keeping origin/master
in sync with upstream/master
, they just remember to diff against upstream/master
GitUsernamePassword
to gitUsernamePassword
with an extra symbol at the same location for GitUsernamePassword
. However, I haven't done the experiments to see the impact of changing from @Symbol("GitUsernamePassword")
to @Symbol(["gitUsernamePassword", "GitUsernamePassword"])