2023-06-21T16:00:00Z
Jun 21, 2023
- Attending
- Mark Waite
- Wadeck Follonier
- Cristina Pizzagalli
- Basil Crow
- Alexander Brandes
- Antoine Neveux
- Bruno Verachten
- Kevin Martens
- Topics
- What’s happened recently in UI improvements
- Prototype.js removal has started - lots of work to do in many small steps
- Prototype.js references removed from core since 2.406
- Ships Prototype.js in core for plugins
- Plugins tracking sheet shows progress
- Blog post shows contributors how to do the work
- Many of the issues are small, well suited to new contributors
- Continue recommending to new contributors
- Prototype.js references removed from core since 2.406
- Delete dialog becoming a modal inside page thanks to Markus Winter
- PR 7938 reviews and comments look good
- UI improvement pull requests from Jan Faracik
- Ongoing discussions in pull requests
- Other pull requests in progress from Markus Winter
- CSS compilation and compatibility with HTMLUnit 3
- Transpiler was able to convert newer CSS syntax to a form that is understood by HTMLUnit
- Modernize CSS without breaking HTMLUnit
- Media feature range notation that may be usable elsewhere
- Already using Babel transpiler for JavaScript
- Compared generated CSS and confirmed it was the same
- New syntax transpiles to current syntax
- Two pull requests, need review and approval
- The
has
pseudo notation can’t be transpiled (polyfill)- Removing
has
reduces test noise
- Removing
- Requires both CSS and JavaScript
- JavaScript did not work in HTMLUnit 3
- Likely more exceptional than the common case
- The
- No issues detected with pure CSS, general technique
- Already using SCSS with postcss
- Currently compiles SCSS to intermediate postcss then postcss compiles intermediary to CSS
- Prototype.js removal has started - lots of work to do in many small steps
- Next LTS baseline will be chosen in 3 weeks (July 12, 2023)
- 2.414 likely releases that week, 2.413 likely the week before
- Temporary expansion of the scope for the security audit requirement
- A vulnerability was corrected as a (positive) side effect from a JavaScript PR about Prototype.js removal
- The security team discovered that afterwards when preparing backports
- Reference: advisory/2023-06-14/#SECURITY-3135
- Awareness / information sharing about the associated cost of a security release
- The cost factor between providing a fix as an advisory versus within the PR before merge, is easily 20+x (just for the security team)
- The preparation for a Jenkins Core security release has additional constraints in terms of coordination between the private fixes and the public backports (or latest weekly)
- Multiple data to prepare for the security team (between advisory content per se, but also what to merge, in which order)
- Also, the fixes have to be prepared for both weekly and LTS
- Sometimes that is more invisible for the contributor, it’s the incurred cost for user of Jenkins
- Having vulnerabilities, means that some companies prevent production deployment, leading to “urgent” update
- Compared to a non-security LTS, where the adoption depends on the features
- Security scanners are complaining about CVEs (as a bonus)
- The idea here is to expand the scope of what kind of PRs require a security review.
- Originally it was “UI related” changes, here it’s more about anything touching JavaScript / Jelly (/ HTML)
- That scope expansion will be done during a 2 months period, as a time box effort, to provide information and see if there is any utility to audit those parts
- To compensate for the potential impact on collaboration speed, the Security team will increase the frequency of checking if there is something pending, from 1x per week to 3x per week, to reduce the likelihood of slowing down development. Usually the team members are looking proactively at open PRs.
- If you have a particular project in mind that will require quicker reaction, open a discussion and we will put more effort to audit the PRs more quickly.
- Add the
needs-security-review
label as first step, if that’s not enough, then mention the security team
- Why only JS/Jelly? Usually the backend security in Jenkins is more widely known and thus risks are lower.
- Since the introduction of the “policy”, we have seen a nice list of vulnerabilities that were detected before the merge and thus, reducing drastically the need for “Core security releases” which are pretty expensive.
- Just to make it explicit, the security team is more than happy to be pinged on a PR where you have a doubt, to help review the code. It’s not limited to JavaScript or UI.
- Two month expansion of scope, then removed
- Share what we learn during those two months
- Agreed, proceed as proposed
- A vulnerability was corrected as a (positive) side effect from a JavaScript PR about Prototype.js removal
- Improve keyboard usability - Cristina Pizzagalli
- Big three blockers are cleared
- Asked to create tickets for audit items
- See Loading...
- Some pull requests are already in progress to address keyboard use
- Cristina willing to create the individual issues in Jira to track the details
- Individual issues are much easier to get specific help
- Issues · jenkinsci/jenkins · GitHub is the label
- Big three blockers are cleared
- Notifying users of operating system end of life - Mark Waite
- Included in 2.407 changelog, blog post, tweet, and LinkedIn
- Discussions in the community forum
- PR merged for the 2.401.2 LTS (28 June 2023)
- Approved exception to usual LTS backport policy
- Included in 2.407 changelog, blog post, tweet, and LinkedIn
- What’s happened recently in UI improvements