 Welcome, everyone. This is Jenkins online meetup and the Jenkins contributor summit. It's October 2nd, 2021. And it's depending on what part of the world you're in, it's midday, Saturday in India. It's early morning Saturday in Europe or it's the middle of the night Saturday in the United States where I am. Thanks everybody for being here. I'm going to go ahead and share my screen and let's let's get started. This one, there we go. All right, so everyone what you should see is slides. Perfect. Welcome to Hacktoberfest 2021. These slides are archived at this location bit Lee Jenkins dash Hacktoberfest dash 2021 so you can go find them later if you need to. You know what I should probably paste a link to those slides into the chat. Let's do that. I'm going to post it in presenter mode sorry I'll have to have somebody else help me with that. Welcome everyone let's get going. So we've got three presenters today. Vadek Folonier and me I'm Mark Wait. Uli comes to us from the technical university of Munich. Uli could you clarify for me technical I never get the title quite right go ahead and introduce yourself for it. Yes, it's a university of applied sciences. It's called Germany in Munich here in Bavaria. I'm teaching about software engineering where I'm always using Jenkins to show continuous integration and yeah. I'm also a long time Jenkins committer. I think it's now 15 years that I'm committing to Jenkins started at the fine box plug in. And now I'm author of the Bonnie's plug in the get forensics plug in and plug in. I'm talking about today is the code coverage API plug in, which I'm now a co maintainer. Thanks very much Uli that's wonderful. We're so grateful for your contributions and so glad for what you do with your students at the university. Vadek Folonier is here with us Vadek comes to us from the Jenkins security team. Yeah, sure. I'm located in Switzerland I'm working especially in the Jenkins security area meaning correcting finding vulnerabilities and coordinating all the release of the security correction. That's a bit the top part with the community we have to care about all the things to be done at the same time to prevent any disclosure and things like this. And doing my regular vulnerability finding research. I'm discovering some bugs that I'm correcting at the same time. That's a bit the idea. Thank you, and I'm Mark wait I'm the Jenkins documentation officer and I maintain the Jenkins get plug in and try to help the community as well. We've also got one or two as additional helpers with us today. We've got dirage sing Joda who is is has joined us and he'll be assisting as a moderator, looking for your questions. So if you have questions and one and the presenter heavens to miss those questions, we'll rely on dirage to help us with that. Dear Raj thanks very much for being here we sure appreciate your help. And we hope to have one other but that that moderator may arrive a little bit later. So thanks everyone for being here. Today, we're going to talk about Jenkins in Hacktoberfest, a contributor summit for Jenkins as a chance for people to get together to work together. We usually start the contributor summit with a presentation segment and today's presentation segment will focus on three or four different ways that you can contribute to Hacktoberfest in Jenkins. Then, after that we will switch from this zoom webinar format to a zoom meeting format, you'll need to join a new zoom meeting and we're going to breakout rooms there and will allow vatic to have his breakout room. I'll have my breakout room and if Uli's willing he'll have his and each of us will try to answer questions for you. And I believe dirage has agreed he's willing to run a breakout room as well. We'll use those breakout rooms. Thanks dirage will use those breakout rooms as a way to let you interact and ask questions about your specific challenges or things that may be getting in your in your in your way as you try to contribute. Definitely that sounds exciting. Thanks. Right. So for today's introductions, or today's agenda, I'll do the welcome and then Uli's going to talk about improving the user experience. I'll do a segment on migrating plugin documentation to GitHub. Vatic will talk about implementing content security policy. I'll talk about modernizing plugins and then we will switch at that point. I'm happy to answer questions during the session. Please feel free to use the Q&A facility to do it. You are also welcome to comment in chat if that will help you. We would love to have your interaction we're interested in helping you be successful contributing to Jenkins during Hectoberfest. So welcome to Hectoberfest 2021. We're very grateful to DigitalOcean for their sponsorship and to Intel, AppRite and DeepSource for the funding and sponsorship that they've provided to make it successful. We've done Hectoberfest for many, many years in the Jenkins project and have thoroughly enjoyed our interactions with community members and the way we learn together how to contribute to open source, looking forward to it again this year. As a reminder, everyone can contribute to Hectoberfest. You don't have to be a programmer. You don't have to be some guru expert. You just need willingness and interest and we'll help you through it. There are online events highlighted at the DigitalOcean site and sometimes even in COVID-19 there are people who run local events. Now their recommendation right now is please let's stay mostly virtual like this session. So contributing to Jenkins in general looks like this. You could open the Jenkins.io website for the Hectoberfest page. It's under the events menu and there you can see some of the featured projects that are available. And there truly are hundreds of open issues that have been identified specifically as good first time issues or issues that are well suited to a new contributor. So Jenkins.io slash events slash Hectoberfest will give you insights into ways that you can help. Just for clarity, any pull request counts towards Hectoberfest and counts towards well can count towards Hectoberfest and helps the project. So if you want to do code, great. If you want to do documentation, great as well. We manage our blog posts and our artwork through pull request. So if you are a graphic designer and would like to do a new Jenkins logo, we've got the place for you to do it and you can do it as part of Hectoberfest. Now on this slide there's a link here contributing to Jenkins it is all about you that takes you to a separate slide deck that goes more into detail on this. So where should you contribute. Well, user experience and Uli is going to take us through a detailed tour and show a demonstration of things that he's prepared and places you could help very immediately with your JavaScript skills or with Java and JavaScript skills in combination. I'll show how you can contribute to user documentation and learn something about ASCII doc. So Vadek is going to show us how to contribute to content security policy. I believe that's predominantly Java as is plug in modernization where it's made in Java. It's even easier for content security doing my advertisement there. Okay, need to know a bit of JavaScript really the bare minimum and the rest will be more easy. Excellent. Thank you. Okay, so Vadek's Vadek's point is well taken. I am not skilled in JavaScript. I actually find Uli's work in JavaScript somewhat intimidating it's such an amazing thing that people can create user interfaces on a web page continues to amaze me. Thanks Vadek. We have opportunities to improve terminology in Jenkins. We've been using terminology that is uncomfortable and indelicate. And so for instance several years ago we switched from using the term master to describe the Jenkins central central system to call it a controller. We switched from using the term slave using the term agent but there are lots of places that need those translations need that that change. We can also contribute to translations. Maybe you'd like to maybe you're a native speaker in French or, or in Japanese or Chinese and would be willing to help with translations that would be great. So where can you contribute. Each of these locations here gives us a link to issues that you might considered working on for Hacktoberfest. So if I click this hyperlink it will take me to a table that is, oh let's go with this one table that is. I've got to go off screen for just a minute. Hang on. I want to be sure I show you the exact right place I thought I had that hyperlink correct. It is the following I want friendly issues, because this is the thing that you need to see. What it is it's a nice little table. That shows issues. So what we've got here is these are friendly issues identified by the developers for various components you'll notice core that's Jenkins core the kernel of Jenkins 70 issues identified warnings and G and analysis model the get plug in. If you're interested in subversion. Here's the subversion plugin you can help with if you're interested in user experience improvements warnings ng analysis model. If you want to learn more about get there's the get plug in ready to go. That that list of friendly issues is there to help you decide where you might like to contribute. And these are places where we can really use the help. So we look forward to your help there. Likewise, if you'd prefer to do see issues, possibly on GitHub, maybe you want to do something with documentation. This one will take you to GitHub issues that have been listed as good first issues. And there are plenty there for your help. That's, that's the caliber of things that we're looking for we would love to have your help. Now, how do you get started. So join our Gitter Fest on their event website and join our Gitter channel. So our Gitter channel looks like this. Join up and have conversations with us will be delighted to have you there. And then just start creating pull requests. If you create a pull request, you'll help all of us if you'll put the word hacktoberfest in the pull request title. And if you're a Jenkins maintainer help us by labeling the pull request as hacktoberfest. That way, it qualifies for and marks it correctly so that the hacktoberfest counting system will correctly detect it. And please be sure you put hacktoberfest in the title. If you didn't get it into the title put it into the text of the of the pull request that you're submitting. And now you may say hey but what if I want to find other ways to contribute. Well, the Jenkins participate page Jenkins dot io slash participate gives you lots of other ideas of wait us to participate. Each of those read more buttons takes you to an entire page of places where you can help. And inevitably, you'll need to help by submitting pull requests that you can mark for hacktoberfest. So we look forward to your contributions. We think they'll be great. Now, if you need some more advanced places to contribute. There is the Jenkins zh so the Jenkins China repository for the localization to Chinese there's the Jenkins dash info repository, where we do info maintenance. So things like hosting our web servers and maintaining the plug in site and all sorts of things like that are in Jenkins info. And we're also happy if you contribute to upstream projects like Apache Apache Maven, or others like it. We'd love to have all of them. Get your help, as you feel interested. And the links are participate hacktoberfest the FAQ and contributing to Jenkins. Now, we're going to switch to yours and I'm going to stop sharing my screen and let you share yours is that all right. Just a quick comment. The question and answer panel is more for question. If you had just a discussion that you want to have with us with other people just use the chat. It will be easier because otherwise for the Q&A. We have to reply to the different questions separately. It's not the best tool for that I will say. Thank you. I think one moment. No, I can't move the window. Let's start again. So what I would like to show is the work that I've done in the last couple of weeks with the code coverage API plugin. I just had a nice few, but there were some details missing from these views. And so I tried to refactor this fuse so that these views look a little bit more prominent. What I'm sorry. But I'm missing from my introduction. I think I prepared two slides, which are in your slide deck mark. So I'm wondering if we can start with these slides, and then I make the presentation. Absolutely. So would you like me to. Is it okay if I share my screen then. Yes, just that this is just two slides. Just when I talked I noticed there is something missing. How about this one? Yeah, this and the next slide. Yeah. So what I wanted to start with is Jenkins is yes, I think it's almost 15 years now old and the user interface is quite old as well, because Jenkins uses mostly static HTML. So this is very helpful if we have plugins that want to extend the user interface, you can provide your own views that is quite easy. But disadvantages of course, the layout looks a little bit boring, let's say, or it's some kind of old school, and the other modern JavaScript elements are not available there. So we have in Jenkins notice that we need to put some work on this, and therefore we created a Jenkins user experience group to improve the user interface. And what we want to do is some kind of step by step improvement that means we want to make small things in every release of change and that big bang integration as Blue Ocean tried to do. So the idea is that we start by improving the plugins, step by step, and then take one part that works well to the other plug-in so that everybody can have a nice user interface. And in this group, we have some Jenkins developers, and if someone of you is a UI engineer or JavaScript professional, it would be really helpful because we have a lot of Java developers but not so many JavaScript developers. So the meetings in our group are every four weeks, you find it in the event calendar, so welcome to join here if you want to help. Can you switch to the guest? And now about the background of my talk today, the code coverage plug-in, as I already mentioned, is some kind of old user interface which I wanted to improve. And what I've done is I'm not sure if anybody knows my warnings plug-in, but in the warnings plug-in I started to use a lot of modern JavaScripting frameworks to improve the user interface. And the same frameworks I applied now for the code coverage API plug-in so that we have now two different kind of plugins which use basically the same kind of user interface. So if you look at the warnings plug-in and then you look at the code coverage plug-in, it looks everything quite familiar. Of course, there are different elements on it but the user experience is almost the same, I think. So I'm using bootstrap. Sorry. Sorry, Uli, forgive the interruption. There's a question that I think this might be a good place to answer it. So what I'm going to talk to you as is code coverage covered by using SonarCube. Maybe you could describe how code coverage operates at the user experience level and how people or I guess maybe you'll be demonstrating that. So one way or the other, I think you'll get there. Yeah, the code coverage or let's say the analysis elements in Jenkins are quite different from Jenkins. There's a kind of an additional server that takes your source code and processes the files and creates code coverage, creates static analysis, and then renders in the SonarCube application. So what we try to do in Jenkins is we just hook into the build. You have a Maven build, for instance, where you produce your code coverage files or you produce your static analysis files, or you have a note build for JavaScript where you produce as well your code coverage or you produce some warnings from ASLint or something like that. And now the Jenkins plugins take the results of the build and render it within Jenkins. So you do not need another tool. So everything is included in your build. For every build you get the same information that the build has. The thing which is quite different from tools like CodeCuff, which work afterwards or SonarCube, etc. And what I've done now is to introduce some different libraries. I already mentioned Bootstrap. I'm also using FontASON, awesome to provide some modern icons, each chance to render the trend charts, and yes, data tables to show. Data tables like in Excel, you can see them in a web user interface as well. And I implemented the basic features now, and there are still a lot of things that could be improved there, and therefore I would like to show now in my demonstration which kind of things are already there and where you can participate. Okay, so now we are ready for my demo. Let's go back here to my screen. The first thing when you start with the code coverage, the code coverage, let's switch to this. When you create a build in Jenkins, every build has some typical artifacts that are generated for each build. Now we have here the build number 38, and here we have some checkout from the Git repository. You see the latest commits from the repository, and what I also included here is now a coverage report where you see what is your line coverage and what is your branch coverage of this build. You also see in this information the reference build. What we also now try to compute is for every build, we not only want to compute the total coverage for this build, we also want to see the increment. So did you change the coverage? Is it better? Is it worse? So here we have, yeah, it's a little bit worse, the coverage here, but yeah, you see it's not really a big difference. So this is the idea. We have information for builds and information for data. That means from one build to the next build. And this is a screen which is quite a basic screen where we see some build results. And yeah, I think it's more interesting to see how the code coverage looks for the single build, and therefore you can click on this link and then you will navigate to a detailed view. And the detailed view looks or is split into a little bit bigger. So now we have, the screen is already prepared for different screen resolutions. That means we have a different components on the screen that render differently on your iPad or on your big screen. And now you've seen, if I make the screen a little bit smaller than some suddenly the screen is too small, then yeah, you can show different UI elements. And this is one thing I started, but this is not really finished. So I think if you're on the iPad or even if you're on your phone, you need some different screen because on your phone you are maybe not interested in the overview or you may not be interested on the details here and in the bottom level. So, yeah, here is a lot of possibilities where you can help take your phone and make a screen just for your phone or take your tablet and make a screen for your tablet. So this is one thing where you can help to improve the detail view consists of four parts. So we have the trend chart, we have the overview, we have a kind of package overview where you see for all your files, the code coverage, and you have some, let's say a table where you see the details for your table for your files. That means you see the package where your code is placed, the file names, and then you have some elements that show the line coverage. And one thing which works but is not perfect is now that you have a horizontal scrolling, for instance, that means what one can do is to improve the number of columns according to your screen resolution. This is possible with the libraries I'm using, but I did not find the time yet to do it so this is would be one part to improve the table so I make it a little bit bigger. So if you make the table bigger than everything is visible but if you make it smaller it would be helpful if maybe some columns will pop off and will not be shown at all. So this is the detail view which I'm would be or which I'm using as an architect I would like to see these are my files and I want to see why is here in this file the code coverage. Good or bad. Then I can click on the link and now I see the overview for this file. The branch coverage for the pile, the line and instruction coverage for the file, the number of methods and the number of classes in this file. And if I want to see a detailed view of the source code this is possible as well. And then I can have a look at the source code and you see, according to the coloring green lines are covered, red lines are not covered, and yellow lines are partially covered. Though this is a good help for an architect or for US and developer. And yeah, here it would be helpful if we, yeah. I'm not sure if this part of a hackathon or October Fester issue because currently the text is kind of just plain text it would be helpful if there was some syntax highlighting, etc. So this would be a one possibility to change the visualization to a concept what I'm using in the warnings plugin, where we can see the source code with Java syntax highlighting, etc. Okay, so here we let's turn back with here we see the details for one build. And what's also provided by my plugin is this kind of trend chart that means you have the opportunity to see the results for builds to build that means a trend. And are you decreasing your coverage or are you increasing the coverage. And this same information is shown on the main view of Jenkins that means if you start on the main view that you see this coverage brand and line coverage a trend. And there you can see, yeah how behaves your coverage how many percentage do you need to get closer to the 100%. And of course, the introduction to the user interface, which is now almost ready. And for this interface, a lot of things can be improved. For instance, the trend chart. Here we have only a single trend chart. It would be helpful to show a different trend chart that does not show the absolute values, but the data values. And we already have this configuration button here, and you can extend this few which is now showing where you can change the width and the height. You can put these things you can say okay I only want to see five builds. And if you save it then the trend chart changes. And what we also can have what would be helpful if we show a kind of delta few that you see, not the total coverage but you see how did you increase by each build or decrease by each build of the code coverage. So this is one thing that you can improve the charts. One thing that one can improve is the coloring of the charts, for instance, currently the coloring is hard coded in my Java files. So it would be helpful if we can provide, for instance, in this dialogue that we say okay I want to show it in different colors and add here a customization of the colors for instance. So this is one thing we can add. There are a lot of other things we can add we can add a columns for the Jenkins few let's say I go to the Jenkins dashboard back. So here we have our the jobs here on my instance on and here you see, for instance, the name of the project and the last success, and you see the number of static analysis warnings. And it would be helpful if you also see the branch coverage or the line coverage in this table few. So this would be also one enhancement that you can provide at a column that shows the branch coverage. Some other elements you can show or help to show, for instance, here this table. I just provided two columns, for instance, one column shows the percentage as a number and the other column shows the percentage as a chart. As a background. So maybe it would be helpful if someone can create a single column that shows both in one cell. Then we have not the width is better used and yeah, I think it's even easier to read if we just have one column that shows it. What can also be helpful if we currently I only show the branch and the line coverage in the detail fuse. Maybe someone is interested in the instruction coverage or in the method coverage I'm not really interested as an architect because for me only the lines count, but maybe other uses of Jenkins require some different a few so it would be helpful. If you can extend the plug in by making some things more configurable, which are now hard coding. Well, for instance, in this chart here where you see the package overview. Here you see the code coverage elements of my classes. And these. So for instance, if it's read you have a poor coverage if it's green you have a good coverage. So you can click and see this is the eclipse eclipse XML browser seems that I'm missing a test case for this class. And what you see in this chart is the tree view of your whole project for the line coverage. But you don't see the branch coverage yet. So an additional idea would be to either make this few configurable that you can switch or toggle between line and branch coverage, or create another tab where you see the same, not for the line coverage but for the branch coverage. So, you see, if you get a little bit familiar with this plug in you will find a lot of ideas where you can improve. What I try to make is I created several issues here in GitHub, which I marked with her to profess. Some are features, some are enhancements. And yeah, I think you can have a look in this table, if there is something would you like to add. Not everything is UI related. I have some views, some issues for instance, the remote API needs to be added for the new model, which is playing Java so if you don't need your eyeskins to provide that. Some others are great Java and JavaScript and some others are only JavaScript so feel free to look here and see what where you can help. And here I have just look for the hacktoberfest label here in this repository. So this was my walkthrough of the code coverage plugin. Are there any questions? There was one from one of the participants about branch coverage is branch coverage limited to Java. So, is the UI that you're presenting tightly connected to Java as a language or can it present results from other coverage systems or from other language systems. And present results from every system that is supported. The code coverage plugin works a little bit like the warnings plugin. We have the tools separated from the Jenkins plugin. That means you need to run the tool in your build. The build produces some kind of JSON file XML file, whatever, and then the code coverage plugin comes reads the results and present the results. We actually have support for Chaco co cobertura in Java, but we also have support for the different other tools. I actually I don't know the names of the other tools because I don't use them, but we already have for C++ and C support. And if we do not have support yet, one can write a simple adapter or parser. And this parser needs to read the XML file and to create the Java model. And this would be an enhancement as well. So if someone wants to not participate in the user interface. And he wants to show, let's say coverage data of JavaScript, and we do not have a parser yet then just write the parser and the plugin will work out of the box for these elements. So it's, there is nothing in Java which, which is basically in the plugin. The only thing is maybe that we have source files that may contain classes, which is not given in every other language. So, but normally we in every language you have some kind of files you have some kind of methods you have some kind of lines and branch coverage. So, yeah, everything should work what you, what you have. Thanks, really very much answer the question. I think it did thanks very much. Okay, so you give hope that those who write C programs like me sometimes can use coverage reporting to see the results of our automated tests of our C programs. Yes, I think it's already possible. Thank you. Anything else that you'd like to share it really before we switch to our next next presentation. I think I, when you switch to the presentation I have one link where in the slides where you see the, the issues that are open. Okay. Let's go here. And can everyone see my my screen. Yes, it's again here. So, the, the issues I've talked about. This is the first link here you will be right redirected to GitHub, where you see the GitHub. Yeah, October Fest elements. The second link is if you want to have some beginner topics in the warnings plugin there. This is not only UI it's also plain Java. So have a look here there are a lot of small things where I don't find the time would be helpful if someone can help. And I think the last link is the same you already presented it's just for the user interface I think. Excellent. Thank you so those links those links are ready to use and a new contributor can pick one of those and either contribute to core to the warnings plugin or to code coverage. Thanks. Okay, fine. All right, thank you very much. Great. So, so the next, the next stop, then on our journey here is maybe you feel more comfortable contributing to something that's a little different than code. Well, here's a way you can contribute to help with documentation. So Jenkins plugin doc Jenkins documentation for plugins is let's let's do it this way I'm going to pause here and we're going to look at this site plugins dot Jenkins dot IO, which is the Jenkins plugin site and yes, as it says here there are 1800 or more Jenkins plugins. And when I look for a Jenkins plugin it will show me different matches for my search I asked for the get and it showed me get in the get client. So when I click this one it shows me the documentation for that plugin. This documentation is maintained preferably in the the repository of the plugin itself. So we want to do documentation as code. And so this documentation you see on screen and it's quite a lot is part of the get plugin source code. Someone had to create that and someone had to put it there. And that creation process is part of this exercise. So what we want to encourage people to do is help us migrating plugin documentation to GitHub. So the idea here is that there are plugins that need to be migrated. And if we click here on the this sheet for instance, it's going to take us to one view of plugins that need to be migrated. This is this is my view that I did a sorting on. In this view, you would could say, hey, I want to improve the documentation for one of these plugins. And if you'll right click on a cell and comment. Let's see and I'm going to I'm going to put a very specific because I want to do my demo. I think it's called, let's see it's called schedule bill plugin here it is so I'm intentionally choosing one that's a little further down so that I won't get in other people's way. But I'm going to put a comment here that says, Mark weight wants to work on this one. This is an easy way for you to say I'm going to work on this and still see which what the priorities are. If you don't do this, no harm will detect it pretty quickly that you're working on a particular plugin. But so that's first step here find a plug into migrate. And I use the sheet because it was easier for me. I prefer there is also the official progress report. And this progress report takes a little bit of time to generate because oh, and it looks like it's been interrupted so you'll have to use my sheet for now. It appears to be offline I'll work with Gavin later to figure out why it's offline. So once you've said which plugin you want to want to migrate. I said schedule build. Now we're going to go find the exported read me file that came from the original documentation source on the Jenkins wiki. And I'm going to look for schedule build. I didn't find for me that way I've got to look this way and scroll down so we're going to do here and instead of appetite ties we're going to say schedule build. And here is the documentation as copied from the Jenkins wiki. This is the thing that I want to convert to migrate it into the Jenkins, the Jenkins plugin repository. So back to our steps find the exported read me you go to this plug in wiki docs file repository and find your plug in that you're migrating. Now, next step is let's fork the repository and create a new a new read me file for it. So I'm going to actually borrow this hyperlink open the page the GitHub link that you saw let's go back there you see right over here in the links. There's the GitHub link. I'm going to click the GitHub link. Okay, here's the repository. My first task then is to fork it so I'm going to click the fork button in the top right. Open up. It will put it into my repository notice that it's creating marquee weight slash schedule build plug in. So here's my fork now I need a local copy of this so I can work on it. So I use the code button copy here and now in my favorite terminal system. I'm going to say get clone there and you could do this on Windows you could do this on Linux you could do this on Mac OS. So give me a copy of that plug in. And now it's time to get ready to do the transformation so I'm going to check out a branch. And the branch I want let's see so docs to docs to GitHub. I want a branch to work on and back to the instructions. I want to create a read me file there or edit the one that's already there and include the extra information in it from this file from this page. So let's do that. And use your favorite text editor I think the one true editor is emacs but don't don't let anyone be too distracted by that. So this one has a read me file already and I'm going to go grab. Yes vi editor would work as well. I actually use that one as well. Good, good point. And yes, as most people learning how to exit vi is one of the earliest things we have to develop as a skill. Very good. So let's go there to the to this file, and I'm going to look at the text in raw format. So I need to find. Let's see where is the raw view I want this. Click raw here. And here is the markdown for this plugins documentation in the original wiki that was there so I'm going to paste this in here. There we go. And now it's just time to do some editing. Okay, so it's got the first thing it shows is oh there are some references here to docs images so I need to go get those files. And those files are in this repository as well. Whoops in this repository here. So as we look here we'll see docs images, and there's the file, and I'm going to go grab each of them so I'm going to copy these, and I need this link so, and it needs to go into doc slash images directory so I'll put it in doc slash images. I did it not make her. Right, it didn't because I need to use the minus P argument. Okay. There we go. So I'll do that with the other images as well because I think I'm going to need them all. So get that link. And what this is doing is preparing me to create this documentation. So it's that simple that process of bringing down the images from the original reference material, put them there and then they will be usable. And we won't take terribly long with this it'll be just another moment. And if you're on windows. W get is available you just need to use PowerShell. On Linux and macOS it's already very commonly available you can get it immediately. I think we've got two more is all and then we'll be done with the capturing all the pictures. It's this simple, we just go ahead and do this, and you've now transferred files so that you can continue this development work. The last one here. Okay, so I've got got my read me file. It's now got references to those, those pictures. And now I prefer sometimes to fix formatting like that. And, but there it is, it's ready. I'm going to get at all the go ahead, was there a question. Yes, sorry for interrupting. So, I just want to make sure if I'm on the same page with you and just want to discuss the things that we have done until now and just just correct me if I'm wrong. So, there's a main repository, which has all the plugins related content posted there, plugins, wiki docs, and what we're aiming to do is selecting a plugin from this repository, and then make changes specifically for that plugin. And for that, we are accessing that plugins, specific repo, its own repo. And then what we want to do is you want to update that plugins read me with the right documentation related to it. Right. That's exactly correct. Awesome. And then what so currently what we just did is you folk the repository, or, and then you are manipulating the contents. Yes, as we can see just for the repository of the plugin called schedule build. And now you are aiming to edit its read me file and put in right content into it. And I think there was a question regarding that how are we are we getting the content from specific to that. So, it's coming from this main repository, as we can see, and this is from here we are extracting the code, and then putting it to the specific plugins read me file. So that's we are doing, right. That's correct. Yeah, you've described it very well. Excellent. Awesome. That's great. So now I think we can move forward. Thanks. Good insight. So, so the exactly as dirage said we are starting from a central location where the docs have been captured from the wiki page, and we are then converting those to so that they can be used by the plugin maintainer in the plugin specific repository. I don't as a plugin maintainer want to have to go write documentation in some other location. It needs to be in my repository. That helps me because then I also can write documentation when I write new features. I'm much more likely to do that because I can actually include the documentation right away, as I'm creating a new capability. Thanks dirage thanks very much. So, so here we have it. I've got. I've got this ready and I'm going to say, move documentation to get up. And now I'm going to push that to my origin repository and I'm going to do a set upstream so that it remembers where I'm pushing. And it tells me what the URL is that I should visit to open this pull request. And let's go ahead and visit that that location and open that pull request so that we can, we're ready for it now, you'll see here on GitHub, it already hinted oh hey look, this green button would let me compare and create a pull request. So let's me see how does my, how does my file look and okay this is pretty good. It doesn't look bad the pictures are there and they they they appear they're visible. I haven't submitted the pull request yet but I've had a chance to see how does my work look before I submit that pull request. So that's that's and now I could either push this green button, or I could paste in the URL that GitHub gave me either will do the same thing. And it says, Okay, I'm moving documentation to get up. And now it's got a checklist. The first item is please be sure you're using a branch that's not named master. And branch a better name so yeah I gave it a good name, and be sure that it describes the pull what you want to do so this is move documentation docs to get up copy and move docs from wiki to get up. And the reason I say wiki there is that's where they existed originally admittedly I didn't have to deal with the wiki. I did yep I did. I don't need to link to any relevant issues in GitHub or Jira so I'm going to delete that one. No pull requests, and really for documentation I don't have a way to put any in any tests. So now when I create this pull request. There it is ready for the maintainer to review. Now, one of the reasons why I started this sheet. You may say, Well, how do I choose there are 1000 plugins that need documentation conversion like this. How do I choose which one to do. Well, Vada can I asked a bunch of Jenkins maintainers, if they would be willing to commit to review a documentation pull request. And these top 30 or so are all plugins where the, the maintainer has agreed to review a pull request if you submit one. I recommend you choose one of these so you get fast feedback. Now if you if you would rather, you could choose something, something else further down the list or something that's interesting to you. That's fine as well I just happened to know that these top 30 here. We have reviewers who are committed and ready to review your change when you submit it. Do you have any other questions that have arisen any things that we should discuss. All right so and and it looks like, go ahead. Okay, then I'm going to go ahead and switch back. I think it's time for our next topic. Thanks to everyone who who assists with documentation now let's go to the next topic and Vada. So I'm going to go ahead and show screen right Vada so I'm going to go ahead and stop my sharing. That's green that should be good. So are you seeing my screen. Yes, we can see it just great thank you. Perfect. So just in case I'm not seeing the discussion and things like this so if you have any, I don't know actually I can open it on anywhere else. So that's good. Perfect. Thank you for the time to discuss about my topic there but content security policy. So why we are doing that. What is it auto implement the fix and all this kind of thing that will be I will say the part of the slide there. I will not put the slide in a full screen mode because you will see for the demo I will need to switch tabs and things like this it will be easier like this. So what is content security policy. If you want, we have seen a lot of vulnerability because I'm working in the chicken security team in the recent years we have seen a lot of excess. An excess is a type of vulnerability that is pretty annoying in Jenkins. It's based on some JavaScript that you can inject in a page as an attacker and using that JavaScript to exploit some things in Jenkins. You have to think that an attacker with an excesses capability can do whatever they want at the place of the victim instead of the victim innocence so using victim authentication to do something. And as you know for administrator you have a lot of permission on Jenkins for example the script console. And so with an excesses you can use this kind of feature to execute any code you want on the server. So that's pretty annoying in Jenkins. That's why the score in terms of severity is between seven and eight on 10. Meaning for 10 it's the most critical vulnerability and zero is just a regular bug without security impact. Now what is the plan with the content security policy what is the goal with that to prevent excesses there is I will say two or three ways. The first one is to correct everything to correct every vulnerability but that's a reactive approach when we discover vulnerability we have to correct it. It's easy most of the time but we have to find the vulnerability first. The second and I will say that will do most important one when we are discussing content security policy is to be more proactive, meaning to forbid the use of unexpected untrusted script so JavaScript in this case to be executed. And how do we achieve this kind of thing. That's where content security policy is coming. If you want it's a new type of protection that is global to your application that global protection will restrict which kind of script could be executed on your page. I can show you a demonstration about that to ease a bit understanding about what is CSP. Just before that, you have some explanation on the web page, the official October Fest event webpage about the topic in general. You have a document that is this one with a lot of information so it's mainly what I'm discussing right now, but with more detail. And you have some official documentation from Firefox directly from Mozilla actually not Firefox directly. So from Mozilla but what is CSP what is the current support what you have to do to apply this correctly all this kind of thing. I don't want to go too deep into the detail there a demo will be easier to explain what we are trying to achieve. Are you seeing my screen with all the things moving or not just to be sure. We are seeing that it just great. Yeah, so you're currently on the content security policy GitHub page. Yeah, perfect. So this pull request in Jenkins core is a proof of concept to show you to demo you what is the effect of content security policy. You will see with that. Yeah, it seems to be pretty interesting compulsive just the theory innocence. So you have a lot of instruction or to use it. I will just do it myself to show you the thing because that will be easier like this. And you will see and I hope you will convince why we want to achieve CSP globally in Jenkins. So, regular Jenkins instance running we have from that pull request actually just a snapshot very old I will say because that pull request is also pretty old. So I'm connected as an admin, you can see the forewarning we have on the top right, you will see why it's important to mention this part. There is one page that is linked here with CSP proof of concept and it's mentioned here. In that page, you can configure your current in current playground to demonstrate the different impact there. So here it's a very simple I will explain you more the detail. And if I'm getting to the test page so you can go with that page that link and back with that link. It just you have a page with an injection of a variable in Java. I will show you the thing in terms of pure Java code. You can see the before injection here and after injection at this point. In the meantime, you have a payload that is injected from Java into JavaScript in this case into HTML directly. The job means that we are not escaping the content at all. What it means in practice is that the desired payload that is coming from this page, the desired payload. If I'm adding something like this italic with the correct tags. When I'm rendering this page that part will be in italic because in the code. It will be directly with the I tag so the italic tag and you can think yeah it's interesting but what I can do with this kind of thing. Actually you can just include a script. And inside the script button alert. That's the basic XSS payload that we are doing when we are looking for vulnerabilities. And in this case if I'm refreshing the page, you will see that JavaScript being executed. That's something that is pretty annoying, especially on some web page, not in Jenkins but in some web page you can just do something like this. To display the current document cookie in for my case it's not important because the session ID is protected. I can show you the thing there just in case I'm not showing something that is confidential because my local host is protected you cannot access my local host from outside of my local network. There is no secret there. You can see the session ID that has a value there that is very important if you want to attack my server. But my server is not online so you will not be able to do it you need to enter my house to have access to it so it's already broken into more security at that point I will say. I'm not seeing that cookie it just because it's using the HTTP only flag, meaning that the JavaScript code will not have access to the value, neither the cookie name and things like this. So that's why you are seeing the jgid screen resolution when I'm refreshing this page so screen resolution jgid. So that's all the things that are publicly available in essence inside the JavaScript. The problem is that if you are able to do the alert, I will just go back to the 123. You can do something else. You can, for example, trigger the administrator to run some groovy script and so having access to the server create a reverse shell so that the attacker can have a permanent access to the server, all this kind of thing. Or just like most of the time in Jenkins, creating some code that is mining some moneros and things like this to gain some money there. So here, the problem is that we want to prevent that code to be executed. Because in a sense, this kind of thing is something we want to avoid. It's not what we would like to have in terms of code. If someone is doing that, most of the time is just because there was a variable inside Java that contains some HTML tags, for example, to render a description of a job with some payload that is trusted in a sense, meaning all the name of the job need to be involved. The rest, regular text. So they are just proposing that. But now, if the display name of the job is something that the user can enter, like in Jenkins, they can inject potentially some things like this, like a payload. That's where the CSP is interesting to work with. So you can see here, reporter-only mud. It means that we are seeing a lot of report-only stuff there. All the rules we are putting in the page, you can see default source, self, and things like this. I will not go into detail. You will understand the thing directly with the demo. It means that we do not allow anyone to do something. For example, unsafe inline means that we don't expect style in this case to be directly put inside the HTML. It means that if someone is doing something like this, font, font size, 20 pixels, 23 pixels, that part will be refused because it's inlined. And that the same kind of thing we can do also for script in general. So in this case, we are seeing for the default source, self. It means that we are not allowing a JavaScript to be executed inline. Inline means what I just showed with the style. If you have some unclick, do something like alert like this, that's something that we want to prevent. That's the inline script. And here, I'm just unchecking the reporter-only mud and you will see the difference. I'm just not refreshing the page just to mention there is the four with the red background there. If I'm refreshing. First point, you will not see the alert and you will not see the four with the red background there. It's easy to explain. With the new CSP approach, we thought the reporter-mode only, we are refusing to execute the code. So we are refusing to execute the alert 123. That's why it was not popping at the beginning. And at the same time, we are refusing to execute any code that is inlined. And for that code inside the top right part, it's coming from an inline JavaScript part that is refused. And that's why you can see that part here before it's moved to the top because there was a script doing that. I think it's inside the page footer. I think it's that one. AM means admin monitor just in case. So you can see that code. If we are executing that code so I can do it manually here. You will see that part being moved to the top and that just that part of the code that is inlined inside the page because it's inside a script tag inside the page. It's forbidden to be executed. It's part of the different things were refused and hence it was not put at the top. Now I can do something differently. I can approve some of the script. In this case, that part is known to be safe. I can put a hash on it, meaning I check what is the checksum of the script. And I will put that inside the approved list of script. That's why I'm proposing a list of things here. And you can see some of the things refresh refresh. I don't remember exactly. Yeah, that one. So that hash is the equivalent signature of the script that I was just showing you. And if we are allowing that hash to be executed, we are letting the server do the regular thing. So I would just show you the thing. It's just the copy paste of the value. In this situation, you will see the alert is not displayed, but that code is executed. And inside the console, you will see only one script was refused. It's the one coming from my payload. If I'm changing the payload just to remove that part, you will see normally no error except the error or the syntax here. You will see no error. It's just a report-only thing for another stuff that we do not care. There is no longer a script, so there is no forbidden script inside the page. I can just repeat it to show you again the stuff. And here, you can see the refuse to execute inline script because it violates the different rules and things like this. There is an alternative because potentially my script is something that is safe. So that's what I did with all the scripts from that page before. I can copy paste the show, so the checksum of that script, putting it at the end of that list, approving. And in this situation, my script will be executed because it was trusted by using the hash. So that's a bit old for the demonstration of why it's useful. Now, the main issue we have is that we cannot put such things with a hash for every script we have in a page. In Jenkins, we can have between 10 and 20 scripts that need to be approved inside a single page. So imagine if you are adding this kind of thing to every request response you are sending, that's just a nightmare in terms of load for the request size. In addition, what is problematic there in addition to that is that if you're injecting a variable inside a JavaScript part, so I will say you have a regular script like this, we can say there is some script like this. I will just remove that part and refreshing the page. So normally it's not executed because it's the new one that I refused. So just adding that to the page before. So in this case, it's just an inline script that is coming what I missed. No, it's that one, sorry. So it's just an inline script from the code directly. That should be safe. But in the situation, we have something like variable, my variable because I'm lacking creativity at this point. And I'm adding something like this in JavaScript. And that's something we are seeing often in Jenkins inline script in general. So that's something that is a bit dangerous I would say that part will be injected inside the script. And then the code will be executed. So in this case, I will just execute it once so that we can see what is the hash. I will show you the result of this part executing again. So we have the alert at the bottom. I can just look for the alert. That one. And you can see inside the script. You have my variable with the payload. That payload could be something like the name of the job. It could be the name of the user or something that is fixed. If it's fixed, that's perfectly fine. That's safe. But if it's not fixed, it's potentially user entered. It means that if the user is providing a single code inside their stuff, because we have seen the alert 123 was not executed. But in the situation, I'm just disabling CSP to ease the stuff. I'm putting alert 123. I'm executing that page. There is nothing that will happen in terms of script, because it will be contained inside the single script inside the single code. But if I'm doing something like this to escape my current context, you will see to alert the first one and then the second one. Because in the code, that alert is executed as JavaScript. And it's not expected at all from the developer, because they just expect to receive a string that is contained inside his own context. So that's why we cannot really rely on hash, because if we are generating the hash directly during the generation of the page, that full script will be approved. And that's something we don't want to trust, because there was a variable inclusion that variable could contain some issue. And so we don't want to inject such things. I'm just checking the chat to see the point. Yeah, thank you for the question, Mr. Wick. There is something important to understand the regular XSS protection you can see in the different browser are most of the time not working. It's sometimes just against the reflected XSS that you can have in the page. For example, if I'm putting a payload here, payload equal alert or stuff like this, that part sometimes is not reflected on the web page directly thanks to the browser technology. But honestly, it's not something you can trust. There were some usage of this kind of protection to inject XSS in addition where it was not possible without the protection. So it's a bit controversial at the moment. And I think Chrome is removing the support for this kind of feature just for your information. So that's a bit the idea there when we are using the hash, there are other possibilities to restrict the script. And that's where I'm going with the second slide there. We have seen the hash. So the different ashes we can generate from the different script. But we have also a nonce. A nonce is just a number that is generated and that we are using only once. So nonce innocence. And that part is pretty interesting if you have a static web page in the static web page, you will put the nonce in your in your response that is generated at the server level. And all the script will receive the nonce as part of their tag. This is pretty good. It will work. It will reduce the size of the request because you are putting the nonce only once in the in the response and once per script, not a big deal. The main issue is as for the hash. In this situation, if I'm putting the hash, I don't remember exactly the attribute name, but the attribute for the nonce and I'm putting 123 or the random thing that is generated or something like this. That information will just ensure that the browser at the end will trust everything that is inside the script. If there is a variable injected, it will be trusted. And so breaking the usage, the protection that CSP is providing. So are we blocked? There is no other possibility. Of course there is one otherwise it will not be a topic we are discussing about innocence. It's about the origins. So the idea there, instead of checking the script content, we are just checking where the script is coming from. In this situation, it's coming from the page so inline. We want to entrust all the inline script. What we want to see is only things that are coming from outside of the page, but inside the web application. Meaning that is downloaded from localhost 8080 slash asset JavaScript or things like this. So that we know it's a fixed file. We thought a way to inject JavaScript at this point. Or at least I will say to be transparent with you with that kind of approach we will reduce by 94, 95% the number of excesses we will see in the future. It's not a 100% protection, because if you are trusting something that should not be trusted, it's still possible to bypass the CSP innocence. But that's pretty rare. I will say in four years working in the Jenkins security area, I have seen only two excesses like this. And they were very particular. So with the origin, what we can restrict is to say we want to have separate file coming from localhost or Jenkins that are your things like this. Or if you have some issue like with Google script that you are retrieving from Google, you can just add the Google inside the other list, so that you accept this kind of script inside your page. That's a big idea. So how do we achieve that? Because that's where the topic is starting in a sense. What I did until now is just the context to show you what we expect to do. And now is to put that in place. If I'm saying to Jenkins that all the JavaScript should come only from the localhost, it will break everything in Jenkins. Or not everything, but most of the things you can see. I can just check quickly. If my intelligence is responding, just the number of script we have in line in Jenkins core, and that will apply the same to the rest of the ecosystem. You can see that one, and that will be a very good example, you will see why in two minutes. That script is just something that will be forbidden with the new approach. So we have to do something to prevent this to be forbidden because it's a trusted script. It needs to be trusted. So that's where the topic is for in a sense. You can see inside the document, I show multiple examples of previous tasks I did in the topic is mainly we are taking one script. And we are un-inlining it, meaning we are removing the script tag, but we are putting it in a separate file. With that approach, we are preventing the variable to be injected and indirectly all the XSS to be exported in Jenkins. That's a big idea. You can see some with the level of difficulty, some are very easy to understand. For example, that one in terms of script, you can see, for example, that one was a script that was inlined. It was just replaced by where it is. No, I'm a bit lost with that one. So it's mainly just initialization. Yeah, it's just that one that is put inside a script that is used to prevent all the inline script to be needed, required in the page. I will give you a live example of what we can do for this October topic. It will be very easy. You will see five minutes to provide a poor request. Of course, five minutes because I know which one I want to do what I need to do. But if you need to find yourself your way, it will be between half an hour and four hours depending of the case and depending of the complexity you will see. So for this, I'm preparing just another Jenkins instance. That's running. So leaving that one aside and moving to another one. So, from that list of a new be friendly issue that you can find using where is the, I think it's that query. You can find that query as well here, the Gerard newcomer friendly issue. It's this request. It's what is inside the particular topic so the CSP smooth since reduction smooth because we will not put the enforcement at the beginning. We prefer to have all the migration being done before. Otherwise, we will break the instance. Not ideal, I will say that could work in terms of security. If nothing is working, there is no vulnerability. So in the list there, I'm just picking one randomly, because I know that one is pretty easy to do. You have the script. So you can know exactly what you have to do. And you have the difficulty, the skill requirement. So in this case, very basic knowledge that is required and you will see it's pretty zero knowledge. You have just a quick tips that I put in the ticket that will be enough most of the time. So the code we want to change is this one and you have seen is exactly the one I show you before because that was the first one when I was looking for script in line. So for this one. We have here and then a different project in intelligence configure entries from list. So that was what I show you, and we have the script we want to an inline. So the first step is for the developer to be sure to understand where that script is used, because if you are not sure, you will not know if what you are doing is correct or not. So in this case, so I think I need to log in or things like this. No, everything is working perfectly fine. So it's a list view configure entries. So it's inside the list view I'm editing the view. I'm just skipping some of the things to prepare the stuff and inside the webpage. I'm looking for records. I think it was something like this. Yeah, we have that part of the code so I can just add a break point at this point and a second one there. I'm refreshing the page to be sure it's executed because if I'm not able to reproduce it, I will not know if it's working or not with my correction. So you can see we are there. So I'm letting the thing moving and there is an on click doing something the on click is on that recursion in sub folder. I'm clicking there. You can see I'm there. Re-clicking I'm there. So it's working. We know exactly where that code is. Now the fun begins. What is the code change I need to provide? So back to this thing. What I will use is just a new thing at the bottom of the page. I will just add something like this. That's an adjunct. It's a feature from stepler. We are calling we are asking stepler to introduce some resources inside my page. So in this case, I need to rename it to Hudson model list view configure entries resources. That means that we can create a file inside the list view. So where that configure entries is located. That's just the simplest way. There are a lot of other possibilities. I can add a JavaScript file or a CSS or both if you want. Now the very interesting skill that is required. Copy paste and you're done. That's the main requirement in terms of JavaScript you have to do. Of course now you can really remove completely the script there. And you'll ensure the list reconfigure entries configure entries resource.js. That's fine. Everything seems to be good. So I'm saving. We thought changing the method I used to run the stuff. I will just update the page. So refresh the page. Sorry. And you will see my break point is no longer the good location. I just research for the records. And you will see it's coming from the configure entries resource.js. That one contained only that part. Just adding break point there. Refreshing the page. Oh, my break point is it. So it means that my JavaScript is included and it's working or it seems to work. So just to ensure clicking here. It's still working. Okay. Perfect. So what I did is finite is finished in terms of code. So next step is easy. Creating a new branch with the number of the tickets. Pushing the commit to your fork. And then you have the pull request ready. So that one was perhaps the easiest one you have to do. There are some other examples. What I show you before with this example, what are you doing if there was a variable? That's where there was a bit of magic you have to use. Because there was a lot of variable inside Jenkins. If there was a variable, for example, that one was a variable. So variable coming from Java. For example, actually, I don't think it was a good idea to put it there. Just adding variable here. So variable. Like before adding some code. That one is potentially dangerous. And that one, something that was injected in the page before we are in a static file in the static file. There was no injection of Java variable possible. So what we have to do is to change that variable injection to put it inside somewhere here. For example, we are looking for a recurse ID. So we can look for recurse ID. It's that one. We can add some attribute there. So data. What is the name of the thing? Variable. So just variable from Java or anything you want. And you are adding the variable here. The advantage of this approach is that when we are putting a value inside the attribute value in jelly, we will ensure that variable cannot escape its own context. Meaning if there was a double code inside the variable coming from Java, it will be just escaped by a jelly. And at the end, the value put there will contain the double code. We thought the possibility to escape that context. And now you have that thing. And you can simply, simply being perhaps a bit too easy. But it's a get attribute. Perhaps it's not exactly that wording. And we are able to replace the code with that simple approach for these things. And of course, removing that one, because even with the comment, it could be possible to inject the stuff with this approach, the variable we receive the value that is put inside the value of the attribute. Just for your information, that type of injection is explained as well inside AutoPass value to JavaScript. That's inside the XSS prevention in jelly views. You can see here the stuff. For example, that one was exactly the example I showed you before. That page is linked from the Google Doc just in case. And we are explaining all the double the double code is working to escape the context and the good way to solve the issue is mainly to create the data attribute putting the value inside and then retrieving the value from the page from the HTML text. That's to be the idea there to resolve the problem and to be able to have that script being unenlined. And so allowing us in the future, when the situation is good enough to enable CSP and to enforce it for all the page in Jenkins. That's all for my topic. If you have any questions, feel free. Vadek, for me, I was trying to be sure I understand so data inserted from Java there in that div is that a variable that only scopes to inside that specific div, or is that scoped globally in that file how how how do I how do I have a question collisions of variable names, etc. Yeah, that's a very good point. So there is no scope in the sense that if the div is present in your page. It will be reachable by your JavaScript code in the sense that if you have something like this, you retrieve the element from the page. So the target div, and then you get the attribute that called that code could be outside so in a separate file, it could be completely far from the div in a completely different div and all this kind of thing. Now in terms of conflict, you can use something more specific. For example, coming back to the code. You have, I will say a table, sorry, inside you have some tier. Of course, it's not exactly the thing we expect so td, td, td, td, and multiple TR. And what you want to do is to add a capability for something in particular, you have the cell ID. I will say it just the cell that contain the ID of the job, for example, and you have that multiple times in your in your page. And you want your class delete button. Click here to delete the job. What you will do is that you will put a behavior specification on the delete button. So inside a behavior specify here you will put just delete button. And the E at that point will be that td. That td could go back to his parent, the tier, looking for a cell ID and retrieving the attribute their job ID, job ID, something like this. And with that approach, you can do that for every line. And if we job ID, we be linked only to the delete button from the same line in essence. Is that answering your question. It does. Thank you. Thanks very much. So any other question. So just another question I got from the chat, although you protect again, other type of excess. So if you have a reflected excess, so the payload is coming from the URL directly, you will not be able to inject that part in the code, because it will be forbidden by the CSP. That's a bit the beauty of the thing there. It will be the same. Instead of coming from the request, it will still come from Java, because the request value is coming from Java as well. And that will be prevented by the same thing there. That this part cannot be used as an excess injector part in an injector location. So concerning the last part of XSS about the DOM XSS, it's not something that is very useful to protect against, because most of the time it's just some false positive from scanners. We are more concerned about stored and reflected XSS in general. And concerning the checksum, you can use all the chat checksum. I think it's a chat 256 and I can just give you the full doc there in terms of chat. It's only the recent chat two, but no shower, no MD5. I don't remember exactly where it is, but there is a link here explaining the stuff in particular. What about other type of vulnerability? Of course, there is no silver bullet for security. You have to be very careful about the rest, meaning CSRF, XXC, we are providing some kind of protection, but it's only for XSS that we can use CSP. It's the one that is the most global proactive protection we can put in place. For CSRF, for example, we have put some hardening in place from Jenkins Core to prevent this kind of thing to happen somewhere, but we cannot prevent it everywhere. Meaning if you have some method doing, I can just give you an instance there. For example, all the do-check thing, if they are doing something, now it's mainly forced to be using POST instead of GET, and that's already a good point to protect against CSRF. For XXC, we have providing some safe XML parser, but if the plugin maintainer is using something else, we cannot forbid that usage in essence because anyone can write their own XML parser. So that's the kind of thing we cannot prevent globally. And there are a lot of other vulnerabilities that are too specific to the code that we cannot prevent that globally as well. Any other question or we can move to the next topic? So could you give me a summary again? It sounds like what I need to do to improve is I un-inline the JavaScript and using that un-inline JavaScript, then that already is enough? Or is there some additional change I need to make to the source file? It seemed like all you did was un-inline the JavaScript. Exactly. For this topic for October 1st, that's the main goal, because there is a lot of things like this to do before being able to enforce CSP at the global level. We could enforce CSP for some specific part. For example, inside, if I'm going to the correct one, inside user content. So it's something that is proposed to, of course, not like this user content, to browse this kind of thing inside, for example, the readme. So if you're opening readme, that page normally you will see some CSP being already set. So just putting that one, I think that one will be good. Normally, there is some CSP already set here. Responses. Where is the CSP? Perhaps not that one. I need to enable it or I don't remember exactly, but there are some parts that are already protected. Because we know there is no plugin that could interact with the content. It's a fixed content or coming from the user only and we are restricting completely all the script, but it's fairly specific to part of the code. So it's not everywhere. And so the, the idea is once it's done in terms of migration or we have applied that to 90% of the plugin, we can enforce it, but that will be not as a topic. It will be more as a new initiative in addition as a second step, I would say. Question, Ulrich? Yeah, that was another question in the chat and this is also a question for me. One thing is to move the old code and replace these texts, but it would be helpful if the developers would be aware of the problem. So I never did know it that we should not use an inline script. And you showed a little bit on the week on the Jenkins homepage. Is your document you have shown in Word? Is this available on the developer handbook as well? It's not in the handbook directly. It's actually, yes, I'm not sure exactly the structure. There are some things that need to be improved during October 1st around the developer documentation, but you can see it. It's inside security. And if you're clicking on security, you see multiple things. And I'm not sure exactly where, yeah, you have the auto guide at the end. So it's not the easiest page to look for in a sense. But the important point is that we are using this kind of documentation to show to the people when there was a vulnerability in a plugin or to solve it. Now, if it's something that is discovered more easily by people before printing the vulnerability, it could be a lot easier for us to manage at scale. So that's a very important point. Thank you for reaching out. I think that there was some improvement we have to do on the documentation. For example, all the contributors should have read all the security part before writing a plugin, because we are seeing on the hosting request, some plugins that are broken by default by architecture. And as vulnerability researcher when we are finding something like this, we are just like, okay, that plugin will be just blacklisted because we cannot do anything with it. So that's the kind of thing we would like to prevent. That's why we are writing some documentation. They are just not easily discoverable and that's a bit painful. Maybe we can even write some static analysis tools that check all of our jelly pages if there are script text in there. I will say, stay tuned. There will be something coming in the next or next next weeks about that. We are doing a lot of stuff in terms of static rules for Jenkins with CodeQL. We are putting our own custom rules inside to detect like CSP, XXXE and things like this. And honestly, XSS is the most painful one to detect. But just detecting inline script could be a nice way to improve also the potential issue for the developer. So that's a very good point. I would just note that and inform the other people about the point. But that's totally possible in just in case with CodeQL we have access to the abstract syntax tree, we have access to all the things and detecting just inline script inside the page could be useful to inform people, hey, you have not done your unenlighting part and things like this. Any other question? So there was a question from Mr. Wick on how do you do security while developing the code and you mentioned CodeQL. So I would like to spend just a minute talking about CodeQL if you'd be willing because I've benefited by CodeQL. So would you be willing to share briefly, Vodak, how what CodeQL is and how it helps people who are submitting pull requests and how it helps developers who are maintaining plugins. So I will not disclose all the things that will be published in the future. I will just give you inside about perhaps Jenkins.io CodeQL. There was a blog post at some point that one that explained a bit what is CodeQL. I will give you the link inside the chat. That was an explanation about what we did ourselves so internally using our own custom rules to detect vulnerabilities. In this case, you can see it was mainly seven vulnerability detected by the tool and confirm manually at the end. At the same time, we have detected, I will say, 20 order vulnerabilities. The idea with CodeQL is to catch some of the behavior, some of the patterns. It will not provide you under-person protection or under-person detection of anxieties. It's really what we have written ourselves in terms of rules and all the rules are not perfect. There's a lot of false positive because we cannot do everything. For example, with the method I showed you before, do check your choice. It's a method that is an endpoint because of the do. So it's something that anyone can call on your web page. With that information, we know that it's a potential dangerous thing. What we are checking is, for example, is there a required post annotation? If there is none, we are checking the content. Is the method doing something that is potentially dangerous? In this case, error or okay, we should check here. We are checking internally here what is the thing. There is nothing dangerous because it's just about looking at the string and things like that. There is no code to URL. There is no execution of code or things like this arbitrary code because fixed code we don't care. So this kind of thing we are looking for and we are putting if there is something dangerous or that we think potentially is dangerous because we have no older information. We are sending to the administrator, meaning in this case, the maintainer of the plugin, some warnings. I will not show you the different warnings because that could be painful to share with everyone some potential real vulnerability. But if you're a maintainer of a plugin, you will see such warning with the possibility to say it's a false positive or no, it's a real vulnerability. In such case, you are contacting the security team, opening a security ticket, all these kind of things. The idea is that we are doing that in a beta phase mode at the moment, so you need to register the program. But in the future, it will be something by default for all the plugins. And we are putting that in the cell service mode for the maintainer so that they can manage their own security. But the goal is still to have us inside security, the Jenkins security team to coordinate the release. Because if you're correcting something in your plugin and delivering it right now, it will not be announced in a security advisory. It will not receive any warnings about security and so the user will not know they have to update. So that could be painful for everyone. So the goal is really to inform the people there is something, please look at it, detect if it's false positive or real vulnerability. And then you are creating a security ticket and doing the rest of the thing. What we are covering right now in terms of rules, it's mainly CSRF, part of them, part of XXC, part of missing permission check and things like this. So very simple stuff that no other engine could detect because it's specific to Jenkins. All the engine, most of the time are just taking input from the web request and looking at the flow until SQL database. In Jenkins, there is no SQL database, so we cannot use any of this kind of flow. So it's mainly all this kind of static analyzer will provide us or you are using a bad algorithm for crypto. And that's all. For example, if you're using MD5, shower, nothing like this, they will just put your warning and that's all. There is not a lot of other intelligence that we can use from them. That's why we have to write our own rules. That's a bit of the idea. For instance, if you want to improve your security skills, you can use some other tool. For example, what was the name of this thing? SpotBugs has a specific security plugin to help you also with some of the things, but it's still not perfect. CodeQL will not improve the perfection. If you want to secure your code as an engineer, as a developer, you have to learn a lot of different vulnerabilities and all to prevent them. There is no silver bullet for this at the moment. And I will say, fortunately for us, security engineer, to keep a job in a sense. There is still a manual part there. And we are working very hard to provide such a static analysis more and more accurate because there is a lot of noise most of the time. Oh, there is an injection of variable. Yeah, but if the variable is fixed or not coming from the user, it's not an XSS. So there was a lot of false positive and there was a lot of effort to reduce this kind of noise for the developer at the end. I think I'm talking too much, taking too much time from my topic. Actually, so one of the things now, if CodeQL is enabled for a plugin, for instance, for my plugin, I maintain the Git plugin, it is enabled. When they submit a pull request, will they see if they have injected something that CodeQL would complain about or is that something that only I as the maintainer get to see? I don't want to promise you that right now because I'm not sure it was done already at the pull request level. It was done more in a global status for all the repositories. And I will say we already got hundreds of false positive. So if we are including pull requests at the moment, that could be just too painful for us. Okay, so it's totally right. We will looking for the pull request. And ideally, in the long run, because shifting left to the pull request is not enough. We would like to have that also in the IntelliJ, Eclipse, NetBeans, integration directly when you are writing your code. For example, all the injector directly from IntelliJ, like this thing, or there is a deprecated constructor used. Ideally, we would like to have or there is a CSRF vulnerability there. Be careful. Or this kind of thing. But I will not promise you any estimate time of availability for this. If I need to guess, it will be like minimum two years. Great. So that's a good idea. We want to improve the situation. There is no infinite amount of time resource capacity. So that's a good idea. Thank you. Thanks very much, Vadek. So I think Mr. Wick's comment fits with what you were saying. He was asking, could we consider a linter that could focus on security and provide opinions while writing code and your description of an IDE integration. It seems like exactly that, right? Okay. And, and I know fine sec bugs has been helpful for some users in the spot bugs, static analysis world. So there are there are definitely tools available that can help us. Oh yes, you're going to show a live example of doing something you shouldn't and being told you shouldn't. Yeah, that's a bit the idea. For example, if you are using something like this, and then do the rest with the digest and so on. Here, for example, you are using MD5. That is something that is forbidden if you're doing some security thing because it was broken multiple times in the past. So there is some linter that will just say, hey, you are using MD5. It's not secure. Use something else. For example, shout to 256 or this kind of thing. But there is no more intelligence there at what I said before, they are not looking at the script you are doing there is not looking at all the variable flow and this kind of thing. So it's interesting, but it's not the only thing you have to use as an engineer with security in mind. But there was a lot of training online about auto do secure coding. That's part of a lot of compliance also that the enterprise need to fulfill. There was a lot of material on the internet. So just look for secure coding. And you will perhaps just invest three months of your time and you will have a lot of training there. Thank you, Vodik. Thank you very much. I don't see any other questions. Are you okay if we switch. Perfect. All right, so let's go to the next topic then the next topic is modernizing plugins so we've talked so far about how to do UI improvements we've talked about how to do security improvements. We've talked about documentation improvements let's now talk about specific code, and I'm going to share my screen let's take a look at it so. Again, I'm going to follow Vodik's pattern and just share my, my screen and not presenting mode so there is an element of effort that we need to do in code to modernize Jenkins plugins. There are over 1500 Jenkins plugins, and many of them are very popular and very widely used, but could benefit from efforts, small simple pull requests that will help people help the maintainers make the plugins more modern, easier to maintain easier to care for easier to handle. So one, one way to do this modernization is to take a series of small steps we're going that we can do and begin proposing little pull requests that will help with this modernization. So, first step is find a plugin you'd like to modernize and the ones that I would recommend choosing is from the adopt the plugin list. Now what's adopt the plugin well the Jenkins project as a long lived open source project has plugins where the original author has said, I can't I don't have time or capacity any longer to maintain it. I want to offer that this plugin could be adopted by others, and they will market with a special tag this adopt this plugin and then it will appear in this list. You see that there are 112 plugins available in this list that are ready to be adopted. And so first challenge okay a plugin that's up for adoption you can predict probably needs modernization. Most plugins that are up for adoption have not been modernized because their developer got busy was unable to do modernization on it so choosing one of these is a good choice. It also gives you a chance to find something that's interesting to you. Maybe for instance you're interested in how do you work with config files so config file provider. Maybe you want to do something with mercurial the source control system you could adopt it. So choosing that is a good first step. Then what we're going to do is fork clone and build it. And then we start the series of of modernization steps and there are are many, many modernization steps you can take, update the parent palm. That's one update the base Jenkins version. That's another update the SCM URL that's another one, automate dependency checks, yet another one, enable incremental builds and there are many more just like this. Those three dots are really they mean it there's a there are a lot of different steps. And you could do any one or two or three of these and have added a real value to a Jenkins plugin. There's a document that I started thanks to DevOps world that has the list that I intend to put into a tutorial on Jenkins.io of these different kinds of improvements. So here in this improve the plug in section. You can see update the parent policy. Let's make this readable. Sorry. There we go. There. That's better. My eyes can see it now. Update the parent palm review how Jenkins build status worked. There's one missing here actually which is some of them even need you to add a Jenkins file so that we can build them on our CI server. This Jenkins version enable additional spot bugs checks update the SCM URL, automate dependency updates, enable incrementals and more this these things and you can you're welcome to use this document it's available. Oh, absolutely. So here is the link. So I asked about this link let's paste that into the into the chat. There's the link to that document. And this is a workbook that I created and others are welcome to offer suggestions additional things. What this does is tries to describe all the ways that you can do these changes. And it gives a little bit of introduction it provides some text. Hey do this do this. And, and then I intend to put this as a tutorial on CIDA or on www Jenkins.io, so that people can see and adopt this plugin tutorial. Yes. Alright, improving the plugin is a good thing to do, even if you ultimately don't decide to adopt the plugin. It's really good to improve it no matter what. So, now, I am happy to show how to do this live if that if that helps people. And Uli with okay dear Raj is shaking his head up and down which I think means it's okay if we if I show the demonstration and okay great so let's do it it's it's it's for me it's a useful thing to realize hey this is something we can do. So, I've done the initial steps already. I've, I've, let's go pick my plugin I was using before so you remember schedule build plugin right. Here's schedule build plugin and I had forked it into my repository so let's go to the fork. And this thing needs modernization the last release. If we look at the releases the last release was in 2019. Three years ago. So, you can predict it probably needs modernization. So, let's do that. And as our first step. We're going to update the parent palm. And now I admit is this is is pretty easy one we're going to click this follow here and it's going to tell us what we do create a get branch. Then we're going to run one maven command maven minus NTP versions call an update parent. If I do this that already with this particular plugin gives me the capability to develop with Java 11, whereas without doing this, I'm stuck on Java eight for this plugin. So I've already with one single step, one single step I have improved things for the developer, they're not locked into Java eight anymore they could use Java 11 to do development. So let's go do it. Okay, so get check out minus be and we're going to say update parent palm. Oops, oops, I forgot. I based my branch on the wrong thing. So let's base it on upstream on origin slash master. Okay, so here we go I've got it. And now if I look at the palm dot XML file. As you can see here the parent palm version number is 3.50. Okay, so I'm going to compile. Okay, and I confess I like my Emax I'm going to compile any max. All right, so I'm going to do this step here maven minus NTP versions update parent. Okay, so here's the compilation step going and oh it's finished it says updating parent from 3.50 to 4.27. So if we look at the changes. Here is palm dot XML it says it's been edited. Okay, and in case I needed it. Maven said okay here's a backup copy if you want to keep the old copy. So if I look here. Let's look at the differences and see what it changed. Notice that it was 3.50 before, and now is 4.27. It was that easy. Okay, now, now I owe it to myself to compile that code to be sure that it still works. Right, because that would be really bad if I propose to change that I hadn't checked. So clean verify. And so what this is going to do is this is going to compile the plugin, run all of its tests, and tell me the result. Now while it's while it's doing that compile and run all of its tests. We can go look at the next steps that we're going to take. Okay, so remember our first step was update the parent palm. When I submit the poll request, I'll want to check to see that CI dot Jenkins.io processed it. So let's go back to that session. Okay, it says, hey, it ran all the tests. They were all successful. So let's commit that. Alright, so update parent palm from 3.50 to 4.27. Now, now that's a that's an okay, get commit message but the maintainer will be much benefited if I say why. The Hawaii doesn't fit in that short summary so the Hawaii is allowed development with Java 11 allow more recent development capabilities provided by by the more the recent on the recent parent palm. Now, I admit it I'm trying to communicate to the developer that this is why I did this change. Now I'm also going to tell them to do not merge. This is a demo. All right, because I don't want them to jump in and say oh yes it's time to merge this. All right, so I've committed that now that's only locally on my system so now I need to push it. And the place will push it is to the remote like that. And here it's got my place to go to submit the pull request. And I'm just going to go ahead and do that. So if we looked at my at this schedule build plugin, we'll see. Here we go. Update the parent palm. And again I've got to fill out the checklist. Yes, I'm using the correct branch. Yes, the pull request title is right. Yes, it describes what I did know I don't have to do any of those. And there's the pull request. I just help that developer with that little bit of work to be able to build with Java 11 in addition to building with Java 8 because I updated their parent palm and offer that update to them. This is a pretty easy change for them to decide if they want to accept it. And it's a reasonable way for them to see that I'm interested in maintaining the plugin. Now we're going to do more. We're going to follow on to this because there's more that we can do. Before we go too far, let's check out what ci.jenkins.io says about it. So the help here is that we want to know that that plugin built correctly. And so I can search for schedule dash build. And there it is. Did you see that drop down schedule build. So I click that. Oops, bug, bug schedule build. And I have to choose the second one. And that's just a bug. All right, so here's the pull request tab shows my pull request being evaluated. And there it is running. Now if if you're like me and you prefer the visual view rather than the console output view. I tend to click either the pipeline graph like this. Or I tend to look at Blue Ocean like this so that I can see what's happening. The Linux checkout is complete. It's building on Linux. Now ci.jenkins.io is also building on Windows and I didn't do any Windows work as part of this change. So that's a nice check. I don't have to run the test myself on Windows. It'll do them for me. So by all means check that ci.jenkins.io is okay. Now the next step is that the Jenkins base version in many plugins is a is a long older Jenkins base version. And that makes development a little more challenging for the maintainer, because when they run certain commands they get an old Jenkins version. And it also may mislead users into thinking that, oh, I could run this on ancient Jenkins versions and everything is just wonderful. Well, while that may be true, it can be much better if we just follow the documentation that the Jenkins version runs, what Jenkins version we should choose as our base version. And this page tells us gives us all sorts of reasons why we should choose one version or another as our base Jenkins version. And the recommended versions are 2.289.1 and 2.303.1. So I'm going to pick 2.289.1. The guidelines here, all I'm going to do is add an entry in the properties section of the palm that says that's my Jenkins version. Some plugins already have that you'd have to update the value others like this one do not. So let's look at the palm. And now if we look for properties. Here's the line and I need to insert that there. Now, this one I am basing on the earlier change, because I don't know that the original, the old three dot 50 parent, even understands this so this is a subsequent change for the same pull request. And let's again compile this. We want to be sure it compiles. While it's compiling. Let's look at the next at the next stop on our step set of improvements that we can make. So we said, update the Jenkins version. Well there's another piece is update the software configuration management URL in the palm. What's relevant there is GitHub has announced that they are deprecating unauthenticated unsecured protocols to get repositories. So, so because of that, if they're deprecating it we need to not be using that style of, of, of link or protocol. So let's let test past. Here's the change. Here's the change required Jenkins 2.289.1 as minimum version. And again in the spirit of trying to share with the maintainer why we're doing it Jenkins 2.289.1 is a recent LTS and is more actively tested. And supported by users. Don't rely, don't mislead users to think that we are actively testing much older versions, because truthfully, at least on the plugins I maintain I tend to test the current versions, not the really ancient ones. Well, I want to push that. And this will update the pull request so my update parent palm is now two changes, and that pattern continues so let's do it again. Now the next next of these minor ones was the SCM URL. And let's, let's put that one in here. So what we have here is this get colon slash slash is is a problem. That's that unauthenticated protocol thing. So I'm going to change that as well. These types of changes help the maintainer and their low risk for you and low risk for the maintainer to accept. And this one I know I don't even have to have to compile with it because it's purely used for other tools that want to find the source code of this system. So I'm just going to make a commit it and use HTTPS instead of and say why GitHub is deprecating get protocol in favor of HTTPS. So that here we've made three changes. Oh, I need to push it. And now if we go check our Jenkins, our Jenkins build. Okay, the first one worked. This was the first build of that pull request, when I click that arrow it takes me to the second one. The second one is running now. So it's running checks on my changes. This is my most recent Jenkins 2.289.1 is a minimum version. If we watch, we'll see. Ah, here's the third one. It's running as well. And I think we'll even see the changes there. Yep. See I Jenkins.io. Let's me watch the progress of my, my changes. Okay, we've done we've done some relatively easy ones. Now let's let's move it up a bit. Oops. This one enable more spot bugs checks. Okay, spot bugs is a static analysis system. Spot bugs can help maintainers identify problems without requiring that they know all the details spot bugs static analysis helps me a bunch because it warns me about mistakes that I make that it knows are dangerous things. And spot bugs is already being executed naturally. However, its settings are not this high of a level. So this max and fail on error and setting a low threshold. Those say spot bugs, give me the best you've got. I want to know if you find a problem. Oh, there's a good question. Okay, Runcia has a question. So runcia's question is, she agrees that having old versions mentioned as minimum version is misleading but isn't having only the newer vision, also leading users to think they have to upgrade. Yes, it is leading users to think they have to upgrade and I actually like that behavior. That is precisely a behavior I want because it's a terrible experience for me as a plugin maintainer to get a bug report from a user that says, in this year old long term support release, I have this blood bug, and I try it and I can't duplicate it. I can't duplicate it because I work on the current release. And the Jenkins community doesn't support that year old version. So they are, they are doing themselves a disservice by not upgrading. So, so there really is a notion and it's an intentional notion of, I am trying to motivate and inspire them that if they want my new features, they need to get a new version of Jenkins that's current. So I think it's actually healthy, Runcia, to have them have us set the Jenkins version to the recommended value because it motivates more and more people to upgrade. Ever since we've been doing this we've seen a dramatic improvement in the Jenkins primary versions that are being running. It used to be three and four years ago, the distribution was pretty much even across versions for two and three years back. Now, thankfully, when I deploy a new version of a plug in there are some 70 or 80,000 installations that get it immediately and can use it. Can I answer your question. Thank you. Thanks for asking excellent question. Alright, so let's, let's turn up the spot bugs effort checking. And again, this is in the property section so I'm back to that same spot I was before. Oops, I just lost my cut there. And here it is. I think this this is different in that I'm what I'm doing here is I'm not enabling something that's already disabled what I'm doing is increasing the amount of energy or effort, the depth and the breadth of the spot bugs checks. So again I'm going to run the complete compilation and let it compile. The challenge with this one is when you turn this one on, you may immediately receive new warnings, because you've increased the depth you may have to as part of this pull request suggest additional code changes that will fix some of those spot bugs warnings or will suppress them. But, again, what's that doing that's adding value to this plug in the maintainer then gets from it, the benefit that you've thought about these potential spot bugs problems, and you've made a recommendation on them as part of your proposal. So past. Let's see what the change looks like. And there it is spot bugs effort is max fail on error true and threshold set to low enable spot bugs. Max effort, lowest possible threshold, give us the best chance of spot bugs, detecting issues and time to push again. So we've, we've done enabled spot bugs. We've updated the SCM URL, there are more things we can do like automate dependency updates. So this plug in is really kind of elegant because Jenkins plugins depend on external libraries in the example that we have here this one's a pretty simple when it doesn't depend on particularly many libraries. But if we were to look at a slightly different plug in, like maybe the get client plug in, or the get plug in. The XML file is filled with dependencies on various things like ob genesis, like Apache HTTP components like SSH credentials plug in, and it can be a real pain to maintain those dependencies. If we use this dependable technique, it will maintain the dependencies, it will propose pull requests to update the dependencies automatically. And so it's, it's again, this is helping the maintainer by giving them immediate feedback on dependency updates. So this one we could do even without any palm update. So I'm going to give myself a new branch. And we're going to do this again. And then the, the technique is pretty simple. This file here goes into a directory named dot github slice dependable dot yml dependable dot yml. And now what we've got is, and here we have to find out who the maintainers are for right now I'm going to put me. I tend to be a maintainer on this plug in, and I'm going to switch the interval. I had good advice from Daniel Beck that we maybe want to switch the interval monthly rather than weekly. So now this will automate dependency checking. And if the maintainer accepts this pull request, once a month, the github processing will look at all dependencies and submit pull requests to update them to current versions. So let's call it dependency update checking to ours. Allow notify the groups, notify the maintainers when dependencies, when new versions of dependencies are released. Now Varek and Ulrich, have you had experience using dependable dot what's your, what's your perception in terms of dependable dot experience as a developer. We should not get some pull request too often. I have a test plugin that I use to demonstrate some vulnerability. And I think currently it's about weekly schedule, and I'm receiving pull requests from dependable dot every week, because there are some plugin pump update, but I don't care at all about that plugin. So I'm hesitating to just disable the dependable dot for it. But for a real plugin, it's very useful to get all the update for the different libraries that normally you do not care too much. You are not checking yourself the Mavin status every time. So it's pretty useful. And I will say in terms of security, if everyone using dependable dot in the ecosystem that could just improve our situation. For example, Guava, there was a lot of CV is in the old version of Guava and that it's still used in Jenkins core. If it was updated over time, every time it was updated and soon it's being really updated that will have ease a lot the process there. Now it's more like we have 20 major version to update to bump. So it's a mess. That's the kind of thing that will also ease the future for the maintainer. Very good. Uli, your observations. I'm using it regularly and I'm using the weekly schedule. And it's really helpful. So to get all the new versions of the libraries. I can't look on the internet for every library. So now it's automated. That's really fine. And what's also very helpful is that you get a pull request for free, which you see if everything still works. So some library upgrades that change things and sometimes tests break and you see it immediately if a library update breaks something and then you can fix it, etc. It's really helpful for me for I'm using the pen about also for my JavaScript libraries, not only for the job before Jenkins core libraries and that's helpful here as well for instance if bootstrap releases a new version. I can automatically get the pull request and then I can prepare and companion Jenkins plugin update. So I have very soon the same version as the JavaScript library. So it's really helpful. I can't think how it was before. I like that and thank you for mentioning the JavaScript. I have to acknowledge that I use it to update Docker image versions. Right, so when a Docker base image upgrades for me so Debbie and for instance or sentos or UBI. I get pull requests now on my plugin that relies on Docker images, telling me that that plugin that that Docker base image base version has updated. Yeah, dependent depend about at least for me has been a great experience. One detail, but what really was saying, I think you're, I will say a bad example, because in your plugin, you have a good code coverage for your test. There was a lot of plugin we thought test. And in this case, dependable update is very dangerous because they don't know if they will fail or not because there was no test. And I have seen multiple prerequisites being approved in one minute, meaning it was not even read. So that could be painful without the test behind that. And that's, that's, that's certainly a valid point and that's another place actually where, where, Hacktoberfest contributors are welcome to and encouraged to submit automated tests to plugins or to Jenkins core. I found that I like net beans, and it's ability to create a skeleton of an automated test. And I believe IntelliJ and others have similar capabilities. So, don't be shy as a Hacktoberfest contributor of offering additional automated tests particularly if you happen to look at the code coverage report for that plugin, and see that the thing is not covered. Right. And code coverage is enabled on ci dot Jenkins that I owe you can see the reports that will tell you, Oh, this plugin has particularly poor coverage. And that is a great excuse as a, you want to learn something about unit testing about automated testing in Java. This is a great place to do it. All right, so let's let's submit this poll request. Is it where's my, ah, no, no, no, I know I've got that repository. Ah, here we go. This one. So we're going to submit another poll request. And again this one's automate dependency update PRs. And notice that GitHub kindly filled everything in for me I have to complete the checkboxes. Please do the checkbox thing because those of us who are maintainers rely rely on those answers to decide. Have you done a good job of preparing your poll request. All right. Now there's there's more yet to be done, even on other topics like for example, let's get more ideas here of things we can do to modernize like. Where are we here we go. Enabling incremental builds. Okay, this is, this is a convenience for those of us who use and test development builds. Jenkins has the ability to allow developers to publish an incremental build that others can use and consume. By doing this incremental build others can use your your build and test your build and help you with the testing. So this is the magic command Maven incrementals incrementalify. And now for this one I have to have a modern palm. So I've got to check out back to my update parent palm. And now I'm going to run that command Maven incrementals incrementalify. What this will do is this will extend and adapt the local definition of the plugin. So that it's ready to publish a a an incremental version when it runs on ci dot Jenkins.io. So I have to do a get add dot MVN and get add palm dot XML. Now if we look at what's changed here we'll see it. It added two files and updated the palm in that update. It did this change the version from a a fixed string to a variable reference. It optimized the rep GitHub repository name and put properties in for the revision the change list and the GitHub repo. So I ran one command it simplified the life for the maintainer, the other files. I'm not a Maven guru. So I just trust them and think that they they're probably good. Yes, we could look at them they are they look like Maven commands. Let's say, enable incremental builds, allow others to download and test to easily download and test pull request builds from ci dot Jenkins.io. The reason the reason I like this so much is I maintain my Jenkins configuration as code. One of the things I maintain as code is the list of plugins in their exact versions. Because I do that I can put one of these incremental builds right in there and trivially I've got that incremental build in my test environment. And we get push and now we'll see that it's going to start evaluating it yet again okay so here's here's that same pull request now if we go forward. So when finished skipping that let's see and now that's, I suspect it hasn't started yet. There we go. Update parent palm now. Oh yes, this is it. So this one is now running and off we go it's going to start the evaluation process. So the question from Mr wick was what terminal am I using I'm on a Windows computer, and I'm using MOBA X term because it's my personal preference. I don't know that you need to use that you could use whatever is comfortable for you but I happen to, I happen to love this particular program and I've used it for a very long time. So if you run natively on on Mac OS or on Linux can just use the terminal emulator that's there. In my case the terminal emulator on Windows is just not good enough but MOBA X term is really great. Little French company that maintains it they do wonderful work. And now there are more steps like this but I'd like to stop now because I think, think we've got a good handle and I'll put some additional items here later. I think what I propose that we do now is let's look at switching into switching from where we're at now to let's go into a, a, what would we call it into a session. That will allow us to interact with each other more readily and work together on questions we've got about seven people in the session. It may be enough that we just gathered together as the group of us in a in a zoom meeting that I'll post the link for you and and I'll start it here in just a moment and we can get together in that zoom meeting to help with your specific questions. If you don't have specific questions, that's okay, you're welcome to join and just listen in. So let's, let's have everybody. I'm going to have you join let's see how do we do this. How do I commute oh I know, I'm going to create the zoom meeting, and I'm going to communicate it into the chat you've got to copy that URL from the chat window, because when I start the zoom meeting it will end our webinar. So be ready, I'm going to paste a zoom link in in in the chat just a moment. And I'm going to stop sharing my screen so that you can see my face. Alright so zoom. Okay, sign in. It'll be just a minute here. Okay, so now I'm going to host a meeting with video on. Okay, oh no I can't do that. Oh I'm my mistake. Oh, I rescued us I would have just knocked us all out. Let's try this again Mark still learning how to use zoom I'm going to schedule a meeting. And working session. For contributor summit. And we are set. Let's do this. We want posts and participants video on. And there we go okay so the, the URL that you are going to need to enter it is important you must copy this URL. I'm going to start that meeting in just a minute. And so copy that URL now, please reply in chat when you've got a copy of it so I don't knock you off before we're ready to go. I can put the link in the hot cut one. Oh, that's as well yeah that's there's there's a risk that we may get spammed if I do that we've had when we post public zoom meeting links but at this hour of the morning. It may be okay. I'm not sure. So, let's show we risk it. I mean if we if if it goes badly and somebody joins us and is spamming us we'll we'll know. Actually, and I know what I can do to reduce the risk there I'm going to change this definition so that you'll we'll use the waiting room and you'll have to be granted permission to come in. Okay, just a stupid question, could you stop the recording and put everyone as panelists. Oh, we could we could try that yes you want to try that instead that would be simpler and potential shut down because of some synchronization. Yeah, how about let's do that I'm going to go ahead and stop the recording.