 OK, it seems we're live. So hello, everyone. Oleg and John, thank you for joining and everyone who watch on YouTube or will watch in the future. Today we have a couple of issues in the agenda where we want to talk about a number of pull requests that I feel I need some insight. And then we had trouble in the past with handing security issues in a proper way. We don't want to do it anymore. So Oleg offers to explain how do we handle security issues, how to handle security issues, the process for plug-in maintainers. Anyone who's in the call can ask questions and comments. But please do not talk about specific security issues, because this is a publicly available call. And we don't want to reveal those issues. Just in my case, so I didn't announce it in Twitter. So it's still a limited public availability, and we can clean up the recording. But please be careful with that. Yeah, so we'll start with security issues. And, yeah, Oleg, you can start whenever you're ready. OK, so I share my screen. Do you see it? Yes. OK, so unless I mess up something on my own. Yeah, OK, that was just talking in the channel before that. OK, so regarding the gender security process, we actually, the entire process is documented on a single page, which is not surprised. GenQ SIO slash security, it's linked from the main GenQ SIO site. So it describes the process in detail for users. So we have advisories. You can subscribe to them. You can receive notifications, et cetera. And if you're a user and if you discover security vulnerability, it also explains how to report this vulnerability. Just to be clear, this process applies not only to GenQ score, but also to all plugins and also projects. So here you may see this. So it's Bloat, and Evergreen, Infrastructure, Configuration score, GenQ Insects, GenQ is Remoting. So from the GenQ's project standpoint, whatever GenQ sliver you use, you expect it to use this process if you discover security vulnerability. It's important because if you misreport the issue, it immediately becomes public. So for example, if you submit a security report in GitHub issues, they become public. Moreover, till the last weeks, it was also not possible to remove these issues. So it was even worse. Same for Twitter, same for public GenQ's Jira. So if you just report an issue to the GenQ's project, it becomes public. And some people may see that they can create exploits. And they may impact not only GenQ's users, but also you particularly, if you misreport that. So you do not want that. And yeah, that's why in GenQ's project, we have a security project. And when you create a discover an issue, please follow this process. So I clicked the button. Now I need to log in. Now I shouldn't open this link because it will probably show the security issues. What I need to do, I just go to the back tracker to them. OK, here I can click the Create button. And on the Create button, you see that there are multiple projects. So if you want to report a security issue, you click Security. Let's say my big task again as a security bug, whatever. You don't need that to be a specific day because all issues are being trashed. So what we asked is just report issues against this project. And we will fix the rest if it's misreported. So you just describe the issue and that's it. You click Create, and then the security issue is reported. This is what described here. The question from Evelina was, what happens next for plug-in maintainers? Current configuration of the GenQ security project that, of course, maintainers do not have access to security issues by default because we restrict access to the security team only. But when there is a security issue reported to a particular company, for example, configuration as code plug-in, one of the security team members, usually it's Daniel Beck, a GenQ security officer. He reaches out to maintainers. He describes the issues. He assigns them to them so that they are able to see this issue and comment on it. And if needed, we also provide a secure bug tracker. So any maintainer can fix the issue privately, review it with the security team, and then we coordinate the release. What we expect from plug-in maintainers is that security releases don't happen in public just to fix security, but they happen in a coordinated way. Why we do that? Because, as I said, there are many Jenkins users, and we need to prepare the release. We need to prepare the announcement. We need to send the announcement in advance so that Jenkins maintainers are ready to update their instances so that they know that the update is incoming. And that's why we ask all plug-in maintainers to follow the process. So for example, here we had one security release. In October, there is a security release incoming today according to the announcement. Here you may see that there were two plugins released and if you scroll down, you may see that there are many advisories and some advisories include plugins. And I thought that there was one advisory with this configuration as code. Yeah, there is advisory for configuration as code dated to June 25th. So there was one of, it doesn't work in that way. So if you just scroll down, we may see that there is a configuration as code plug-in allowed to anyone who is overall read access to export Jenkins configuration. So it was a reported defect, it was fixed, and it was announced as a part of advisory so that anybody who follows that, they receive this notification without looking at whatever change logs, whatever release notes, gitter, et cetera. And yeah, this is the process we try to follow. Any questions so far? No, you answered the question, one of the questions. So yeah, Jenkins security team will reach out to you if there is a security report. And yeah, we ask all people to be silent as possible about security issues so that we can coordinate releases, especially in the case of important ones. Of course, if your user submits an issue in GitHub or if he reports it in Gitter, you cannot do much about it. But at least we can still follow the process. And in particular cases, it's also expedite the process. We had several cases when the security issues were publicly announced and we had to expedite deliveries. It didn't happen for long. But in previous years, there were some cases. And in this case, we didn't send the advisories in advance, et cetera. We just at least advisory as soon as we get this information. But yeah, in most of the cases, we ask to follow the process because it really helps Jenkins users. So I have one question. So when we release the changelog for the plugin, we should not include the security issues in those. So how the process happens? As I said, we provide a private repository to fix the security issues. So as a plugin maintainer, you fix security issues in this private repository. Then we stage the release. We use Artifactory and we can stage the release using one of our repositories. So the release is staged. And it gets released on the date of the security advisory. So we push the release. Then we publish the advisory. And after that, the maintainers publish the changelog for this release. And they push the code to public repository. So we ask to not put the code and to not put the changelog until the security advisory is published. Because otherwise, it's still a potential way to exploit issues. Of course. Well, no more questions from me for now. OK. Anything else? No. OK. If you want to have more control around the process, actually, there is a way to join the Jenkins team. As many other Jenkins team, we need more contributors. And we will appreciate volunteers joining the team. Of course, joining the security team requires some background in the Jenkins community, et cetera. But if you want, it's possible to discuss that. There are some requirements like setting up two-factor notifications and CLA, et cetera. Nothing really specific. And after that, we can grant you more access so that you can participate in a coordination of releases, et cetera. Otherwise, as a maintainer, you usually interact with one or two contact persons from the security team while preparing and delivering your fix. OK. That's it with this topic. If there is no more questions, I'll just stop screen sharing. Yeah. Thank you. Thank you for that, Oleg. I will start sharing. OK. So do you have a couple of more minutes, or do you have to? I'm checking my chat right now. So let's assume that I have some minutes. OK. So there is a couple of issues I wanted to, like, for requests that I wanted to check with some of you before merging or acting on it. And one of them, 6.5.4, you had some comments about. And I'd like to hear a little bit more from you. 6.5.4. So there is this feature exporting plugins to POM. And you commented that you like the feature, but you're not sure if it should be part of JCAS plugin or separate plugin. So I rely on your opinion a lot when it comes to that kind of stuff. So would you skip merging and suggest Oliver to have it as a separate plugin, or are you think having it in JCAS is acceptable? Well, I think that generally it's acceptable. The problem is how many reliance you want to have on external tools. What Oliver requests here, there is a Custom Work Packager. A Custom Work Packager is a project started by me, Raul, and several other contributors. So it's a way to package Jenkins, including Jenkins, FireRunner, et cetera. And what it does here, effectively, it produces the input for Custom Work Packager. For me, to be honest, it would rather be a part of the support core plugin, because support core plugin already produces plugins TXT for Docker. So there is no reason to not produce Omaximal there, I would say so. And from what I've seen in the quote, actually all the quote isn't really binded to JCAS logic. So it could be easily ported to a separate plugin. And for example, if it's not a support core plugin, we could make it a part of Custom Work Packager, if needed as well. So yeah, I do not think that it needs to be in the configuration as code. I'm waiting for the feedback from Oliver, but maybe it makes sense to just ping him. Yeah, that's what I was going to do. Just wanted to get more background from you. It sounds like a nice feature, but not integral part of configuration as code, as I understand. And I mean, I see your point. So whatever you'd like me, not whatever. What did I have just said? I will ping him with that comment and we'll see if there is any problem. One of the ways to integrate it is going to, so POMUXML export is one story. Another possible option is to export plugins. JCASC has a feature to install plugins via Jenkins YAML. What we could do in inverse way, we could teach Custom Work Packagers to understand the plugin section in this configuration. And it would be impossible because we already have several input formats supported, including POMUXML. So if Oliver wants, he can just add support of JCASC format to Custom Work Packager. And I will accept this request. I think we recommend using plugins TXT, especially when you use Docker solution to process the feature of JCASC installing plugins is not working perfectly. Right, plugins TXT is also fine. But you export the plugins section already. Okay. Yeah, and plugins TXT is being exported by support code plugin. So it's also an option. Okay. Custom Work Packager input. Okay. Well, we'll follow up with Oliver then. Then there was another issue that, well, kind of showed the problems of the process we have. Is this configuration as code? Yes, so pull request template. There was a pull request template introduced before without going through a pull review process. And well, not everyone was happy with the template. And so following the suggestions, I reverted it and I created it back as a pull request so we can discuss it. And then a number of people commented that problematic line regarding the funny picture or picture of a funny animal. I don't remember. Anyway, it was meant to be a joke or something funny but people are against it or have no strong opinion about it. So I think in general, if we collect all the issues, all the comments, it would mean we will have to skip the last line. So I will update the pull request template to not contain the last line. And then there was also a comment from Liam that maybe we could have a checkbox. Checkboxes, and I mean, it looks nice, but it's, yeah, what my first thought was so people will just check the checkbox and we don't really check if the description of the change made was provided. I think we don't have to complicate it. And in my opinion, we can skip to the first version which is just text and we'll just adapt it. So we, yeah, we don't have the line that was problematic. Yeah, we used checkboxes in Jenkins Core pull request templates. I have no strong opinion about that. It kind of works. Yeah, yeah. Some people tend to click on checkboxes, as you said. Some people just tend to delete template and ignore it at all. Unfortunately, there is no way to prevent that. Well, we could kind of figure pull request builders to prevent that, but we don't. So yeah, I think it's just as you wish. Checkbox just saves some place because when you open pull request, use multiple headers, the additional lady box is bigger. But yeah, it's a minor comment. Okay, yeah, I will have a look. I mean, it's not complicated technically. So yeah, but anyway, that's the decision. We will remove the last line. You're still allowed to put a picture of a funny animal if you want to. Yeah, that one will be gone. And it was one. If I remember correctly, the default template or example template from GitHub.com actually includes the funny picture part. So I think it's just basically a copy page from there. Okay. I personally don't care that much about it because I suck at finding funny animals, but. And it's been said that they're basically just a filler. But hey, storage is almost free. Yeah, yeah. No, I mean, I think many of us are okay with that. Some of us find it funny, but some of us are not happy with it. And I guess removing that won't hurt anyone. That's my way of dealing with it. Just to clarify my feedback. So my main concern was that it was pushed without pull request review and just push. So it's the main source of my frustration. Yeah. Yes, I do not like these funny images and pull request templates, but it's, if others vote for that, I'm fine. If no, yeah, I prefer not to have that. Yeah. So the summary is more like, yeah, we have the comments. You'll find with it, except the last line. John said that he doesn't care. Then I don't know the name of X10A and 14, but he supports your comments. And so that's all the feedback I got. And then there is Joseph. Was that you, right? Commenting. You remember the big Norwegian from Nice? Oh, that's, okay. What's X10? Ah, anyway. So I guess most of us are okay, but not needed. And there's- Remove the last line. They actually want it, they can add it. Yeah, yeah, yeah, yeah. Then that's the decision. That's, now we follow the process. So I hope that everyone will be satisfied. And then there was one more issues that I think, ah, okay, a six, five, six. I mean, there's more for requests, but those are the ones that I wanted to hear some comment, and I think again, it was you, Oleg, that commented that it may be a breaking change in the, that's Daniel. So Daniel commented that I think it should not be breaking change, and did you have a chance to look at it and ask it? No, I didn't. Okay. I'm looking right now. No. Sorry, I received too many notifications. No, no, that's perfectly okay, and you don't have to address it now. I just wanted to get your attention whenever it's available. Yeah, I'm just looking at the test right now. So if it's binary, yeah, now it, okay. So now there is a comparison, which should be, let me check. I checked, you probably missed it in the original review. I checked the GitHub by the way. I haven't seen any conflicting case, lower case, but yeah, one of the things we really know and which impacts Jenkins users is that JCASC doesn't fetch symbols by class. So we have a more general issue with JCASC that plugin developers kind of create conflicting symbols and their plugins. And this is not how the symbolic system is designed. So with, regarding this pull request, I definitely approve that. Yeah, my concern is about architecture in general, should do something about that because yeah, I had a discussion with yet another Docker plugin maintainer recently. He is kind of concerned about that because there are issues coming to his plugin and effectively kind of do anything about that because he follows the development guidelines and yeah, there is no much work around for the plugin developers. Okay, did we have an issue about it already? No. Maybe there is an issue, I'm not sure, maybe it's submitted in the Jenkins data. Yeah, because I remember something about symbols, but no. Okay, so yeah, we need what you have just described, we need an as an issue and yeah, so this will have to show up. Would it be okay for you, Oleg, to just put it in words, like in GitHub issues, what you just said or do you want to do? Okay, I'll double check. So if there is Jenkins Jira for that. Then we can just rehearse, yeah. Yeah, because yeah, Jenkins Jira should be official for the project, but yeah, let's see, I can speak half-ish as well. Okay, I'll check it. Symbol conflict, okay, done. Oh, you want me to put in notes? Yeah, sorry, sorry. I just want to link somewhere and then it will be in the chat with you. To do on the paper, I may be told style, just second, I'll just add an action icon for me. Okay. Oh, by the way, I'm the person he's dropping, Ben Creasy. I'm JCR Ben in the Gitter channel. I don't have much to say though, but thanks for building this plugin, it's awesome. Well, thank you for saying that. Yeah, thank you. Okay, okay. I mean, I do have questions a little bit about the future of jobs configuration, but I know you guys have like a bunch of stuff in your backlog, you have that chicken and egg thing, but general jobs, job DSL is the way to go, right? Yeah, I mean, we're not planning to provide some separate tool for that. Okay, cool, cool. You know. So yeah, that's it for now. And yeah, so my focus currently is to make plugins. I find not being compliant with configuration is code compliant, so that's it. But then there's an interesting pull request, I think as a built pipeline step for cast plugin, and I haven't had a chance to have a look at it. Daniel said it's considered a work in progress, but that the simple functionality is tested. So I guess I will follow up, checking if he's planning to develop it further or this is it and we can take it from there. Are you talking, sorry, you're talking about job DSL, Daniel, the maintainer of job DSL? I'm talking about Daniel Garzon, I don't know. Oh, different Daniel. Yeah, different Daniel, I assume. Now it's a pipeline build step for cast plugin, and I haven't had it addresses. So the, I think I see what you mean. Okay, yeah, so it can automatically reload the configuration if the change happens. So that's interesting. Yeah, nice. In the future, there are also some plugin prototypes. For example, pipeline as YAML. So there was a JSOC project to create pipeline configurations as YAML. And once it's done, it can be naturally integrated into a configuration as code by offering a configurator in that plugin. Right, right. In the future, there may be even more ways to get it configured. Without using job DSL and kind of having to use configure blocks and stuff like that. Right. Yeah. Yeah, and you've got that chicken and egg problem, but does that pose problems for production? It does. It does, okay. So chicken and egg problem, it needs corp patches to resolve it. And corp patches, somebody has to do them. Yeah, that's the problem. Yeah, oh well, okay. But if I just have a master instance this up for a while, I don't have to worry about it as much, right, if it's already been brought up. So just to explain the main problem, the jcask initialization may happen in parallel with job loading. And you never know at which point of jcask initialization job loading happens because it's just a parallel graph and depending on some conditions, the execution order may be different. So for example, jcask may initialize some plugins after jobs requiring these plugins have been loaded. And some keys, some hooks, some unloaded handles in job implementations may be behaving correctly. But I mean, in like a simpler case where you're just like, you're just using job DSL to get some pipelines configured, you know, then you're running those pipelines, it shouldn't matter as much. Yeah, it shouldn't matter much unless pipeline plugins rely on some jcask initialization behavior. Yeah, yeah. As far as I know, the only reliance right now is continuation of pipeline execution. Yeah. But yeah, I'm not sure how it would behave in parallel with jcask. Yeah, yeah, okay, cool. Well, yeah, I mean, I like this. I'm glad you guys do these talks in public and you know, the whole community thing is really cool. So yeah, that's a good thing. Yeah, it's helpful to join. Yeah. Well, I mean, I'm mostly a front end developer. I'm just trying to get our CI system under control. Yeah. If you know what you're all trying to do, get some CI systems under control, so yeah. Yeah, yeah, I will. But yeah, I mean, I think it's worth mentioning that there is a lot of things like that happening in Jenkins community, not only around jcask. Jenkins configuration is called plugin. There is a lot of groups that have public meetings where you can discuss issues. So, you know, just to let you know that it's not only us. Yeah, yeah, I think WSL is sadly kind of quiet. So, you know, that one could use like more public group meetings and stuff. But I don't know Java nearly well enough to really do much. I did, I do drop into a Java debugger sometimes and try to understand Jenkins, but it's not easy. It's pretty much going from nothing to, you know, a speed racer like, you know, that Jenkins is heavy. It's deep Java, you know. Speaking of job DSL publicity, maybe we could just invite Dan Spelker. Sorry if I pronounced the name incorrectly. We could invite him to one of the next meetings and maybe talk about job DSL specifically. Why not? Yeah, because there are some questions regarding job DSL on Gitter. So, yeah, that's. Of course, keep in mind, those are my questions. Yeah. I think it's a good thing because it's just such a, it seems like it actually is pretty core to JC, JCask in the long run, you know, because everybody wants to configure jobs, you know, via version control as well, right? Yeah. And that's the only way to do it really is job DSL. You still have Ruby hooks. Okay. Yeah. I don't know what those are, but. Okay. There it's. Oh, yeah, yeah, you can do the Ruby. It's my own holy wars story. That's probably a standard way to do it, right? There's those groovy in it, in it hooks. It's the most common way. Well, I would say that now it's recommended to use JCask, but the JCask combines well with Groovy hooks. My approach, for example, is I use JCask where I can and for plugins, which I still not supported or for dynamic logic, I use Groovy hooks. Okay. And you don't use job DSL as much. I don't because I use Groovy hooks to automate a loading logic of pipelines. If you want, I can show some of this logic, maybe right now, maybe consent to your link. Oh, yeah, maybe it's okay. I don't want to take up too much of your time, but yeah, thanks for, yeah, you can drop a link into the Gitter channel or something, maybe. But yeah, that helps. I mean, I've tried, I've messed around a little bit with the Groovy hook, but I ended up, you know, just first try and then I gave up. So maybe I'll try that again. Cool. Okay. Okay. We're going to put a drop off, actually. Yeah, thanks for talking to me and have a good day. Thanks for joining. Okay, bye. Bye. Okay, so that's all I had in my agenda. The pre-request I wanted to comment and the security issue, things I told you what I'm planning to work on in the upcoming weeks. And we still have time. I don't know how about you, but theoretically we still have time. So is there anything any of you would like to talk about now? Nothing specific from me. Yep. So one heads up from me that I will be like and available on the current system basis for the next several months. And yeah, I really don't know the reason. So yeah, regarding video broadcasts and other such things, probably it's time to unbutton like me. So if you could get permission, it would be really cool. Is this something I should take up with Liam? Yeah, you can discuss it with Liam. But my recommendation would be to just get YouTube permissions on your own so that you don't depend on us. Because for Liam, 8 a.m. UTC, he's based in the Bay Area. Oh no, he's based in Seattle, but still it's... No, no, I mean, sorry. When I asked if I should talk to Liam, it was about getting permission. Yeah, right. So who should I contact to get the permission if... I mean, I can of course do Hangout on there on my own, but I mean, I don't have like my own channel. I would like to be signed silly. Yeah, we talked about it, but I never got to the point how should I get it and sign it. Okay, I can show it again if it helps. Yeah. Okay, just a second. Finally, I'm not needed, so it should be fine. Okay, I made myself a presenter. Okay. So to get Jenkins permission to YouTube, right now we don't have formal process and I believe it's something new here. We have some agreements about the process. So there is a repository for CLA. Let me find it. It's either in infra, no, it's in the Jenkins. Sorry, infra CLA. This is a repository where you need to submit your pull request. So there is a process described in this repository. Okay. And this contributor license agreement actually helps us to track who can get advanced permissions within Jenkins organization. We request all security team members, so people with Jenkins Corners permissions and all people with infrastructure to sign this CLA. The process is described here, generally you prepare PDF encrypted properly and send it via pull request. Here's a number of such pull requests, I believe. And yeah, you just create one on your own, then Tyler will integrate this permissions. I believe it has, so it has to be reviewed by somebody from Jenkins board. Now it's either Tyler or KK. Usually it's Tyler, then it gets integrated and we have collected CLA's there. So it's ICLA, individual contributor license agreement. So there is a bunch of people here, likely there is me as well, is me. So there is some committer properties. So you may see that we start email, we start GitHub ID. Don't ask for GDPR, please, but yeah, that's how it works now. And the same for CCLA. So CCLA is something for companies and some companies may opt in and send an ICLA if they want, but it's totally up to the companies. What we need for infrastructure is individual contributor license agreement. So even if you work for a particular company, we need the ICLA from you. Yes, of course. And then once it's approved and merged, I should be able to publish Hangout on there, like created on. You will still need to create a puller infrastructure request to get permissions, but I can grant permissions on my own belief and the LIM can grant permissions, Tyler can grant permissions. So there is a bunch of people, you just come, for example, to the community channel, ask here or send a message to the infrastructure, well, at least, and you can get these permissions. Okay, but the individual CLA is the first step. Yeah, individual CLA's must have. Okay. Thank you for explaining. So I'm gonna take care of that and then I should be able to handle the recordings and publishing on my own. Okay, yeah, it will just help you because yeah, sometimes you may want to set up recording cat-hawk, for example, to do a knowledge transfer, et cetera, and if there's access to YouTube, you will be just able to start the broadcast immediately so that it gets recorded. You don't need to ask anyone. Yeah. Same for meetings, whatever at-hawk discussion, maybe it makes sense to record it. Yeah. Okay, thank you for that. Okay. Anything else? Not from me? No. Okay, so thank you for joining. Thank you, Oleg, for handling the recording today and well, talk to you when it's needed. Hopefully some of, at least some of you in two weeks. Yeah, it's nice to maintain regular meetings. Yeah. Yeah, maybe it makes sense to revisit the discussion about the time slot. Yeah, so I was trying to revisit it when I suggested the retrospective but I guess it wasn't the right time. And I don't think just before Christmas is also the right time so we may maybe try to fix it at the beginning of next year. I think we have some contributor from States so maybe we can add up to put them. Okay, so thank you, have a nice day and back to you. Bye. Bye.