 All right, starting the recording here. Going to, oh, we're recording already. Great. Let's see, go to the meeting notes, share, should be all set here. Think if Hershet's trying to get his audio going still, maybe. Hi, all. There he is. That sounds like you had a great presentation today, Hershet. Nice. Yeah. So do you have any questions immediately for us? Mark's putting on some of his questions that he had also asked in the channel. I think maybe that's the same thing as you, too. I think we're ready to release the username, password, credential binding. Looks like Mark had done some testing. You had done some testing, and mostly just an impact reviews at this point. And now, I mean, I see myself three times. I don't know what advice this had me. I mean, every time I log out and log in there, I am added once more in the privacy print list. Yeah, I wonder if it's maybe hanging onto your connection. Yeah. And Justin, you could, I don't have admin permission. You could just drop the other two connections. Yeah, I can do that. Hershet, could you talk again real quick? Yeah, so I think I'm the first one. Or I mean, the mic is about. Yeah. So yeah. One more time. I just double check. I'm pretty sure I got the right one. Oh. Yeah, so good. All set. We're squared away. Does that turn out better for you on your side? Yeah. Great. Yeah, so Mark's teeing up a great question. Any objection to Verges's? With all 40 plus commits, personally, I have no objections. I'm all due to that. Anyone have any other thoughts? So Mark, will we be releasing the binding this week? Yeah, I was intending to release it tonight. Right now, basically, if we as a group say yes, we're ready to go, I think it's time to merge it, release it, and then you can base your private key implementation on a stable version instead of having to do all sorts of games with versions that haven't been merged yet. Does that work OK for you, Hershet? Yeah, both kinds. Yeah, I feel like I've been not as intensely focused on the code review as I have been on the interactive testing, but all my interactive testing has been quite satisfactory, so I don't see much reason to delay it. And yes, if we have objections to documentation or something like that, those are pretty easy things to fix. The functionality is there, and I feel like it's, as far as I can tell, it's very strong. Yeah, and I think my nitpick doesn't really even isn't visible on the UI. I'll check your screenshot. And I think we're all good there, so it's just more of a style and code question. I'm not concerned about merging it. I could also be told that I'm wrong, so I'm not feeling strongly about my comments there. A part of me was thinking, hey, should we do a blog post to introduce it? Because really, this is one of the top three most requested, most highly voted Jenkins enhancement requests. And so it may justify a blog post to say, hey, look, step one of this highly requested feature is here. Here are some ways you can use it. The documentation says that already, but a blog post is a way to make it even more visible, saying, look, this thing is ready. Go ahead. I'm certainly going to, when I release it, I'm going to tweet about it. And usually, for whatever reason, when I tweet about the Git plug-in, the tweets become very popular. Yeah, I think that'd be, I agree with you. If I recall correctly, we have maybe done some of that with Rishabh's project as well. We did. Yeah, that was exactly what we did with Rishabh's work last year, and it was very well received. And then that's just another good artifact for you to point at with the Google Summer of Code stuff, too. Does that kind of make sense for shit? Yeah. In the blog post, we have to explain the procedure of how to apply the binding, or do we have to give an overview of what we have achieved? So what I was thinking the blog post would be is tell the high-level story why this, why credentials binding is so useful and so important to first pipeline users and second, even to freestyle users. And the big compelling value that, hey, all sorts of things, and the evidence there for me is there are four or five enhancement requests that I closed as a result of doing this implementation, where people wanted this novel behavior, or that novel behavior, or this other one. And in each of those cases, credentials binding allows them to do that without us having to write code for it. Your work on credentials binding has enabled many different use cases. And for me, that's the story the blog post should tell, is, hey, this thing is really a significant addition to the functionality of Jenkins. And even better, it uses standard facilities that are already in credentials binding. So that makes it even better, because if they weren't using credentials binding before, now they learn, oh, I can use credentials binding for these other purposes as well. I don't understand why it says checks if not. Oh, I know why, because I just did build. So back to my earlier question, Harsha, any objections to you if I merge? Any objections from you if I merge? And Justin, any from you? Nope, let's do it. And Rishabh had already said yes. So I'm going to go ahead and do the merge. We'll accept that there are, Justin, your question on the logging improvement that Rishabh suggested is still certainly possible. That's not blocked by releasing again, or by doing a release formatting, not an issue. We know how to do that. OK, now there's one question here. Get client instance, he asks, why was that added to the contract? And so I don't understand that. I don't understand that question. Let me, well, Justin, could you open up the pull request? It's get plugin pull request 1104. Let's look at this one comment together. And Harsha, you can probably give us some clarification. Perfect. I believe you can see both my tabs, correct? Yes. Yeah, we see. Well, we see, yes, we see that one just fine. So looking at, yeah, I think it's the convert. Well, I'm looking at the conversation tab, conversation tab, I think. And if you look for the phrase contract to be implemented. Oh, Rishabh's here. Very good. OK. Hey, Rishabh. Hi, Justin. Hi, everyone. I'm so sorry for joining you. I don't know where it is. Wait a second. It's the wee hours of the morning for you. We're delighted that you're here. Even worse, you were awake only 12 hours ago as part of the presentation. So did I interrupt something? I'm sorry. We were just discussing, actually, your timing is perfect because we had just come to the agreement that we would go ahead and merge so that I could start the release process. And we may even have the release done by the time our meeting ends today. And but there was this one question you asked about why this is added to the contract to be implemented. Is that comment such that you feel like we need to, is this one we need to, because implementation contracts are permanent once released, tell us more about your question or harsh it if you feel like you can give an answer that'd be fine too. My question, yeah, my question is what I've asked that. Do we need that? Why do we need this flexibility? Is it is this portion of course something that depends on this conditioning? Some users logic, why would we want to add this flexibility? Because I saw the code, what it does. And I could not find a reason why we would not do it and provide it to the user. Our sense. So what this does is given a string that represents the get executable and a repository environment variables, it returns the get client instance. And it's used in the bind to set the get environment variables. So this is turning the get tool name into a get client instance that then is used for the environment variables. So is your question and why not make that a private method inside get username password binding instead? Or? No, as we're doing with this method called get to name, get to name, get CLI get to name. So what we're doing is that we're ensuring that we have a place our own logic is going to run. We're not placing the responsibility on the user to implement the logic to resolve the get to. Similarly, I was thinking that why do we need to place that responsibility to the user? When we know that this is going to be constant, it's not going to change this portion, this two lines of code to get the get instance from the get to name. Or is it something that is there a reason for adding it to the contract and making it implementable by users? That is just my question. Well, I think that the API that I provided in the interface, I mean, I have provided all the parameters that are required for the programmer to create a get client instance. So in my implementation, I'm not using the repository. So the method dot using that could be used to set a specific repository in which the get client instance will be available. So I'm not using that. So I think that could be used by another programmer based on his on their logic. So that's why I made a method overrided method instead of a default implementation. But default implementation can also be overwritten. But I think it's better for the programmer to have the choice of the implementation. As in my case, this implementation works fine. But I'm not sure how the other for the other programmers the implementation will look like. So I think that's a good idea. But the way we could find out how this is being implemented is that we could look at how the get plugin uses it for the major functionality it performs. Because I think that is the biggest consumer of getting a get client. So if we know that we can safely assume that this is 90 or 99% of the users are going to do. I'm not sure. I did not get the point of using the repository to. Are you saying that there is another way to get the get instance, the client, get client. Except does the get dot with accept the repository as an argument to create the client? Are you saying something like that? Well, no, it's a helper method, I guess. It's an API provided by the git that shows where you want to have the get client instance in which repository you want to have the get client instance. That's something that you're saying is wrong. I mean, there are two options. You only said that you can provide a default installation implementation and people can override it if they want to or they could use this. I think if this is what is being used majorly by the consumers of this API, then they can provide the default implementation and remove that responsibility from the user. But it's like a network. I'm not sure if this is something that we should do right now. But then Mark said that this is permanent. Once we've published an API, it is very rare that we will risk the danger of unpublishing it, of deleting it. But then again, the messiness in the Git plug-ins APIs is already sort of legendary. I'm not overly worried about this one addition here, in part because I don't expect any other implementations to extend or to implement Git credential bindings outside of this plug-in. I could be wrong. I've been wrong in the past on that. But usually, it takes years before others start considering implementing things that the Git plug-in provides from its internals. So then we can safely do that. I think we could make this a default then. What do you think, Mark and Justin? Do you think that it's an effort we should take right now on it's just OK because you say it's not going to implement it? I'm prone to not take the effort just because if we do change it, I feel like I've got to go through Interactive again and verify interactively with the modified code. And so there's a motivation to me to say, no, let's not change it. Let's go ahead and ship it because we want to get harsh it onto fully focused on the private key work. Yeah, I'm OK with that. That seems like a fair assessment of the downsides and upsides of that. I guess if it was easier to remove it than that, then maybe I would like to say that maybe it'd be nice to remove it. But yeah, given the interactive testing that you have to do, that seems reasonable. And given the fact that it's quite unlikely that someone is going to take a dependency on this API anyways, and the harm in someone taking a dependency on it probably isn't a lot. So to double check. So what I think, Rishabh, your point is that if I'm implementing the get credentials binding interface, I must provide an implementation of get client instance. And that implementation I must provide will probably be those exact two lines that are in the implementation already. Yes, the only point, the only logic being that we should not assume that the user is a customer aware of the get plugins ecosystem or let's say APIs. Let's say they want to implement the binding, extend the binding, and they don't want to. But it feels like an extra step, but then it's OK, because you said the reality is that the binding itself is not going to be extended. It's not like it's something which is going to be frequently extended by users or developers. So definitely we can go ahead. The cost of doing it is right now considered at this stage. So Harshad, back to you. Are you one more round of safety checking? Is any objections to me going ahead with the merge then? No. For me, I'm OK for both the cases. If you want to change implementation, I'm OK with that as well. If you want to go with merge, I'm OK with that as well. And Rishabh, back to you. I'm OK with the current. It's great. And Justin. OK. All right, then I'm going to go ahead and just hit the merge button. And that will, oops. OK, merge. All right, now we'll let that CI job run for the 30 minutes that it needs to. And I'm going to launch on my local systems the same thing. Get up checks are great. Yeah. So builds, if I remember, I take 30 to 45 minutes for this particular thing because of the number of tests, et cetera. And right now, my infra is mostly offline because I haven't restarted it recently. So half the agents are currently not online. So it'll be busy for a while. Kind of in holding pattern for that. Yeah, so then I guess after this, then you're going to handle kind of the release then. Or is it something Harsha's helping out with? No, no, that's something that has to. We're still, we still release from my desktop. So we haven't yet switched to use the automated release systems. So this will be, yeah, I'm going to build it, install it in my local Jenkins instance, restart the instance, do some preliminary smoke tests. And then if I haven't run out of awareness, I will release it. But then the next hour, if not, I'll release it tomorrow when I'm awake again. Mark.sleep. Exactly. Well, and Mark's got an embarrassing one that the Jenkins release that should have happened today didn't because there was an infrastructural problem that I should have investigated, but I didn't. I was busy doing other things. So we're one day late for the Jenkins weekly that should have been delivered yesterday. Or it should have been delivered today. The eternal realities of modern software development. Yes, yeah, that's a way to say it. I like that. Harsha, did you have questions about private key implementation status, or was it a question to Harsha? No, just I know he'd been working on it. If there were any questions, I put that as a placeholder. Oh, OK. Cool. Oh, we have a new release of Blue Ocean. Well, I have one question. Mark, did you check the license that I asked on the video chat? I did not. Very good question. Let me ask that. So let's go to the I'm going to post a question to the developer mailing list on that, because that's an excellent question. I did not do the research on it. Harsha, let's see. Let me find that it was it's LGPL3, right? Yeah. Also, sorry to interrupt, I'm on the same lines. Harsha, you were saying that the line is mutated. Are you saying that they did not even to get the correct private key? They were not even to convert the private key, pass phase protected private key into the correct decrypted private key. Is that is that what you found out? I think when I change the format, the file format to PEM or any other, we base 64 encoding, the private key generate and the file format generators is not being accepted by the server. Things that the public and the private are not matching. I would say they are not authenticating, forming a valid key pair. So I think it was an issue when I'm converting the private key into a file format. So that is where I'm getting an issue. But the plugin that I suggested, sorry, the library that I have suggested is performing this on by its own. So I don't have to care much among the formatting of the file. It just creates a file form. It just creates a string for us rather than creating a byte array, which is done by the previous implementations. So is that only for certain types of keys? Or is that just kind of happening in all cases? I think it's happening in all of the law. I have tested it on OpenSSH key format only for now because the other formats are being handled by the credentials. So that was, yeah, bouncy castle API plugin that was provided by Jenkins. So that was not an issue for me. Okay, yeah, so yeah, because you were looking to use SSHJ specifically for these. Yes. I have another doubt regarding the scope of the Git. There's a method in Git client plug-in named, you know, Git SSH executable method. So, and it is, I think, packaged private. So, but we needed the implementation in our binding as well to find the path for the SSH in Windows environment. It's in the Git plug-in, or Git client plug-in, you said, right? Yeah. What was the name of the method you were? Git SSH executable, this one. You want to be able to use that in the Git plug-in? Yeah. You know, this method provides the path to the SSH executable in Windows. But it is packaged private scope. And my reason for not making it public was because I was embarrassed by the implementation. I apologize for my embarrassment. But trying to find SSH on Windows had all sorts of awful problems. I mean, you can see it in, if you look at the code, how it's making all sorts of guesses. Oh, what about here? What about here? Let's try here. Maybe here. I remember having to do the, or... Exactly. Well, brother, let's play this guess, or this guess, but I think it certainly has been there for a very long time. And for me, I have no objections if it were to, if it were to make it public. Let's see, let me look at the blame, the history on it. So it was... 2004 scene. Yeah, it's only seven years old. So it's probably pretty stable. Just depicted this. It doesn't seem that this... Is it something that we did to get... Sorry, what was that, Rishabh? I was just saying that... Can we not complicate this to the get plug-in instead of inferring it from the get plug-in? We could, but then we've got to maintain it, maintain that horrible guesser code in two places. And really, to me, when I look at that, I think the location of SSH is very much a command line get specific thing and command line get specific things probably should stay inside the get client if my preferences are held. Just because that's a level of guessing that I wish we didn't have to do, truthfully. So should we change the scope of the method to public or do we have to get an Apple method like we did for the, is it least method? I would just change the scope of the method to public. Are you already calling CLI get methods? I think you are in the get plug-in, right? There were some places where we needed to call APIs that are specific to the CLI get API Imple class. So I would just make it public. Yeah, I think that kind of makes sense because get client plug-in is the dependency of get plug-in and not the other way around, yeah. I think then it would be required some Jollerdocs to explain the method as well. Yes, yeah, yes. And you probably shouldn't use the word, Mark, Wade is ashamed of this method in there, but you might think about it. I guess one other question back, sorry, jumping back a little bit, we still have more questions about this one. I think this one's closed, great. Does that help you on this particular question? Sorry, I don't wanna jump back to the other question before we finish on this one for you, hardship. No, nothing for my sake. Okay. Do you feel like, are there other things that you think you can look at for the SSHJ thing for like while we figure out the answer to the license question, like as a backup plan or do you need guidance from us? I have tried the SSHJ library, but I'm not, I'm pretty, you know, I'm not able to, I'm stuck on that thing only to convert the byte array into the file, new file format. So that's causing an issue for me. Another alternative I have not searched much on that. I'm currently working with the Maverick library only. If you all have any, you know, alternative or something to suggest, that would be great. Maverick seems to be, I was just trying to compare, actually. I was just saying that Maverick seems to be a relatively new library, right? Harsha, do you still consist of full ranches in your 70s and 70s and 70s and 70s and 70s and 70s? No, no, I was just looking at the library. Yeah, if it works for you, I don't have a problem. So you're directly getting the decrypted key in a string content, right? Yeah. And the problem you're facing with SSJ or any other library is that it gives you that same content in a byte array, in a byte array, and then you have to convert it into a file first and then you convert that to a pen or do you convert that into a string, base 64, sorry, the byte array into a string and then encode it to base 64 and then try to do something with it. I try to convert the byte array into file format directly. There's a method provided by the bouncy castle jy implementation named PEM write object. So that does the work for me. Also, the byte array generated is, yeah, sorry. Go ahead. I was saying the byte array generated was in a format, it was in format PKS8 format. I think I mentioned on the little chat as well. I think that could be an issue of converting into PEM format, but I have to work a bit more on that. Okay, this news for me because I thought, you're saying that the encrypted private key, the AES56 encrypted private key, when you decrypted using the library, it's providing you the key in PKCS format. Yeah, I mean, yeah, I'm, no, no, I'm sorry. I was just saying that if that is the case, then we would have to handle those keys by using Java's PKCS implementation because it would not understand it directly. I didn't assume it, but fine. Okay, that's something that I would have to also do because I did not. I mean, I provided the code for that. You can look from there. Have you provided the code in the chat only, right? Yeah, I'm trying some comments as well. And did you say that you, I saw you include some code that I think was for Maverick Synergy. Did you say you also had code for the SSHJ one? Sorry. I think I had an audio issue. So can you say that again this time? Oh, sure. Might have been my side to you. I see that you had included some code for the Maverick Synergy. Did you also include some for SSHJ? Maybe that was a while back too. So I apologize if that's what you meant. Okay. The code that I've put in the chat. In the Gitter, right? Yeah, yeah, yeah. I have included that. I mentioned the methods that I have tested. So there are at least four methods, at least three or four. So, and two types of encoding that I'm using. So there's four basics, Tico and PEM encoder. I'm not seeing it, but that could be my search foo is not working well on Gitter. Did you, I guess one question I'd have is if you convert directly to a file first, are you passing the same encoding that should be expected for the byte stream? Just don't wonder if anything's getting like, kind of swapped in terms of like encodings. But I'm assuming you've probably already taken a look at that. I think I remember you passing in a coding before. Yeah. So encoding, yeah, the encoding I'm not sure about the, are you talking about the algorithm or something? Well, so when you write a file, you have to tell it what encoding you want to write the file with. Maybe that was optional. But I do remember, like, I mean, I've had problems in the past where if I don't exactly line up the encoding for some of these kind of more interesting use cases, sometimes that can cause some problems. I'm not suggesting that it's definitely the problem here, but a possibility. Yeah, I think that's a possibility. I have to look into that. Well, I will inform you on the Gitter chat. Okay, sure. The only difference can dishonorable difference I could find between Maverick and SSJ is that SSJ is older and Maverick is relatively, I'm sure that is something we don't need. Yeah, although for me the, and I agree the more mature is interesting. I like seeing the history of Maverick's synergy and the fact that it's got a commercial entity behind it. That's very comforting. If the code were MIT licensed, the answer would be trivial, go with it. I just don't know the limits on LGPL3 and what it means in the Jenkins project. Might be hard, but yeah, I don't know. Exactly, perfect, Jenkins. I think that since we're not sure about the Maverick library, I will be working more on the SSJ then using SSJ and figure out if I'm able to resolve the issues. Yeah, and I guess I have kind of what might potentially be a silly idea, but could be an interesting idea from a licensing perspective. But maybe annoying for you from a user perspective is that you could, since this is a particular type of SSH key, like maybe you can make this an optional plugin, but I'm not, I don't really like the solution. I just want to really make sure that's clear. I mean, theoretically, I think you could not make this available to people unless they specifically installed it, which would mean that they're accepting the license, if that were helpful for the Jenkins project and they weren't happy with the LGPL license. And maybe that's not even an option, but. Good question. So, ah, ah, oh no. Okay, so we've at least got some components that are dual-licensed. The Java native access library, i.e. JNA, is dual-licensed Apache 2.0 and LGPL 2.1. And Java Assist and the, looks like possibly the Mariah DB Java client library is LGPL 2.0, LGPL 2.1. So, oh, and the icon V library is LGPL. So there definitely are some LGPL libraries at least referencing the CloudBees documentation. So my suspicion is LGPL 3.0 is going to be okay. I don't see any LGPL 3.0 in the list of known licenses used in CloudBees products, but I see LGPL 2.1. So I'm not sure, Harshit, that I would shift your focus away from Maverick if you've got Maverick working. Yeah, I'm just concerned about the license only. Right, everything is working. If we can get it functional, that for me is much more valuable right now and let's get through the getting it functional, assuming that because the only thing you're doing with this particular library, the Maverick Synergy Library is being used to read and write the keys. You're not using it to actually make an SSH connection. You're not using it for any network connection. You're not using it for anything other than reading and writing files, right? Did I understand correctly? Yes, ma'am. Okay. Yeah, so in terms of my advice, proceed with Maverick Synergy. My thought was, if we go ahead, worst case, we discover, hey, we're not allowed to use LGPL 3. Okay, then we gotta look for an alternative. Yeah, that seems reasonable. LGPL 3 is an open source license and it's just, it is one of the GPL family. If it works for you, Harshit, I think you should go ahead. I've noted that and underlined it. It's a bolder, even, we don't do that. Hmm, right. Any other doubts, Harshit? Well, I'm thinking of making a PR, hopefully, by today for the binding, particularly in all Linux distributions, because for the Windows, we are, you know, I have to first make the method public, only then it will work for Windows and then using incrementals. And I like that a lot because if you've got a pull request, that gives a chance for me and others to do some interactive testing and code review. So I think that's very promising. You said you'll put together PR from Linux, correct? Just to make sure I don't have those flipped. Yeah. Yeah. And then I'm marking here that we put together a blog post for the release, and assuming that the basement has ended and it has then, will Harshit write a blog for the basement? Is that something that is already, is that something that we've discussed? Sorry, I didn't quite hear your question. Rishabh, you were asking about the blog post. Yeah. Could you ask it again? I was just saying that is that something that is discussed that we know that Harshit is going to do or is that something that is going to be done after a certain period, a blog post? So my thought was either Harshit can write it or I would write it, but one of the two, I would like to have a blog post just to highlight the good work that's been done and that people can begin using immediately, credentials binding to solve interesting problems that they have with the get plugin today. Now, in terms of benefit to the organization, I think Harshit's work on SSH private keys is more valuable than the blog post, but the blog post is a great way to write and show if he doesn't mind doing it. We discussed earlier there was another, so there are two blog posts or just one? I think we discussed that there was one blog post for the explanation of how to use the binding and what issues that it dissolves for the users or is this the one that we are talking about? That's the one we're describing and it's just one. Ultimately, at the end of the project, we'll want you to do a blog post that describes the experience that summarizes and that highlights the functionality. This was, for me, just a good short-term way to describe it for people so that they can realize that the functionality is available. The project's not complete. We haven't done private keys yet, but it's already usable and shipped. That kind of characterizes this, Rocky? Yes. I mean, Harshit, if you have the time, I think it's a good exercise, coming from a student's perspective, writing the blog and trying to present the idea, the complex idea and abstracting out that idea into a simple blog, into a blog is a good exercise for any, it's a good experience. So I don't know if parents in India have this phrase, but at least my children used to hate it when I would say, you should do that because it will be good for you. Maybe they don't say that in India, but my wife used to say, husband, you never should say that. Don't ever say that to your children. This is not an attempt to give you something that's just good for you, Harshit, ultimately. But for me, the challenge is, implementation is intensely valuable, and if you need me or someone else to write the blog post so that you can keep focus on implementation, I'd much rather reach the end of the project with a private key implementation than with a blog post and no implementation of private key. Yeah. And now I am curious, do parents in India ever say that you should do this because it's good for you? Yeah, yeah. All the time. Come on. It's like each step of a child's life is defined by that point. Oh, OK, all right. So you've heard it as frequently as my children heard it. Like, yeah, I don't ever want to hear that phrase again. That's a terrible phrase. I think still, to this day, I hear it, so yeah. Yes, but you're still your parents' child. Therefore, it's OK. At least that was the excuse I gave my children, adults that they are now. You're still my child. Get over it. I mean, if Harshit wants to focus more on the implementation right now and rightly so, I would love to work with Mark. I just like the writing process. I'd like to contribute there if you're doing that. Yeah, well, and that, Harshit, if you don't mind not being one of the authors of this, I think it might be good if we let you stay focused on the code. Do you have a feeling one way or the other? Gee, I want to be a writer and I want to do some writing on this or no, I'd like to stay on the code. Well, I think I should stay focused on the code because there's a concern on the Maverick license and then there's SSHJ issues also. So it would be good for me at not being focused more on the code rather than focusing more on the writing part. Great. Then let's, Rishabh, you and me together, I would love to team up with you on it. This would be a lot of fun. Yeah. OK, so that's a that's a that's called that a decision. We're set. All right. My apologies. I'm running a little late today, so I need to I need to drop off any other things that I'm needed for. I don't think so. Hershey, do you have any other things that you need us for? But no running the time. OK, Rishabh, you're good. Yeah, I'm doing it. All right, cool. Well, thanks, everybody. Have a good one. Bye. Bye. Hey.