Hey Wadeck, > until they have received at least one approval from someone in CERT.
Could we add a "security" team with read permissions on jenkinsci/jenkins, core maintainers can request a review upon if a PR touches UI components? I'm aware that Basil (?) created a label, but GitHub honors submitted reviews from team members, if requested. Not every contributor may know every CERT member, but feedback submitted on behalf of a team gets special attribution, see https://github.com/jenkinsci/packaging/pull/320 for an example, to differentiate between regular reviews and explicit reviews. Cheers Alex On Wednesday, 22 June 2022 at 19:58:32 UTC+2 [email protected] wrote: > Hi Wadeck > > We can monitor this in the short term. > My concern would be around responsiveness and turn around time. > > RPU hosting requests already can take a fair amount of time if there’s a > few at a time > > It already takes a long time to get some of the UI pull requests in. As > long as the security team are in early and actively reviewing, (and that > means looking at all the pull requests currently active) too then fine. > > We already have a big backlog of pull requests that we were asked to hold > off on the last few weeks due to the security release, so if these could be > looked at ASAP then that would be great. > > Let’s add this as an agenda item for the next UX sig meeting to review how > it’s going > > Thanks > Tim > > On Wed, 22 Jun 2022 at 18:37, '[email protected]' via Jenkins > Developers <[email protected]> wrote: > >> Today the Jenkins project released a security version >> <https://www.jenkins.io/security/advisory/2022-06-22/> that contains >> several high severity vulnerabilities. Five vulnerabilities from Jenkins >> core were introduced very recently during UI improvement work. >> >> Such security issues discovered after a merge implies that we are >> investing a lot of energy/time to correct it and providing all the >> necessary data in terms of vulnerability management. The difference between >> finding them during review and after a release is really huge. >> >> For this reason, as the security officer and effective as of today, I >> want to block the merge of any UI-related PRs until they have received at >> least one approval from someone in CERT. >> >> To set expectations, if a PR is approved but then substantial change is >> committed, the approval must be dismissed and re-requested. The second >> approval is expected to be quicker. >> >> This process is expected to provide better security coverage of the >> upcoming changes and thus, reducing the likelihood of introducing >> vulnerabilities. >> >> In order to not be a blocker for the UI improvement project, I will >> assign more people from my team to review the PRs. The job done by the UI >> team is amazing and should continue. >> >> This new policy will be revised over time and ideally removed in the >> mid-term. >> >> Do you have any concerns related to this? >> >> Wadeck Follonier >> >> Security Officer >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Jenkins Developers" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/jenkinsci-dev/7846d76d-2bc0-4829-a4a2-d9035e10592fn%40googlegroups.com >> >> <https://groups.google.com/d/msgid/jenkinsci-dev/7846d76d-2bc0-4829-a4a2-d9035e10592fn%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/6b7471a0-f8f7-4613-a66a-ecb4fae7fd77n%40googlegroups.com.
