 Well, looks like it's recording. So we've got get credentials binding project July 28th, 7.30 a.m. India Standard Time. So the hardship we were talking about before he joined, we were just kind of kicking off with this topic of private key support and things that we should check. You had mentioned something in the Gitter about an RSA RSA encrypted keys that you're having problems with with the library or anything. Can you do you want to kick off the discussion on with some detail there? Yeah, so I think that the SSD library is not supporting the RSA encrypted key, which is an open SSH format. I mean, any other key, such as is the CDSA 19, which is encrypted and even in open SSH format is, you know, performing the task very well, but the RSA encrypted is not. I think that the issue is from the SSJ library rather than in the binding code. Okay, but have you tried debugging and Yeah, yeah, I tried to debug. Well, I have not gone through the code of the SSJ library that much. So No, that's okay. Because I can see from there from the lead me they say in the supported I can see RSA. The signature SSH dash RSA. So, Rishabh, could you could you provide a link that we could drop into the document on the Because it may be that we're just talking to different types. Also, I just discovered tomorrow that the VKCS8 encrypted Encoding is not supported that they're not supported in the boundary castle plugin API. Like it's showing an error when I was performing tests. So I think I need to either open an issue or make a PR regarding that. We do have a VKCS8 format private keys open SSH. Any, it can be in open SSH. But I've I've never seen open SSH mention any support for PKCS8 keys. I would assume that if open SSH doesn't support it, we don't need to. Yeah, and I thought that the VKCS8 format is useful certificates. I mean, storing certificate changes sort of format which is used to storing to mediate and Client root certificates. That's what I thought. So harsher than I think what you're hearing is that we're not worried about PKCS8 format as far as I can tell because Not a concern. Because open SSH doesn't support it. And so PKCS8 format unless you've unless you found some way to use PKCS8 to to communicate with open SSH I've never I've never seen it mentioned in any documentation. So I will look into that more because I'm just discovered the issue this yesterday. But if Mark is saying as Mark is saying that open SSH is not supporting it then why would we need to worry about it because if a user is not able to create a key with it then SSH keep it then why would it be an issue for us. Okay, now I'm seeing that. Okay, so open SSH takes a minus M argument for key format and does accept PKCS8 as a public key or private key. So apparently it will accept PKCS8 so we may have to just declare pay not supported. I mean. Yeah, I should go on. Yeah, code is available in the bouncy gas labia for the PKCS8 but it is not performing as expected you know you can say it is showing an error. I think that's an that's a bug for that. I mean the code is there in the plugin but it's showing an error. So there's a bug and it is support it supports when there is an error bug is is not support is available for that in the plugin. So what I was was I was trying to say is that when we're talking about releasing this SSH private key as a binding for the plugin. Should we not focus on encryptions and formats which we know for sure are going to be encountered by 90 or let's see 80% of the user if that is something we can figure out. And if we know that then we should focus on that and first release the plugin with that those many encryption algorithms and we can say that we at this moment we don't support. Let's say PKCS8 or any other algorithm which is a bit outdated. I mean is that a viable strategy we could use Mark just in an internship for me if we support RS if we support the keys that a typical Linux system will generate. I think we're 90% of the way there and a typical when I say typical Linux system I mean a typical Linux system using SSH dash key gen. Yeah, I agree I think kind of try and solve the the broad case and then you know if we need to create follow g-ish use or something like that or just declare them as you know. What's what is supported we could even declare in the doc and then if it's unsupported and someone wants to take great an issue like that seems like an option to generally agree. I mean, there is there is a bug in the bouncy gasoline yes if that in in one of the libraries will be using if that is the case that I think that creates a dependency for blocks him right and then he would have to create a PR there and I'm not sure how their development cycle works. Yeah. You've opened up a discussion with them right fashion of pkcs a bug what you're saying. Oh no I just discovered it yesterday so I have a little bit more on that and then I will. Will I think open any sure I should I should I look into the code and solve the is all the sure should I just open any super. My advice will be first you should have you gone through the unit tests so actually I was trying to find the unit test I was not able to write down but I remember that in the unit test they've tested a lot of algorithms. These encryption algorithms and they've shown how to decrypt them so were you able to see an example of them decrypting a pkcs a format. Because I vaguely remember that I saw it but I just I'm not able to find it right now. So what I'm trying to say is just make sure that it is a bug from their side and not because maybe we are giving a wrong input or there's something that they something different than they expected something like that. I guess I'd even maybe go a different way like we could just kind of mark this as you know it may not work for now and just kind of like keep moving forward with the ones that are the standard ones just an interest of time and moving forward. Yeah, I'm, I'm agreed with Justin that if I think if we support RSA and ED 25519 we've probably already supported over 95% of the use cases, just with those two, those two algorithms and passphrase protected or not passphrase protected. Now, harsher, the thing I didn't understand from your, your Gitter comment was, I think you said that RSA is not working for you with when using open SSH format did I understand that correctly. Yeah. Okay, so so that's that would be a red hot one because RSA is the default used on many of the and I think maybe even most SSH implementations. Okay, so if the private key file is encrypted by the RSA format and we're not able to decrypt it right. The SSJ library is decrypting the file and return it in a PKCS format in form of byte array. And I'm using the bouncy castle if you had to convert it into a new format you can support so that it can be used for the authentication purpose because by that is not that much supported. I mean it was showing another because showing an issue that needs to secure the key is not that much secure if you are using byte array because the PEM format uses ES4 base 64 format for the transferring of the key that is more useful and more reliable rather than byte array. So. But I didn't I did not understand what is your issue your issue is that you're not able to use that byte array and then is there an issue with the transmission to the PEM format from PKCS it or is there an issue in decrypting that key. The issue is I'm not able to perform the authentication operation. Well, all others are being performed but the only thing is I'm not able to form the authentication operation it says that the other in the crypto. Okay, so. Okay, the library is not okay okay. So there is some issue with the decrypting key that is what it is. But I guess, are you able to take the byte array and put it down on the file system and see if that works without going taking that extra step. Yeah, I did that. Okay, and that that works right. Or no. No. That doesn't work okay. And so the, you know, the assesses banding is highly dependent on library so it is more slimming for open SSG is 100% dependent on the SSG lab and for other formats it's dependent on the BOMC castle plug in library API. So the bind the asset binding code that I am providing is not much. You know, playing much role that only the bindings are. So, yeah. So as I understand it. If, let's say you're RSA by fastest predict the first it will be. I think it would be encrypted by a cypher like he is something in that he is 256 and then that is decrypted and the second step would be to give you that RSA format format key into a by data right. And you're saying that that is provided to you in a PCC is a format. Yeah, when you're talking about RSA. Yeah, you have opened an issue in SSG. Oh yeah. I mean, if I'm wrong, they could even point me to the direction I am. And then that's great stuff. I just wanted to know, like, if you mean the issue is really in SSG library. So are we still using that, or should we, you know, look for the alternatives. It depends that we have an alternative, which would work for all of the cases. So, so RSE are for me RSA key support is crucial. Without our without RSE, we could, we could ship without it, I guess, but the pain factor would be enormous because most users generate our SA keys by default. So if we truly can't make it work with SSHJ I think we have to look for something else to that would support it. Yeah. Or provide a fix back to SSHJ that allows it to be supported that would be fine as well. But I'm just astonished if it's not supported because I would expect their consumers see it as the most common encryption algorithm. Yeah, and I guess, Harsha, I think you said that you just recently discovered this and maybe some more debugging can go into whether this, you know, there's just something else that needs to be done or something like that. Is that my understanding correct. And the RSA issue. Yeah, yeah. I have debug that on that but I could not, you know, could come to I still think that the issue is in SSJ lab. So, because the binding code is not that much playing role in the in decrypting the key and you know, giving the. In the byte array is just just giving the instinct form and and then out putting the key in basics to perform at even using the policy classes. Yeah. The reason that we're not consuming key, maybe decrypted byte array. So you're saying, first of all, I just don't understand that I'm seeing your code here which you've written in the issue that you get the private key out of the SSHK1 key file and then you get the encoded byte array. Okay, this encoded byte array you, then I would as you decoded base 64, right. This would be a base 64 encoded byte. Yeah. And you're saying that this isn't because he is a format because you, you check the get format from the get format function that this was PCCSA. And then, since this is PCCSA, as far as I understand you are working with PEM format files right so you would be doing that conversion as well. Yeah. So if you have, have you tried using the PCCSA file like converting that into a PCCSA file and then using that to establish a SSHK1. Or are you using the PEM after converting whatever logic you've created and then using the PEM to do that. I tried to byte array but it doesn't work and it didn't work so I'm now using the bouncy class label for that converting to PEM. I mean, that's also not working as well. I mean I tried both the cases. And have you seen in SSJ, is there an example, could you find a test case or something like that. I'm not sure how to do this. In the same example. Because I can, I cannot find that. I mean I have the SSJ. Yeah, that's a good question, Rashab. I think I'm, so I'm sorry I'm looking at the SSJ repo. And it looks like they have integration tests with RSA keys. Yeah, that's that's what I was seeing as well. So we might be able to use that. I mean, this is a PR that came in that actually looks like it recently added the some other keys. Or that's what it says anyways comprehensive support for public key of those certificates. So with certificates, that's slightly different I guess. So when we're talking about RSA, so then I was reading about open SSH is new format, which they implemented. So if I don't provide an encryption algorithm when I'm using SSH key gen, Mark, you were saying that the keys would be RSA keys generated the private key. So I think that's what I had experienced previously let me double check the man page just to be sure. Okay, because wouldn't open SSH default to the new open SSH format now. The encryption and I believe it's open SSH hyphen. But it depends on what system you're on and what you have. Oh, yeah, I mean that's a good point. But yeah, I think some older systems are probably going to have like older versions. Yeah, certainly the I would expect the version of open SSH that's installed on Centos seven to be dramatically different than the version that is installed on open BSD 69. Because one of those was created what Centos seven's original release is probably seven or eight years ago now, and open BSD 69 released in May of this year. So, so there that's that's why the operating system variants thing there is is on the test ideas is because those different versions of SSH may generate different different things that users will paste into the form. So I just tried SSH key gen and it's generating a public and private RSA key. So I just tried the same thing on open BSD 69 and it is offering to when I run SSH SSH key gen with no arguments it offers to store it in dot SSH slash ID underscore RSA. So I think it's still defaulting to generate an RSA key. So that means that this since the RSA key would not be the new SSH format then I think bouncing as it would be able to do it right because RSA is relatively open SSH was new and fault and they don't support the direction of past phase protected private keys when they're in open SSH format but RSA, I think will be supported right. Not even SSJ bouncing. Yeah, so I'm afraid I don't know which libraries support which, which formats and that's where I think harsh it's investigation is the is the harsh it's implementation is the real answer. If it's not working for him, then it probably won't work for the users. I've seen that I clearly remember that the bouncy castle Java repository that contains test where they show the show various formats how to decrypt them. Have you seen some of the examples there, do you see, could you find examples how they're doing it when it comes to RSA. RSA encrypted using bouncy castle encrypted without encryption. I would expect both. So the format will be different. Yeah, yeah, I think that's a good exercise. I think that's the easiest way to find it. And the correct way to do it as well. And maybe, maybe it's that we end up using bouncy castle directly instead of SSHJ. If you can because you'll have the bouncy cap castle API is already imported. So maybe it's that we use SSJ for the 25519 and bouncy castle for RSA. So if you show up, I think you're kind of also saying that maybe that'll unlock using SSJ to use RSA. No, I'm just saying, I would say, if, if we don't have to the issue where we have to switch from bouncy castle to SSJ started from point where open SSH private keeping their format that that is where bouncy castle is supporting us. But since RSA is when we're creating keys which are in RSA that should be supported by it is supported by bouncy castle. Open SSH they said that it. So I'm trying I'm assuming that we can find some place where they've done it. Decrypted RSA in bouncy castle and not sure why SSJ is not supporting it. Any other thoughts on that one or any other concerns that we need to talk about besides the big one. I'm trying to catch myself up to speed just reading the SSH key gen man page and I think I've got more, more things we need to put in the formats in the key, or maybe less things to put in the key formats. I have three key formats that are listed here I'm going to update that just because I was being imprecise it looks like they've got a thing called RFC 4716 slash SSH to public. Okay, that one we've got Pam, and then pkcs eight. So, those three seem to be the key formats that it can that SSH key gen can both import and export, and can change the passphrase on them. So, so for me I think Justin to your question. I've just got, I need to do more, I didn't need to test the code that harsh it has submitted as part of the poll request, and see, see confirm that doesn't support RSA keys that I've generated. But if it does, which kind of RSA keys does it not support that sort of thing. Yeah, that makes sense. Do we have any other topics that we should cover now. I think this is our big one right now. Yeah, and I apologize my capacity to do testing right now is pretty limited the next chance that I'll be able to attack this is probably this weekend. So, were there any other topics that you wanted to cover in today. Well, I'm pretty occupied by this. There's not much to go over. Only the, the two things were there only the SSJ regarding this and then the bouncy castle, and we have discussed on that. Yeah, so I guess from here maybe we, I guess are we maybe done for today and then offline we kind of like people can take a poke at the RSA stuff see what we find out. I'm happy to continue talking about this to I'm not trying to close down the subject early. I just, I just went into a smart like off topic. So mark the issue that I encountered when the, you know, are looking at the fat version was 4.19. So it was all when you change it to 4.21 so tell me what was causing that. Unfortunately, I don't have any guess at all. What was causing it because that was I couldn't, I couldn't duplicate it and and I think what you're saying is now you no longer see it either. Interesting. Yeah, so I've, I don't, I don't know what what would have caused that that was. I mean I guess it could have been something corrupted or mangled in your maven repository cash that's on your in your dot m2 directory. It could be some other surprise I, I apologize harsh it but I just don't know that that was completely perplexing to me. And it was not, you know, reproducible by by you. It was not. No. I have to, I have to system so on both the system before showing the other so I was sure that it was. Interesting and, and yet. Okay, so then if it was showing it on both systems and it certainly should not have been anything related to local corruption on one system and not another. That that's really strange and but are are either of the systems still showing the problem. No after you know changing to 4.21 then it was gone. Interesting. If you, if you switch back to 4.20 does the issue return. I think it will. So that may that yet that might indicate some real problem in the parent parent version 4.20 4.20 but I have not seen any mention of that kind of problem. I don't know where in the Jenkins mailing lists. Let me see if let me see if I can read the releases to see if there's some hint in the release notes. Okay, so 4.21 was released to remove the spot bugs upgrade to 4.3.0. So that to me doesn't seem like doesn't seem like it would be likely to do any damage to your ability to compile. And, oh no 4.20 though requires Maven 3.8.1. What version of Maven are you currently running. I've dated about first for that. I was learning 3.6.1. So it shouldn't as I updated to 3.8.1 or zero. I think 8.1. Okay good so you're running the correct version and so that's not the problem. Okay so unfortunately I don't have have any guess what could be going wrong and and just would suggest hey let's continue and if it if the issue appears again we'll ask on the developer list to see if others can give us any help. Yeah, I've had. Yeah, the two systems thing is interesting. I've had similar local Maven cache sad times before that sometimes magically fix themselves after clean but yeah with two systems. Interesting. Hopefully we're happy now. Yeah. Okay then I've I've exhausted my topics. So you're just generating those keys when you're testing so you're just you're not providing a specific algorithm right you're just generating then using SSS key gen. Yeah. No no I'm providing. Well it depends on which for which algorithm I want to use and for my. Yeah of course and you're giving RSA as the algorithm. And the private key when you open it, you're seeing open SSH private key or you're saying RSA private key. Open SSH. Yeah so. So then the problem then I was saying that RSA should be supported and we should definitely find a solution for bouncing acid problem. So this is not the RSA algorithm right this would be open SSH. Yeah we would need to look at SSJ because SSJ is able to decrypt open SSH the newer format with different algorithms. You've tried with different right but with RSA you're saying it's not. I'll try doing it as well. No harsh it you'll continue your investigation of key support and we'll we'll talk further on Friday if I've had a chance to submit or active testing. We can look at the results and otherwise it may be next Monday before or next Tuesday or Wednesday your time before I'm ready to talk about test results. I will be submitting some you know tests for that. Oh you can go through that. Great. Excellent. Yeah but yeah I also like our shops idea about looking to see if there's any, if you can find any unit tests for bouncy castle anywhere really maybe there are even another repositories for RSA. Yeah, and I definitely see RSA based tests in the SSHJ repository. If you look at the data files, they don't look. They look like they are one of the variants of of files that are understood by open SSH, but I haven't haven't proven I haven't confirmed that by interactive test. Yeah, hopefully it's just like a little weird thing that you just need to flip a something somewhere. Yeah. Those are the most annoying ones. All right, well I guess we have nothing else we can close her up. Thanks everybody. Thanks everybody. Bye. Have a good one. Take care.