 Welcome everyone. This is the Jenkins user experience special interest group. It's the 21st of June 2023. Thanks for being here. I'll update the attendee list a little later here topics that I've got on the on the list for today. What's happened recently in UI improvements as one topic. And then a reminder for the next LTS baseline, a temporary expansion of the security audits. This one, Vodek Filoni will will lead the discussion on. And then we've got in addition, a topic on keyboard usability from Christina Pizzagali. And I've got a closing topic on end of life for operating systems. Any other topics that need to go on the agenda for today. Okay, then let's get started. So on the recent UI improvements. Thanks to the work of Tim Jacome and Basel Crow prototype JS removal has started and is making great progress. Thanks very, very much Jenkins core has had its uses of prototype already removed. Since Jenkins 2.406, the usage from core of prototype is gone. We continue to ship it so that we retain compatibility, but the usages in core are gone so that we can find it and there is now a an experimental feature that you can disable the use of prototype to see what happens. Thanks to Basel for keeping this plugins tracking sheet up to date. We're seeing good progress there as as we get releases of plugins there are some, you can see the the sort of orange colored bars have a pull request and need to be released needs to be merged and released. The red don't have a pull request so we're welcoming contributions from the community and others to help with the transition off of prototype JS. Okay, so next topic on my list then was, we've got a new UI, new feature coming in the UI from Marcus Vinter of SAP. He's proposed to use a modal dialogue inside the web pages for the delete dialogue. Nice modernization really good feel it's been through the security review it's been through various use reviews so it should be arriving pretty soon. Any questions or concerns there. Okay, next topic then was UI improvement pull request from me on fire chick and here there are several in flight that need that are either ready to merge or need review and further discussion. I'm not sure that there's any of these that I feel like a need to highlight specifically over the other just that we've got these ongoing pull requests that that are looking for comments reviews and getting ready to merge. Then there are some that I'd say have more more discussion going on where it's proposed to change manage Jenkins to be settings. There's a discussion there it's recent discussion happening in the last few days. Good discussion but it needs to continue. Likewise this change of the structure of the, the jelly files to better represent things has good discussion happening between yawn and, and, and Jesse Glick and others. Any questions or concerns on any of those. Okay, then the last item for me on the current current UI progress was, we've got work from Marcus Vinter of SAP on three additional pull requests that are sort of quiet right now and might benefit by some extra attention to bring them back to life. Okay, any other items on specific UI improvements. I did some experiments with the CSS compilation. And I found, I found that I was able to use as able to use some transpiler to compile newer and newer CSS syntax into a form that could still be understood by HTML unit. And I think that could be a viable approach for us to continue to modernize the CSS that we use without breaking our existing unit tests that rely on HTML unit, which can't parse a lot of the newer syntax. So I have one pull request that demonstrates that for the media feature range notation. In general, I think that's an approach that we could use for other CSS features in the future. And we already have the Babel JavaScript transpiler doing the same thing for JavaScript. So this approach should be the same thing but for our style sheets. Thank you. Okay, so, so Basel, in terms of what that really means is as a developer, I can write CSS that's modern, and the transpiler will convert it into a form that is understood by HTML unit three by the old JavaScript interpreter that's that's understood by HTML unit three. Yeah, exactly. In fact, I compared the generated CSS from my change before and after. And it was exactly the same. Even though the code that was checked into get was the newer syntax. So it transpiled to the exact same version as as what we currently have checked into get. Excellent. Now is there is there more review needed there or is it just that we need to we need to get the review and then get it merged. What do you feel like. I think one of them has one approval so far. The other one is for. So I tried to use this transpilation option for that has pseudo notation. And it did not work for that because has is more complicated and cannot be transpiled into older CSS. Without some JavaScript as well so that the polyfill for the has feature is more complicated. It requires both CSS and JavaScript to run in browsers that don't support has and the JavaScript part of this polyfill didn't work in HTML unit either, which is just really just really depressing because you're trying to you're trying to use a polyfill which is ostensibly designed to support older browsers the older browser doesn't even support the polyfill. So, but I think this is more of an exception. I don't think I think in the common case we should be able to transpile most things if they aren't complicated like this, because most of the polyfills that I saw the vast majority of them were pure CSS. There wasn't any, any JavaScript. So, so just because I wasn't able to use the transpile approach in the case of has doesn't mean that we can't use it in general. But getting rid of the has pseudo notation at least makes our logs clean, because our logs are full of HTML unit, not understanding this has notation. Which is just distracting when you're running other tests. So, so basically my first pull request gets simplifies the has the has notation and my my second one introduces the transpiler. Thank you. Thanks very much. Any questions from others to Basel on CSS transpilation on transpiling with CSS. To that, have you tried with some less or CSS situation as well there, or just with pure CSS that is a model. This is, this is already using CSS. The technology that I'm using is, is a, is a preset environment for our for CSS, a building tool, I forget what it's called now post CSS. We were already using scss and the way that this technology works. I thought that I thought that we would be directly compiling scss into CSS, but that's not how it works it. It compiles scss into some intermediary representation that's unique to post CSS. Post CSS has a generic, a generic mechanism for compiling its intermediary representation into CSS. So, essentially, scss and less, and many others are just front ends to this post CSS subsystem, which was surprising to me but that's how it works. Thank you. All right, next, next topic then was the just a reminder from me that as a reminder our next LTS baseline will be chosen in three weeks, July the 12th. So the the weekly releases, we always care about weekly release stability but be mindful that we're up upcoming on the next LTS baseline selection. So, let's do a good job. That likely means 2.414 or 2.413 will be the chosen baseline, if our past patterns hold any questions on LTS baseline selection. Okay Vodek you want to take this next topic. So it's a pretty long topic if you want to move to another one before. No worries for my side. Well, I think I need at least 10 to 20 minutes depending on the discussion around that. Yeah, and I was thinking well, we could we could Christina if you're not especially interested in the security audit we could bring security Christina's earlier. If that would be easier for you Christina or if you intend to be with us the whole time, we'll just put you where where you are on the agenda now, wherever you'd like it. Like, so then, given the time variable this one I'd like to go ahead with this one Vodek if that's okay. No point is not critical that we cover it this week it's just a continuation of what we've already discussed so. To provide you some context related to the topic there you can open the reference that you have like three or four lines after. It just an advisory that we published some days ago, related to an issue that was in Jenkins for perhaps seven years or eight years something like this. So that vulnerability was detected recently by the security team. I think it was one month ago something like this. And what was interesting to see with that one, it was corrected as a side effect of something else. And when you know that it was detected one month ago, but was present for seven years. And it was detected and corrected in the approximately two weeks of this kind of thing that's quite interesting. What's also interesting there is that we are usually doing some audit on the web UI, the pure UI related for request. That was something we put in place some not weeks but month ago, and that reduced drastically the number of vulnerability that were introduced recently in Jenkins. And recently I mean, like, less than one year ago, because we have some vulnerability that we are still finding in the code that are coming from 10 years ago and this kind of thing. It's just a matter of finding them at some point. And with the audit that we are doing, it was reducing drastically the number of them that were recent. So if you come back to the previous or tap please mark. Thank you. So what is interesting there is that that pull request was not UI related. It was in JavaScript with some jelly aspect I don't remember exactly but it's JavaScript and jelly, but these things were not covered by the initial scope of the requirement for the audit in the past, because they are not touching the UI. Meaning it's not visible for the user. That was really the goal of the first policy or instance there. So at this point, that's just for the context, I want to just raise a bit of awareness about the cost of the security release, because that's something that could be oversight by people that are not directly working within that process. So I try to keep it simple there. I discussed with a basil about the extended list of things we are doing. You can see you can see that list is already reduced by at least a factor of two, I think. So we have a lot of costs in terms of time in terms of time frame as well in terms of constraints. I can correct something within the pull request. It's fairly easy. It's a matter of perhaps one day maximum the time to do some ping pong discussion and this kind of thing. But if we wait for it to be released, and part of a version of Jenkins, it's at least 20 times the cost, just for the security team. Now, it's also something to consider it's what is outside of the security team and mentioning that at the end. The preparation is time consuming because we have to do some coordination between what we have ourselves in the private version and what is in the public version. All the backport we have to provide for the weekly and the LTS. In addition, the release lead for the next LTS version will provide some backports. So this backport has to be integrated with our fix and showing that the fix is still fixing the vulnerability. And also the weekly is sometimes something that is changing quickly depending on the time. So we have to integrate that as well inside our fix and still ensuring it's fixing the vulnerability. So due to that, we have to prepare some additional data. So the advisory process, so the content, the description that you are seeing at the end, but also the upgrade guide, the change log, and all the merge information that we are using to do the different merge of the pull request correctly in the good order while ensuring everything is compiling correctly. That's for the security aspect of the security team. What is also invisible most of the time for the contributor is the impact for the user of Jenkins. If you are running a version of Jenkins that has an open vulnerability, meaning that we have published an advisory, your version become vulnerable, openly vulnerable, it was already, but now everybody knows about that. And with the information, some companies has to provide a quick update, so urgent update and this kind of thing, which is disturbing their regular data they work in a sense. So we try to reduce the number of security release to approximately one per month to reduce a bit the alert fatigue, the not have one release every day or every week, it will be a pain for everyone. And also, compared to a non security LTS, if you don't want to adopt a new version of LTS, it's up to you, you don't want a new feature and this kind of thing, that's fine. But when it's a for security, it's expected that you adopt it, because it will have an impact on your instance, or potentially depending on the vulnerability. To point the security scanners, they are very close friends in the sense that they are reporting a lot of CDs, every time that are not always very interesting, but it just a noise that we are adding to the top of all these kind of things. So, all the information there is not to say that we have to split the bill or this kind of thing. It's something that we are paying in the security team, it just to make other people aware about the incurred cost of that. That is not just all you have to correct the thing. It's a one line things you can do it quickly. Yes, the fix itself is simple. Probably it's 95% of the thing. It's outside of the pull request process, the fix. So perhaps any question related to the costs there. So, so have you considered ways to, are there any ways that we could spread those costs or is the reality most of them have to be because of the confidential nature they have to happen inside the security team no matter what. It depends on the people working within this fix. It's more matter of time and will from people. The security team is open. If you want to contribute to participate in this kind of thing. What we usually what we usually require is that the people inside the team are active in the team because they have access to a lot of confidential information. If you are part of the team once per year, it could be problematic in terms of security confidentiality and so on. Providing the fix could be a way to participate in the effort. But as I mentioned, it's 5% of the cost. It's a participation for sure. Typically the release lead and I'm saying in that meeting already some previous release lead. They are participating by the coordination and this kind of thing. So that's also part of the thing there. I'm talking about requiring people who are on the team to be active within the team. And I think there are other teams in Jenkins where it would be beneficial to have a requirement that people who are on the team are active within the team. Agreed. Yeah. Okay, Vadek, do you want me to go on to the next section then. Thank you for the scroll there. So what I'm proposing at this point is that we are expanding the scope of the pull request that require a security review. What is expected at this point is to expand to the jelly and JavaScript pull request, meaning the thing that could be related to same kind of excesses and other vulnerability. I would like to have that expansion to be done for two months and not just indefinite even the previous policies not indefinite in terms of timing it just until we are not single any vulnerability frequently I will say that one it's more like a time box to see if there is an interest if we are finding something because if after two months we have found we have found nothing. There is no value to continue that so to reduce the pace of the development to slow down the contribution that's not the goal. Also, during that period, if we are finding something it's a way also to inform the contributor a be careful that one was dangerous that one could be also impacting in this kind of thing. I will raise a bit triggered some discussion related to that. Also, as I'm explaining the scope of that, I don't want just to be annoying and this kind of thing. We are also helping in terms of compensation there in the sense that currently we are looking actively on the open for request at least once per week. So usually the people in the team are looking at that proactively, but we have one reminder for team per week sorry, and the idea is to move to at least three times per week. Mainly Monday, Wednesday, Friday, this kind of thing. So, if nobody was looking at something on Tuesday, on Wednesday, the team will look at the thing. Okay, we have to split a bit the different things so that we provide an audit as soon as possible. We have to move forward. Something to keep in mind, most of the pull requests that are not UI related are very simple in terms of audit, meaning that we have seen a lot of such pull requests in the past. Reviewing them could take us between five and 10 minutes, something like that. So mainly, if there is something that is blocked because of us, a single ping will solve the situation in perhaps 20 minutes or half an hour. That's very optimistic, I will say. I would like to see the practical effect of that. So, Vada, in terms of how would you like that ping? Is there an alias or just W Follone? What's your preference in terms of if we need to ping? How do we ping? Ideally, the label is enough. The need security review. Oh, good. Okay, add that. Okay, great. And if it's not enough, if we need to have a mention of ping in the pull request, I think we have created a team that is like security review or something like that. I can provide the team name just in two minutes. Also, another point about the scope, why are we doing that only for JavaScript and Jelly, and not for the rest of the pull request like dependency date, backend, correction, modification and so on. It's usually something we have seen. The backend in general in Jenkins is more secure in core and popular plugins. In low popularity plugins, it's also part of the issue, but we are not in that sense of situation. So usually the core maintainer and all the people contributing for the backend. No, I will say 90% of 99% of the thing related to security putting the required post putting the check permission and this kind of thing. So, I have not seen any recent vulnerability introduced because of that. If there were, it's mainly a corner case very complicated code and this kind of thing. So, from my point of view, there is no real risk with that. But the JavaScript Jelly is more easy to put some exercises inside. So that's a bit why I would like to focus on that aspect and not on everything. We have to consider the practical aspect, the team, the security team time is limited. We are not infinite number of people there. So we have to focus on the things that matter the most. That's a bit the idea. And related to that, just a quick reminder. The team is very happy to be pinged on any pull request. Even if it's not gs or jelly, if you think there is something that could be problematic. If you have a doubt fingers. It's a lot easier for us to spend five minutes. Oh, no, no, don't worry. It's a false positive, instead of having to correct something. Basically, I know Alex was thinking us on some of the things. And it was like, oh, no worries. That one is simple. But for us, it's really five minutes. And instead of having something that is very dangerous and is merged. The cost is increased with that. So just a summary about the finger. I hope to have a scope expanded for at least two months. At the end of the two months I expect it to be completed to be removed with the outcome like we have discovered nothing in two months there was no interest to continue at all. Ideally, we have discovered something that are interesting and we have mentioned that to the other people so that they can check by themselves. So that for the future, they will be, I will say, aware we've caught about the different things that are dangerous so that they can ping us more actively without relying on a forced policy like this, which is not ideal at all. So, I'm done with my all liars and these kind of things. So please, any question any concern any feedback about that. So thank you so much for explaining all of this and I really appreciated learning about this process that is followed for each security release. If you want we can explain a bit the discussion, we can spend hours discussing about the whole process and these kind of things. So I know Alexander you've been frequently involved in these kind of pull requests. Are there any concerns from you in terms of this, this extra, this extra step in order to keep security costs reasonable any any concerns from you Alexander. No, I don't have any concerns. One could possibly argue that it would or could slow down the overall time to get a PR delivered. But I don't think the impact is huge on that, given, like what I said, the team would refer them more than one time a week. I don't have that many open pull requests needing attention from the security team targeting jelly or jazz components. So I think the impact would be rather marginal, and we would be still able to deliver front and pull request a timely manner. Great. Thank you. Okay. Are there any others go ahead. Keep in mind that if you are seeing something. Because that's typically something I don't want to slow down the process of others. If we are slowing down by 1% that's fine. But if it become really relevant. We have to discuss we have to readjust the process. Any other concerns any or any concerns from other participants in the call. So then I'm going to go ahead and agreed proceed as as proposed and note, given I've seen no objections I think we we say yes, the UX CIG says let's go ahead with this. Thank you very much for the the Jenkins security team being willing to do it. And thanks to core reviewers for helping helping make it successful. Next topic then was improved keyboard usability Christina do you want to give us a summary there and so where it was left the the big three blockers had been cleared. The top nav sidebar, the bread crumbs. So, in last month's meeting, the ask was that I kind of humanize the breakdown the audit that hadn't done the German language one. So what I've done is created. Let me see. Here I'll just open it. Yeah, please. Yeah, there's seven tasks. The figure rather than bombard the board with a bunch of them group them by the. So right now we're going to target 2.1 keyboard operation and navigation and the results. So some are straightforward some are broken down a bit more so it's got clear acceptance criteria and suggested fixes. But it's a good starting batch. So if I open one of these you're saying that I, okay, there are there is a description of the issue and a link back to the epic so that it's not just experts who could pick this up. No, no, hopefully not. And I assume since I created them if they get comments, I'll, I'll get those. I'll get notified so I can jump in and then provide further clarification if needed. So in terms of is this is this one we've sometimes we get questions in the Gitter channels. I'm a new contributor. I'd like to help. This feels like it's still a little more specialized than a new contributor might be particularly ready to embrace what's your sense is this friendly to a university student or somebody who's just, I would say probably not. Okay, all right. Just because it. It's kind of a core and it's kind of across all. I don't know my gut take would be that, ideally, it was somebody who understood the platform. Okay, so, so that thanks, thanks for the guidance that means for for those of us who sort of do advocacy noise out in the I we're I'm not going to tend to use this one and we'll let this one rather be more handled by people who are already experienced in working in the Jenkins UI. Great. Okay. And most of them are kind of straightforward. They're you know, mixed up tab indexes, things like that, things that fingers crossed, you know, are not not huge lifts. Okay. Thank you any questions from others on on the keyboard usability improvements. Now, I guess this is one these will probably touch jelly files. Right, because that's commonly where, where navigation is set so vodex team will then be flagged, but they should we hope also be relatively simple reviews, because they're not Christina the way you described they're not huge changes. They shouldn't be now. Okay, great. Any other questions for Christina. Okay, next topic then was notifying users of operating system end of life and this is just to share that we've accelerated the visibility of this notification we added an admin monitor in 2.407 to tell people if they were running an operating system we knew would be end of life in the next six months. And we hope that will help at least some subset of them to get off those, those old operating systems. We have an approved exception to the usual LTS policy so that next week when release 2.401.2. And this warning will also appear to LTS users. So that's about eight weeks earlier than we expected. It's not harmful to them. I think it's a reasonable thing to try to warn them earlier that their their operating system is reaching end of life. Any concerns or comments there. I guess I should note one thing is that I'm dreaming of a future extension where where we will warn people about container end of life. And container end of life is a very different thing because it's not the operating system it's the fact that we're no longer going to maintain that container image. That's not there yet it needs extensions to the base thing, but we think it's a good thing to tell people you're running a container image we're not going to support after such and such a date. All right. That's all that I had anything else that we need to discuss here today.