 Okay. You should be recording now. Okay. I'll share my screen. How I can share my screen because there is no video feed for me anyway. My camera is broken. All right, you got it. Okay. I'll just share my screen then. Okay. Do you see it? Yep. So the recording should be running unless I mess it up. It's recording. I've got a big recording symbol on my screen. Yep, yep. Same here. Okay. Okay. So yeah, this is a regular JCAS coffee sales meeting. Today is August 14th. Yeah. It's the Wolf's Volgeng as well. Time frame. But since we have people around, we decided to meet anyway. We have three contributors on the call. It's team Sladin who works on the community for the whole configuration as well as me. Today, I guess we don't have any specific agenda, but we kind of feel it on the flight. Okay. So new releases. I guess we have some at least. Yeah, there's been two, I think. It's not three. Yeah. So we have open the releases page, but yeah, last meeting was when we released the 1.24. So there was a number of changes there. And just one day before the security advisory, we had a meeting. So we were unable to talk about the security advisory, but basically there was a release with a number of security fixes inside Jinx configuration as well. So here you can see four security fixes. They are mostly related to exposure of secrets in plain text to system logs and to important configurations. There was also a fix for schema and the instance specific documentation expert without administer permissions. So it's something which might be impacting Sladin's project, which we'll talk about later. And there is also one fix for exposure of secrets via re-exporting configuration YAMLs. So basically it was possible to define custom fields in the configuration. For example, if you have permissions to add a new or agent configuration, and then when I mean it was exporting the field, not checking, exporting configuration, not checking it and re-exporting it again, it was possible to access all system variables and the passwords using that. So it was also fixed. So yeah, just a few security fixes. In addition to that in this security advisory, I'll provide the Zoom panel. It's always annoying because it's on the top and hides browser windows. Okay, so in addition to these security fixes, we also had one fix in the previous version. It was 1.20. So here, basically proxy credentials. Proxy credentials is a thing you can configure in plugin manager to manage surprising the proxy, HTTP proxy across the entire Jenkins instance. So configuration is called plugin has its own or proxy configuration because we still haven't landed core patches in order to make it possible without custom patch. And apparently there was a bug before this fix because yeah, this password wasn't masked at all and needed system nodes and configuration animals. So now it's fixed. It was also announced on, what was the advisory date? It was July 31st, basically right after our meeting. And yeah, these were the fixes which were announced. Yeah, one thing to know that these fixes are breaking. So we marked the releases incompatible because you might need to review your configuration animals if there is a risk of exposed passwords or even there is a risk of variable expressions so that you need to review your configuration animals and clean up them manually. And also, if you use anonymous API access, for example, automatically validate your JSON schema, well, assuming it works, then now you need admin user permissions to do that. Okay, so yeah, it was 1.25 release. I will skip one release and probably summarize 1.27 because yeah, it was pretty quick. So it was a follow-up fix for data boundary creator which was also exposing secrets to system logs in some cases. So now it's also fixed. There was a separate advisory for that because there was a follow-up report. So we used an opportunity of the next security advisory to just fix it and close the storage with security defect and g-cast. Okay, and between these releases, we also had 1.26 release. So, King, would you like to speak about it? Sure. So one of the ones was the reducing logging level which was a lot of some of those security fixes makes it sort of a moot point for the logging ones. Before, by default, we logged it in for a level of every change we were doing. We have changed that to log it fine so you have to configure a logging rule now if you want to debug. But it means that for most cases, it's not spamming your logs and it also reduces the risk of accidentally exposing any secrets in the logs. Which is good. Logging spam is less, which is nice. Oleg has documented the YAML export feature. There was a lot of APIs that have been added at Since2Do for a long time and were never updated during the release. Mailer plug-in was a change to the Mailer plug-in back in October, I think, and the demo hadn't been refreshed since then. So someone who was using the Mailer plug-in since then has updated our demo as it was confusing. I think username and password are still unsupported, but hostname works now. Yeah, there is a pending fix for password and we probably will need to create another fix later. Yeah, I think there's an abandoned pull request as far as I know. This is number one. We have it in the backlog. It will eventually, somebody picks it up. Yeah, this one. It will rely on data binding for the contributor descriptor. So the issue with this pull request is that it uses some changes which are not in the merged job. It's a bit big for such small change. So maybe somebody will propose a simple fix later. So Nikol did a great job to prototype here. He has a job two or five, but yeah, it's pretty big. Yeah, so if anyone needs this feature, a simple pull request would be more likely to be accepted. I think is what Oleg is saying. Yeah, exactly. As a maintainer of this plugin, I will be happy to accept the project. Yeah, I haven't got to it yet and Adrian or the second maintainer also didn't have time to take a look, but yeah, eventually we will get there. I hope. I think it's also not used as much these days for emails. Remove obsolete plugin management section from different... So there was a screenshot on the readme that was confusing someone. That screenshot's been refreshed. And some maintainer. Make some code styles for IntelliJ. I've been added to the repo to make it easier for people using IntelliJ. And the pull request template's been changed so that commit messages go at the top and it reads more naturally. Exactly. Thanks a lot to Joseph for this patch. Each time I was contributing to JCASC, check style was an obstacle for me. Well, I was spending more time on fixing the issues themselves. So this fix idea users at least don't need to care about that because the integration gets picked up by default. Cool. Okay. So yeah, there was quite a number of changes, mostly quality of life and documentation, but yeah, all the changes are available to the users. There are some pending changes, but nothing really specific right now. So Joseph has spent some time in order to finally fix Codesia because for us, one of the issues was that Codesia was continuously failing for pull request. And yeah, now it's green. There's a lot of markdown issues, if I remember. So coverage is still not that good, but at least we get some metrics and get some statistics from Codesia. So yeah, which helps in the longer run. Yeah, it doesn't work on pull requests though. Like the coverage, because the pull request is untrusted, so it doesn't pass the credential for Codesia through. Well, it happens, but at least we get statistics for the master branch and then we can take it into account. Yeah. So what else do we have for the plugin? Any news? Don't think so. It's been reasonably quiet. Is there any open pull requests that have had any work done? So regarding pull request, we have quite a number of pull requests. But yeah, basically it's related to selling because it's a summer break time. Yeah, there's the hashtag called bulk code change that's coming soon. Yeah. So basically what we plan to do there, is we plan to move bulk credential, simple sources outside of the JCAST plugin. So there are a few reasons for that. Firstly, we use the bulk client address as a dependency for JCAST, which is not that natural or generic plugin. And we would rather use Jenkins plugin as a system to make it extensible. Of course, using a support bulk plugin was a natural choice because this plugin already includes all the features for bulk including, for example, a credentials provider. So yeah, that is a pen and pull request. Joseph has taken ownership of this plugin. So yeah, I think that eventually it will end. Yeah, I think it's pretty close. He's just integrating a lot of other fixes into the plugin. Yeah, there was no releases of the plugin for a while. So there was some historical depth. So you can see that seven days ago, Joseph just cut a release with all staged changes. Hopefully there was no serious regulations. We keep monitoring that, but yeah, then we need a new release which we just started with JCAST. Okay. But yeah, it's good that we revived this plugin in the process. It wasn't a dead bed, but it should be good. Yeah. We are somewhat breaking change, but easy to migrate by installing a new plugin. Yeah, but you have a history of such minor changes. So yeah, I think we can afford that if we communicate it properly. We can again market the plugin as incompatible like we did for 1.25. So yeah, I think we can easily do that. And yeah, right now we also work on plugin site improvements and support of GitHub to change logs there. So these breaking changes should become more visible to users when they update, even now they get a warning. Okay. So what else do we have in the queue? So yeah, there is a schema test by Slavin, but I think we will talk about it a bit later. And yeah, there is another request from me about just another security hardening for the plugin. And now it's rather about fixing security issues in other plugins. Because yeah, there is a number of plugins in Jenkins which you do not properly handle secrets. For example, if you take this advisory, which was released in April this year, there is quite a list of plugins. And the most of the plugins in the list is for credentials and plain text. So what it means, they basically use strings to persist the data on the list. They also usually use strings as a type in the API. And for configuration as code plugin, there is basically no way to determine that this field is supposed to be secret. So that it's supposed to be password. A Jcast plugin relies on constructors, getters, setters, fields in order to determine whether the field is secret or not to define whether it masks it. So there is a proposal to introduce additional hardening where you basically just take common phrases and suffixes like password, whatever. So this list has been created after reviews by the security team. Thanks a lot to Daniel Beck for getting some statistics from plugins. You have 20 minutes remaining. Okay. Yeah, you have 20 minutes remaining. Okay. Yeah, so basically this list is a list of suffixes and the proposal is to just thread each attribute which has the suffix as a sensitive by default, unless there is specific information that this attribute is safe to be exported. So obviously maybe a kind of breaking change again because even if we prevent common cases from being exposed, for example, if you have an attribute called pass to password or something like that, then it will be masked by a Jcast plugin by default. So there are some ways to actually opt out from this behavior. For example, you can say that the field is encrypted and encrypted fields won't be masked by default. It's useful for some secret cases and there is also sensitive fields which can be also set if needed. So basically it's a security hardening. There is no non-security vulnerabilities except these ones. And yeah, there is a proposal to just get it merged so that we have even more aggressive filtering of secrets. The downside is that it potentially causes some degressions because it's aggressive filtering and we cannot say for sure what it will break. So if anyone has something back about this food request it will be much appreciated. Okay. So any other pending changes that we need to discuss? I sent a poor question to Jenkins Core for a read-only system configuration. All right. I wanted to talk about that. It's a prototype. Just wanted feedback. Yeah, I wanted to actually work on that for the last year or so. One of the problems in Jcast that even if you apply Jcast configuration you still have full power studied from the web UI. And in many cases it's not something you would really like to have. Yeah. I want people to be able to see stuff but not change it. Yeah, right. Well, basically it applies not only to system configurations but the same applies, for example, to have an organization folder, multiple events, you don't want some configurations to be configurable from web UI. And yeah, actually this is not a first attempt to fix that and the consensus in the Jenkins community was that in addition to administer permissions you would have whatever it would only administer permission. Whatever it's called. So in my team's request it's called system read. And yeah, basically the attempt is to have some configurations controlled by this permission so that, for example, you can access administrative monitors because you don't monitor, you don't change you there unless you just miss monitors and so on. But yeah, the most important thing is of course system configuration and management things. But there are also some changes here that can make it possible. So let's make a point that changing configuration is always painful in Jenkins. But yeah, I hope that we will be able to enter this change in some sense. So here this permission is implied by admin. So it should be working out of the box if you use classic strategies. So if you use roll strategy and matrix authorization it should work by default. Obviously such changes are subject to extensive testing. Yeah, I mean it works. The only thing is it's just where there's any permission checking which is now exposed. So I think some of the administrative monitors are missing checks. Yeah, right. So I think that, yeah, so this is a long way to get this public request fully working. It's remaining. Yeah, it cannot be done in a single iteration. But yeah, I think that we should be able to measure some. And of course it needs accurate testing because some actions may be not protected because we know about some changes, for example, and fix the CSRF issues and fix the permission issues. And by granting read on the access, potentially you may introduce a security issues for some actions which are not properly protected by system admin. So we all need to be really careful with that. But yeah, it's a good change for sure. Yeah, I don't think it should affect them because otherwise if you knew the URL you'd be able to get there. Because Jenkins doesn't protect anything by default. Yeah, right. So we will be just... Adding a link to it. Yeah. But yeah, I think that it's good. I mean, at least change. And yeah, there are also more changes in the web UI. So I think we should be able to land it pretty much soon. Yeah. You said you had a comment on the previous poor request about doing it in another way, but it wasn't clear to me what he was expecting. Yeah, so basically, the last poor request just didn't work because it wasn't complete. And although many people wanted to work on the server, nobody really worked. So yeah. Yeah. And I see that it's important to get it over the line. Yeah, like if this approach is likely to be accepted, I can finish it off. Yeah. It needs poor request to some plugins as well just so that they don't look crazy, but that can be done in stages. Yeah, we'll have to do it in stages. So we probably will have to introduce, let's say, system read to EPA plugin. Yeah. So that is already fixed on the state permission plugin. So basically, we would need something like that for the new permission with some APIs. So basically, this plugin would employ reflection in order to check whether the permission is accessible or not. And if you have a similar plugin, we can target lower versions of Jenkins Core so that the plugin maintainer can start adopting it. So the biggest challenge for us is that it targets the new Jenkins Core. Yeah. It wants to be adopted by plugin maintainers. If you don't have tools for that. Yeah, yeah. Yeah, I added a question to that in the description of how to do that. Yes. My suggestion would be to just have a plugin like that with API, which targets lower Jenkins Cores. Maybe some reflection or whatever. Yeah. Then a little bit of trying. Okay. Cool. Let's just begin to slide and sorry, because I need to leave in just over 10 minutes. Okay. Yeah. Let's do that. Okay. Okay. Would you like to summarize your work? Yeah. Yeah. So I think we might run out of time there, but so I think we were discussing about the way we could actually implement some of the schema generation because they're having quite some problems with that. So some of the approaches actually we discussed were that we could have it either convert the entire thing into a, for example, we have a particular VAML file where we have all of the plugins from A to Z along with their examples and then just pass it by an API to open source library. So that was, if you, if you, if I could, if you're not sharing your screen, maybe I could. I should be sharing. Yeah. You can share your screen. Yeah. Just give me a second. One thing I just give me a second. Yeah. So let me just navigate to where I was. Okay. Quite a few tabs open. Yeah. Yeah. So we were in a few minutes. Yeah. Um, You have 10 minutes remaining. Yeah. We have 10 minutes. Okay. It's quite annoying. I've never heard that before. That might be because of a free account. Yeah. So can you see my screen? I think maybe it's because we're recording because we use it every day and Yeah. Maybe it might just stop recording after the 10 minutes. Yeah. I believe it will stop it for us. Yeah. Okay. Cool. So yeah. So one of the things that we planned to do was, can you see my screen by this? Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. And so you would take that Jason with all of these example values using using a library And then pass it Jason and get an accurate or more than accurate kind of a schema. So the one that currently Jason schema dot net provides us with Um, a sort of, a sort of way that I don't think you have seen it. Yeah. So if you have a look at this screen here. Yeah. So if you give it a particular Jason you would get a pretty, pretty accurate Jason schema. json schema okay so yeah so we would get our json schema like this but the problem in this was we would need to actually fill every single every single run every single value in the credential in our particular and then then have it uploaded so so we kind of eliminated this option the other option that we kind of discussed was yeah this one the one where we where we convert the schema class dynamically now that's that's very very difficult because as far as I read about it it involves bit manipulation and stuff to convert to write a class on its own that would be I mean that would be hazardous because then we would have to construct the subclasses and that's kind of very difficult so so that that was that was out as well so I think the last approach that we recently discussed was this one yeah the one way we actually use the VAML export so I think Tim thought he would explain it to me I think I think you would you are going to I think I mean how exactly are we going to use that I tried skipping through it by a debugger I went through the entire like code of the VAML export and stuff so yeah so I did go through it and if I'm not wrong does a node actually hold an attribute value is it because as far as I see it has some sort of a mapping right yeah it holds an odd yeah so it holds a little every single every single one in the in the VAML file for example 2 bar whatever it will hold up key and the value yeah yeah yeah so exactly how you I think we were discussing on exactly how we could use this in the in generating this key so I think if you could elaborate that would be cool yeah I mean I could it's probably easiest to walk through from the top how the code works a little bit but the base bit is that this is a slightly different from this is a bit different from the export and that exports looking for values to get in the types in the export them or is here we just want all of the potential ones but I think code should be reasonably similar and maybe if I share if I open it up and share my screen for a little bit yeah yeah sure one thing and I just I just stop yeah by the way 10 the 14 minutes limit has been removed so you have more time I think you get that one time I'm just trying to find it here we go shit you cool you should be able to see it yeah okay so for this one it's useful just to start at the top so this is where the web UI comes in for export one thing to be familiar with is the root element configurators so you will have seen a few different route elements you'll see Jenkins security credentials tools and unclassified five minutes remaining unclassified means it's not in another category but these are there is a global configuration category in Jenkins core where I think there's an annotation or part of your extension that you can say that you belong to a category and if you don't do anything then you end up in the unclassified category so if you go to this is a Jenkins core class and these are the ones configured in the default it's unclassified in security it's an extension point as well so yeah tools and credentials come in by the extension point so that's good to be familiar with and the day global configuration category configurator in configuration is code plugin and that will configure that config is all of the categories it runs a so this is the just so this is describe we do filter we filter some descriptors out I think okay we filter one descriptor out so this is a hack to remove a credentials provider manager that just doesn't really fit in we tried to fix it properly but it was just a bit too confusing so there's a little hack here at the top to remove dodgy descriptors that don't work too well with how I set up is we report some things we can't handle and then we run we run a descriptor configurator over it I've not really looked at this one before okay so basically yeah this is it's picking up from the file right whatever whatever descriptor you have for example Docker API whatever you are is that right because yeah as far as I seen it does go through the entire so this bit here looks like it's just trying to try to map a symbol to a descriptor and it's also to add a patch so that we look them up case and sensitively so it doesn't matter how people pass pass their symbol name in the email file they can do in the case of slap and do slack notify or lower case uppercase camel case yeah so just to make it a bit more flexible good so after your configurator you have the configuration context I think so target components right so yeah we have a few different configurators and some custom configurators as well so these are the custom configuration configurators that are coming up here I think so the main configurators are the data-bound configurator and the primitive configurator that's where most of the work is done so the data-bound is this is the standard setup where you've got a data-bound constructor and data-bound setters so here we look up a constructor using reflection you have only one minute remaining no pressure yeah no pressure yeah right and this is quite a important bit we're using the parameter names and the constructor so we've got all the fields here but I mean basically the idea is that we have these APIs here already for introspecting the classes and you'd be able to from here construct the field names and types so basically if I so for example if it's a credentials plugin or maybe yeah maybe take the Docker plugin or whatever so maybe it has a single it has subclasses right so for example if I wanted to access the Docker API and accept the URI so that would it would have more than one indentation right so how is that how is that handle here I mean I think there was an example I put in the data chat right so if it has indentation how is that manageable? So with subclasses you need to add a symbol which says which one you want to use if there's multiple limitations so in these your VM agents plugin you've got you've got multiple different retention strategies for how you want the VMs to be kept you've got like run once you've got keep around for 60 minutes and you've got never delete and each of those have got a symbol and so you need to you have to add another field in the ammo one line down saying which which type that you want okay I think you always specify for the subclass if you've got different options I'm probably running out of time here if you've got any thoughts Oleg? I think it's fine also yeah this description is quite complicated yeah yeah because you use existing frameworks it should help us and we are taking the experience with the recent security fixes we can probably start refactoring this code maybe moving common methods and common common tweaks to utility classes so it might help in the future but yeah right now just utilize what you have and there is no objective to make JSON schemas ideal after the first iteration you know if you just know for some baby steps and it would be better for us yeah even just start with instructor parameters and ignore optional parameters maybe yeah yeah I think maybe we can get that done cool you just reach out and get a yeah yeah definitely I've got to go now yeah cool thanks guys thank you thank you so much okay so next week I hope if you schedule everything yeah yeah cool okay yeah thank you so much thank you Tom bye