Re: [Proposal] Remove "hacktoberfest" topic from all jenkinsci repositories

['wfoll...@cloudbees.com' via Jenkins Developers]

Great, "more" work on the maintainer but it will be explicit opt-in, +1

On Thursday, September 12, 2024 at 10:08:58 AM UTC+2 bma...@gmail.com wrote:

> Great idea, makes sense to me. It should also reduce the risk that some 
> participants never receive feedback on a PR submitted on a since-abandoned 
> plugin.
>
> Le mer. 11 sept. 2024 à 23:25, 'Darin Pope' via Jenkins Developers <
> jenkin...@googlegroups.com> a écrit :
>
>> In preparation for Hacktoberfest 2024, I'm proposing that the existing 
>> "hacktoberfest" topic be removed from all repositories in the jenkinsci 
>> organization. Why? That way each maintainer can decide whether or not they 
>> want to participate in the current year Hacktoberfest or not. 
>>
>> This will also remove the topic from repositories that currently don't 
>> have active maintainer(s).
>>
>> Yes, this means that a maintainer will need to add the topic back if they 
>> want to participate, but I think doing a cleanup each September 
>> ("Preptember" in Hacktoberfest lingo) in preparation will assist in what 
>> the developer relations team will be doing for promotion.
>>
>> Thanks,
>>
>> Darin
>>
>> -- 
>> 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 jenkinsci-de...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/jenkinsci-dev/14e96b24-83d4-481c-9d7d-b6963d3807a3n%40googlegroups.com
>>  
>> 
>> .
>>
>

-- 
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 jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/7918d132-1198-4283-80d4-9d8d2ef0620cn%40googlegroups.com.

Re: CVE-2023-50164 Struts question

['wfoll...@cloudbees.com' via Jenkins Developers]

Hello Randall,

If it's for a single plugin, the easiest way is to use `mvn 
dependency:tree` to check if you are using Struts or not. Usually if you 
include Struts indirectly (through transitive dependencies) there is low 
likelihood that you are effectively using it. Most of the Jenkins plugins 
are using only Stapler for their HTTP request handling, without any other 
framework (like Struts).

If you want to know about an instance of Jenkins with its plugins, I would 
recommend to use a regular security scanner (SCA) to see if they are 
finding anything there.

Now, if you are not sure, you can still contact the security team, but I 
will ask you to provide more details, like which plugin, which CVE, and 
your doubts.

Best regards,

Wadeck Follonier
Jenkins Security officer

On Thursday, December 21, 2023 at 7:12:21 PM UTC+1 m...@basilcrow.com wrote:

> My unofficial answer: Jenkins uses Stapler as its web framework (not
> Struts), so I strongly suspect there are zero Jenkins plugins
> distributed on our Update Center that bundle Struts 2 or 3. For an
> official answer, contact the Security Team at:
>
> https://www.jenkins.io/security/team/
>

-- 
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 jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/e1eb3d9b-ead5-48a8-95c5-8ec83bcafaean%40googlegroups.com.

Re: [Information] Release block "Beta" program

['wfoll...@cloudbees.com' via Jenkins Developers]

The trade-off is more than "limited" from my PoV. Knowing we are publishing 
an advisory in general means that if you want to look for vulnerabilities, 
you have to search in 1800+ plugins, i.e. there is no advantage to know it. 
With the information we provide, meaning the popularity of the plugin, we 
still limit the scope to 100s of plugins.
If a branch is locked, that could provide information to some actors to 
look deeply in that plugin in particular. With such scope, the search is a 
lot simpler.

The locking being visible makes the "any reason" not really an argument 
from my PoV. Usually you apply branch protection but you do not lock your 
main/master branch completely. By watching the repositories, anyone is able 
to see changes and thus can act on them.

Also, the branch locking alone, will not provide a big defense against 
incident, if we let the maintainers with their admin permission, as they 
can just imagine it was an error from another maintainer and just decide to 
unlock the branch.

>  you weren't involved in the actual security fix
That's the idea with the advisories, to inform co-maintainer, even if they 
have not opened any SECURITY ticket. That information is available on the 
repository as well. The only caveat is the current GitHub UI does not 
display advisories in the tab, you have to use the proposed extension or 
any other mechanism for that.

Adding the branch protection mechanism as an option of the locking could be 
interesting to dig deeper. At this point I have not looked at that part of 
the API (https://docs.github.com/en/rest/branches/branch-protection).

I would like to get more opinions on the topic before investing time on it 
as the current version seems to be satifsactory for the beta testers.

On Wednesday, September 6, 2023 at 1:51:18 PM UTC+2 timja...@gmail.com 
wrote:

> On Wed, 6 Sept 2023 at 12:42, 'wfoll...@cloudbees.com' via Jenkins 
> Developers  wrote:
>
>> Last time we tested, the branch locking has the problem to be visible for 
>> anyone. This means that you can guess which plugin will receive an advisory 
>> soon.
>
>
> It could be locked for any reason, and personally I would say the 
> trade-off of the _very_ limited information is worth it here.
>  
>
>> The feature usage is up to the maintainers, like it's too limited for 
>> them, they can just communicate with their co-maintainers to ensure the 
>> master/main branch will not updated and no other releases are done.
>>
>
> I have multiple times merged pull requests on plugins that are staged, 
> with or without co-maintainers, it's really not something that's easy to 
> keep track of when you maintain more than one plugin, especially when it 
> happens a week or two after staging, and even more especially when you 
> weren't involved in the actual security fix.
>  
>
>> For the bots, that's pretty interesting, I haven't thought about the 
>> fully automatic flow there.
>>
>> On Tuesday, September 5, 2023 at 11:51:58 PM UTC+2 timja...@gmail.com 
>> wrote:
>>
>>> Also this won’t work with any bots that can auto merge when CI checks 
>>> pass, e.g. renovate and dependabot, whereas a locked branch will work.
>>>
>>> On Tue, 5 Sep 2023 at 17:48, Tim Jacomb  wrote:
>>>
>>>> Why not lock the branch instead?
>>>> That means it won’t break review approvals in the meantime and things 
>>>> like enabling auto merge for when the release block is over
>>>>
>>>> On Tue, 5 Sep 2023 at 17:13, 'wfoll...@cloudbees.com' via Jenkins 
>>>> Developers  wrote:
>>>>
>>>>> Dear plugin maintainers,
>>>>>
>>>>> *Context*
>>>>> In situations where the security team is collaborating with plugin 
>>>>> maintainers on a coordinated release, the artifacts are staged and 
>>>>> commits/tags are pushed to a designated private repository.
>>>>>
>>>>> However, challenges arise when multiple maintainers are simultaneously 
>>>>> working on the same plugin. Coordinating these efforts becomes crucial. 
>>>>> If 
>>>>> another maintainer merges pull requests or releases a new version of the 
>>>>> plugin while a coordinated security release is pending, it necessitates 
>>>>> re-staging the artifacts. Depending on the timing of such occurrences in 
>>>>> relation to the release schedule, it can create unnecessary urgency and 
>>>>> often result in time wasted.
>>>>>
>>>>> *Objectives*
>>>>> We want to have a way to inform the p

Re: [Information] Release block "Beta" program

['wfoll...@cloudbees.com' via Jenkins Developers]

Last time we tested, the branch locking has the problem to be visible for 
anyone. This means that you can guess which plugin will receive an advisory 
soon.

The feature usage is up to the maintainers, like it's too limited for them, 
they can just communicate with their co-maintainers to ensure the 
master/main branch will not updated and no other releases are done.

For the bots, that's pretty interesting, I haven't thought about the fully 
automatic flow there.

On Tuesday, September 5, 2023 at 11:51:58 PM UTC+2 timja...@gmail.com wrote:

> Also this won’t work with any bots that can auto merge when CI checks 
> pass, e.g. renovate and dependabot, whereas a locked branch will work.
>
> On Tue, 5 Sep 2023 at 17:48, Tim Jacomb  wrote:
>
>> Why not lock the branch instead?
>> That means it won’t break review approvals in the meantime and things 
>> like enabling auto merge for when the release block is over
>>
>> On Tue, 5 Sep 2023 at 17:13, 'wfoll...@cloudbees.com' via Jenkins 
>> Developers  wrote:
>>
>>> Dear plugin maintainers,
>>>
>>> *Context*
>>> In situations where the security team is collaborating with plugin 
>>> maintainers on a coordinated release, the artifacts are staged and 
>>> commits/tags are pushed to a designated private repository.
>>>
>>> However, challenges arise when multiple maintainers are simultaneously 
>>> working on the same plugin. Coordinating these efforts becomes crucial. If 
>>> another maintainer merges pull requests or releases a new version of the 
>>> plugin while a coordinated security release is pending, it necessitates 
>>> re-staging the artifacts. Depending on the timing of such occurrences in 
>>> relation to the release schedule, it can create unnecessary urgency and 
>>> often result in time wasted.
>>>
>>> *Objectives*
>>> We want to have a way to inform the plugin maintainers while not 
>>> revealing specific details about the advisory in advance.
>>>
>>> *Current solution*
>>> We've implemented an automation solution for your convenience. You can 
>>> now trigger this automation by simply commenting "/block-release" in the 
>>> SECURITY ticket assigned to you. This action will reduce GitHub permissions 
>>> for contributors to "Triage”. At the same time, a GitHub advisory will be 
>>> created, with contributors included as "Collaborators," allowing them to 
>>> view the advisory and receive a notification.
>>>
>>>
>>> Once the release is completed, the security team will promptly remove 
>>> the block. You can also initiate the removal by commenting 
>>> "/unblock-release" in the same SECURITY ticket.
>>>
>>> *Known limitations*
>>>
>>>- Our automation cannot prevent all incidents but aims to cover most 
>>>cases.
>>>- For vulnerabilities affecting multiple plugins, the security team 
>>>has to be involved to widen the scope of the block.
>>>- Some corner cases like users with "org owner" permissions in 
>>>GitHub or Administer permission on ci.jenkins.io are still able to 
>>>perform actions that could make the staged artifacts no longer valid.
>>>
>>>
>>> *Browser extension option*
>>> If you’re a GitHub “org owner” and want to easily see if there is a 
>>> pending advisory in the current repository you are browsing, you may find 
>>> this browser extension valuable: 
>>> https://github.com/Wadeck/extension-jenkins-security.
>>>
>>> This automation was tested already multiple times in a closed beta way, 
>>> and now we are opening the beta to anyone interested. After some iterations 
>>> we will call it GA but still welcome any feedback.
>>>
>>> Wadeck Follonier
>>>
>>> Jenkins 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 jenkinsci-de...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/jenkinsci-dev/2ffd0261-6682-4c67-b5ca-0f29c97ecbadn%40googlegroups.com
>>>  
>>> <https://groups.google.com/d/msgid/jenkinsci-dev/2ffd0261-6682-4c67-b5ca-0f29c97ecbadn%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 jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/52394464-6d3e-4f35-a188-9c88d5ad7d92n%40googlegroups.com.

Re: Removing inactive CERT members to reduce risk

['wfoll...@cloudbees.com' via Jenkins Developers]

To come back to the previous topic, what you have mentioned / proposed, is 
a long term approach requiring additional changes / setting expectations / 
getting agrements. It's just not in the current scope of the changes I want 
to make. I prefer to have an incremental approach that provides value right 
now instead of waiting on a larger effort that will provide value only 
later in the future.

FTR that was explained 
in https://groups.google.com/g/jenkinsci-dev/c/8cy8w7ZqyB8/m/K6sdE_HcEAAJ.
> Starting small and increasing the scope over time. CERT membership and 
VPN/infra access will follow soon.

If you think your proposal should be implemented, I would suggest you to 
start a new thread, as it's beyond the original scopes of the existing ones.


On Tuesday, July 18, 2023 at 4:59:19 PM UTC+2 m...@basilcrow.com wrote:

> On Tue, Jul 18, 2023 at 1:05 AM 'wfoll...@cloudbees.com' via Jenkins
> Developers  wrote:
> > Your proposal about a more extreme approach was discussed and rejected.
>
> But not with a valid justification.
>
> > that discussion seemed to be sterile from my PoV
>
> I fail to see how that discussion is sterile. Neither of the arguments
> in my last post to that thread had been raised previously.
>

-- 
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 jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/160252b4-f1f2-446a-802c-aeb80693c67an%40googlegroups.com.

Re: Removing inactive CERT members to reduce risk

['wfoll...@cloudbees.com' via Jenkins Developers]

Security is often a balancing act, to improve the security situation while 
not impeding too much on others.

Your proposal about a more extreme approach was discussed and rejected. 
Your latest message was read but as that discussion seemed to be sterile 
from my PoV, I preferred to move forward.

On Monday, July 17, 2023 at 8:19:40 PM UTC+2 m...@basilcrow.com wrote:

> On Fri, Jul 14, 2023 at 6:55 AM 'wfoll...@cloudbees.com' via Jenkins
> Developers  wrote:
> >
> > This email is a continuation of 
> https://groups.google.com/g/jenkinsci-dev/c/8cy8w7ZqyB8/m/eZfaenQzEAAJ.
>
> Is it a continuation if the last post to that thread remains 
> unacknowledged?
>

-- 
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 jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/c4dd8b99-0051-4e93-9d1e-bf5036045712n%40googlegroups.com.

Removing inactive CERT members to reduce risk

['wfoll...@cloudbees.com' via Jenkins Developers]

Hello everyone,

This email is a continuation of 
https://groups.google.com/g/jenkinsci-dev/c/8cy8w7ZqyB8/m/eZfaenQzEAAJ.

The "CERT" (= Security team) has access to some confidential information 
like not-yet-disclosed vulnerabilities, which fixes are in progress, 
internal discussions about problems to solve, etc. 

Several members of this team have been inactive for a long time, some of 
them multiple years. Those unused permissions are a risk to the project, 
due to phishing campaigns or accidental screen sharing for examples.

During my search I differentiated the people working on a particular plugin 
fix and the ones that are actively contributing to the security globally. 
Nothing changed for plugin maintainers who will still receive specific 
access to their own scope.

The impact is on permissions in GitHub, in Jira and the 
jenkinsci-c...@googlegroups.com, where some had access to one but not the 
other.

Thanks everyone for your past contributions, and you’re of course welcome 
back any time :)

For transparency and future reference, here is the list of people who are 
at least partially affected:

   - Beatriz Muñoz
   - Jeff Thompson
   - Kohsuke Kawaguchi
   - Oleg Nenashev
   - Olivier Vernin
   - Matt Sicker
   - R. Tyler Croy
   - Raúl Arabaolaza Barquin

Best regards,

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 jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/56090ebe-de00-4c3b-876f-c6858e8b46e9n%40googlegroups.com.

Re: Requesting admin access to the jenkinsci GitHub organization

['wfoll...@cloudbees.com' via Jenkins Developers]

+1

On Tuesday, June 6, 2023 at 10:36:39 AM UTC+2 Adrien Lecharpentier wrote:

> +1 as well from me.
>
> Le mar. 6 juin 2023, 10:15, Baptiste Mathus  a écrit :
>
>> +1.
>>
>> Le lun. 5 juin 2023 à 19:33, Srikanth Jana  a 
>> écrit :
>>
>>> +1 from me
>>>
>>> On Mon, Jun 5, 2023 at 11:01 PM Alexander Brandes  
>>> wrote:
>>>
 +1 for Basil 

 On Mon 5. Jun 2023 at 19:30, Mark Waite  wrote:

>
>
> On Monday, June 5, 2023 at 11:29:18 AM UTC-6 m Basil Crow wrote:
>
> I would like to become an organization administrator of the jenkinsci 
> GitHub organization. This would facilitate various efforts I am 
> involved with, such as repository transfers.
>
>
> +1 from me. 
>
> -- 
> 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 jenkinsci-de...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-dev/78809aba-d9ca-4d43-98bf-858811577121n%40googlegroups.com
>  
> 
> .
>
 -- 
 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 jenkinsci-de...@googlegroups.com.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/jenkinsci-dev/CAP9joaGh28MKR0jSRptwGGhnAKNn_7C8W2aTQVgzpqmsyjtgeQ%40mail.gmail.com
  
 
 .

>>> -- 
>>> 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 jenkinsci-de...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/jenkinsci-dev/CAJxAiNDnHRF5BRtESwKfdsmH9pi698V24TjXTMPXCTfOEUmK4Q%40mail.gmail.com
>>>  
>>> 
>>> .
>>>
>> -- 
>> 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 jenkinsci-de...@googlegroups.com.
>>
> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/jenkinsci-dev/CANWgJS7QcnLsR4ZRR5tU9y6fWsQ2dKP2xdGCpx84V44ga3xhAg%40mail.gmail.com
>>  
>> 
>> .
>>
>

-- 
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 jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/84f3cd9d-81c0-420f-b7c6-663d6145d271n%40googlegroups.com.

Re: Requesting Admin access to the jenkinsci organization

['wfoll...@cloudbees.com' via Jenkins Developers]

+1

Thanks Alex for your continued effort in the project :-)

On Monday, June 5, 2023 at 1:15:42 PM UTC+2 timja...@gmail.com wrote:

> +1 
>
> On Mon, 5 Jun 2023 at 10:05, Ullrich Hafner  wrote:
>
>> +1 from me
>>
>> Am 05.06.2023 um 09:50 schrieb Alexander Brandes :
>>
>> Hey everyone,
>>
>> I would like to increase my involvement within the Jenkins project beyond 
>> a maintainer scope, and would like to request admin access to the jenkinsci 
>> GitHub organization.
>>
>> Besides my seat on the Jenkins governance board, I am one of the core 
>> maintainers within the jenkinsci GitHub organization.
>> The recent sponsorship of the project coming from GitHub and the adoption 
>> of enterprise features, like autolink references you can find in core 
>> repositories already, are one of the examples of my work, which wouldn't be 
>> possible without me bothering Tim Jacomb constantly to click the right 
>> buttons for me.
>> I have admin access to various core component and plugin repositories 
>> within the jenkinsci organization, plus the jenkins-infra organization, 
>> including jenkins.io or the plugin site. Having admin permissions in the 
>> jenkinsci organization would allow me to help to facilitate contributions 
>> of these kinds to the Jenkins project.
>>
>> My GitHub account is configured securely, and I have an ICLA signed.
>>
>> Would the project be fine with such a request?
>> Thanks in advance,
>> Alexander Brandes
>>
>> -- 
>> 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 jenkinsci-de...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/jenkinsci-dev/CAP9joaHYsQEvPKLQpxdWPW_OR92O98F8Xt1AWMyDsO-03tYiQg%40mail.gmail.com
>>  
>> 
>> .
>>
>>
>> -- 
>> 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 jenkinsci-de...@googlegroups.com.
>>
> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/jenkinsci-dev/E1D85BB2-8BC6-4346-B134-5035E20B4B32%40gmail.com
>>  
>> 
>> .
>>
>

-- 
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 jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/36608b06-f9b8-4c2d-9b4b-6b2801f9428fn%40googlegroups.com.

Hosting request - Update on the security audit part

['wfoll...@cloudbees.com' via Jenkins Developers]

Hello there,

To give you a bit of context, let me give you my definition of the return 
on investment (ROI) for the security team. I consider the investment mainly 
as time and task difficulty. For the value, it's mainly the number of users 
receiving a more secure application.

Directly from this, when the team is spending one day auditing a plugin 
with 100k installations, or one with less than 1k, the ROI is completely 
different.

Since ~one year, the security team was directly involved in the auditing of 
the plugin hosting requests on 
https://github.com/jenkins-infra/repository-permissions-updater/. As I want 
to optimize the effort dedicated by the team in the tasks with good ROI, 
the team invested some time implementing bot commands to ease the process.

I am writing this message to tell you that since some minutes ago, we are 
starting sort of a beta of a new automation on the hosting request process. 
When a hosting request is created, a security scan will be performed on the 
candidate repository. If there are findings (including false positives), 
the author is requested to either correct them, justify them or provide a 
suppression. The security scan can be re-triggered using a command 
(/request-security-scan).
Ideally this automation should cover the previously manual audit. The 
review of the audit report / justifications is still undefined.

The security team will carefully observe the automation to ensure it's 
working as expected and provide the desired value.

With this initiative, I hope the security team will be able to provide more 
value to the project as a whole.

Best regards,

Wadeck

PS: We are keeping a very generic name for the "Security scan" even if it's 
based on the CodeQL rules that Daniel introduced some time ago. The idea 
behind this is to not bind ourselves to a single tool.

-- 
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 jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/513bfad2-721d-43dc-a01f-828cfa02ee5bn%40googlegroups.com.

Re: Removing inactive Core maintainers to reduce risk

['wfoll...@cloudbees.com' via Jenkins Developers]

> [...] jenkinsci/inactive-core-maintainers [...]
+1 for the idea

And thanks for providing additional rationales behind the approach.

For Basil:
As it's about reducing the risk and not eliminating it, the approach was 
voluntarily not aggressive.
If you want to have a stricter / more aggressive approach, from my PoV it's 
another topic with harder consensus to find.



On Monday, January 30, 2023 at 9:12:00 PM UTC+1 db...@cloudbees.com wrote:

> On Mon, Jan 30, 2023 at 7:26 PM Basil Crow  wrote:
>
>> A compromised account with unnecessary commit access could very well
>> have that level of impact if it is used to introduce malicious content
>> into a release.
>>
>
> Exactly, which is why this was done.
>
> As a reminder, you originally responded to an explanation why this wasn't 
> discussed more widely before this was implemented.
>

-- 
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 jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/2fb769af-d0f2-4288-99de-d79848624993n%40googlegroups.com.

Re: Removing inactive Core maintainers to reduce risk

['wfoll...@cloudbees.com' via Jenkins Developers]

>  By the same logic, we could dispense with core PR reviews because any 
commit can be reverted without problems
You're going on the extreme there. A PR merged in a release can be 
installed. A missing permission is not at that kind of level of impact.

> [...] witch hunt [...]
To explicit my thinking process there that will also reply to the other 
comments.
I do not want to put a clock ticking above the heads of any role, that 
would notify you "hey you have not merged a PR since 11 months, in 30 days 
you will be kicked". That's neither the goal nor the intent.

> [...] I think it should’ve been discussed on the mailing list publicly
For the CERT list, I will post a message in the mailing list before 
removing the inactive users.

On Sunday, January 29, 2023 at 8:53:27 PM UTC+1 m...@basilcrow.com wrote:

> On Sun, Jan 29, 2023 at 4:52 AM 'wfoll...@cloudbees.com' via Jenkins
> Developers  wrote:
> > Thanks for the positive feedback!
>
> It was positive feedback about the intention, not necessarily the end 
> result.
>
> > [To] widen the discussion before the act did not seem necessary. 
> Especially when such a change can be reversed without problems.
>
> By the same logic, we could dispense with core PR reviews because any
> commit can be reverted without problems. Such an approach would appear
> to go against the consensus-driven nature of the project.
>
> > Concerning the activities, the remaining people did at least a PR review 
> during the last year.
>
> That would make those people eligible to be members of the
> core-pr-reviewers team, which has triage permissions but not write
> permissions. Eligible members of the core team, which has write
> permissions, would be those who have merged or closed a PR during the
> last year. Can you see a flaw in my reasoning?
>
> > This is not strictly requiring the write permission, but I don't want to 
> do something that could be seen as a witch hunt.
>
> I do not see how it could be seen as that given the explicitly stated
> goal (reducing the risk of security exposure), which has been
> discussed transparently in this public thread.
>
> > This kind of risk reduction was rarely done in the past, I don't want to 
> be too aggressive on that.
>
> On the contrary, the fact that this kind of risk reduction was rarely
> done in the past is all the more reason to act deliberately,
> conciliarly, and thoroughly in the present: past precedent shows that
> our decision is likely to stick for a long time.
>

-- 
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 jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/b9083814-3598-4aef-af0b-de7baeb15827n%40googlegroups.com.

Re: Removing inactive Core maintainers to reduce risk

['wfoll...@cloudbees.com' via Jenkins Developers]

Thanks for the positive feedback!

>  we decided
Decision was made between Damien and me.
It was discussed with a few other people and as we got mainly just ultra 
positive response, widen the discussion before the act did not seem 
necessary. Especially when such a change can be reversed without problems.

Concerning the activities, the remaining people did at least a PR review 
during the last year. This is not strictly requiring the write permission, 
but I don't want to do something that could be seen as a witch hunt. 
This kind of risk reduction was rarely done in the past, I don't want to be 
too aggressive on that. Starting small and increasing the scope over time. 
CERT membership and VPN/infra access will follow soon.

Wadeck

On Saturday, January 28, 2023 at 9:59:24 AM UTC+1 mc.ca...@gmail.com wrote:

> Thanks for your ongoing efforts to make our repositories secure!
>
> > Was this decision made in concert with other core maintainers
>
> I was not aware of such a change, but I heavily endorse the cleanup :)
>
> Alex
>
> On Friday, 27 January 2023 at 16:59:41 UTC+1 m...@basilcrow.com wrote:
>
>> On Fri, Jan 27, 2023 at 1:06 AM 'wfoll...@cloudbees.com' via Jenkins 
>> Developers  wrote: 
>> > 
>> > For that reason we have decided to remove inactive contributors from 
>> the ‘core’ team. 
>>
>> Thanks! Strongly agree that this is a great move. 
>>
>> > we decided 
>>
>> Was this decision made in concert with other core maintainers or 
>> unilaterally? 
>>
>> > one year without any activity in the affected repositories qualifies as 
>> inactive 
>>
>> Is this one year without any _general_ activity (e.g., opening a PR) 
>> or one year without any _maintainer_ activity (e.g., merging or 
>> closing a PR)? Write permissions are needed for the latter but not the 
>> former. Given the stated goal to reduce the number of people with 
>> unnecessary write access, the latter definition makes more sense to 
>> me. 
>>
>> Basil 
>>
>

-- 
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 jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/007096da-aac2--93ec-44466cb3527an%40googlegroups.com.

Re: Revert of breadcrumb bar accessibility change

['wfoll...@cloudbees.com' via Jenkins Developers]

Thanks Basil for the message (I especially liked the references).

I can only +1 your proposal as I was thinking about that in 
https://github.com/jenkinsci/jenkins/pull/6912#issuecomment-1331141923. 
Compared to you, I didn't take the time to move the idea further, thanks 
for the effort.

The change itself is good, it's more about the number of related issues 
that could be adjusted before, i.e. just a matter of time.


On Friday, December 9, 2022 at 8:01:16 AM UTC-8 m...@basilcrow.com wrote:

> The Jenkins core maintainers aspire to deliver First Customer Ship (FCS) 
>  quality all the time on 
> the main branch . The 
> integration of jenkinsci/jenkins#6912 
>  has destabilized the 
> main branch, resulting in approximately a dozen pull requests to correct 
> issues with the initial integration. When the main branch is not in a 
> stable state, new problems are far more likely to be introduced, a timeless 
> phenomenon described by Jeff Bonwick as the Quality Death Spiral 
> . The overall quality of the 
> delivered software, not any one project, is what matters; therefore, I am 
> proposing a revert of jenkinsci/jenkins#6912 
> .
>
> There is past precedent for this: when the Jetty 10 upgrade was 
> integrated, it destabilized the main branch. It was quickly reverted, then 
> reintegrated later when all known issues had been addressed. The revert of 
> jenkinsci/jenkins#6912  
> is also intended to be temporary: once the issues caused by the original 
> change are addressed (including JENKINS-70169 
>  and 
> jenkinsci/design-library-plugin#182 
> ), we 
> fully hope and expect for it to be reintegrated and delivered in its final 
> form.
>

-- 
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 jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/8a1ad83d-9216-468e-9f10-a1d2aeb72d14n%40googlegroups.com.

Re: JDK19 is now available on ci.jenkins.io

['wfoll...@cloudbees.com' via Jenkins Developers]

+1 for the edge approach, to not create "superficial" tech debt 

On Thursday, December 8, 2022 at 8:34:12 AM UTC-8 slide wrote:

> I think the edge idea is a good one. This reduces the churn on Jenkinsfile 
> changes to support building on the latest. It would be nice if we, as 
> plugin developers, could opt in to failures on the edge or not, meaning 
> that a build failure on the latest jdk would not cause the build to fail, 
> unless an option was set to true.
>
> On Thu, Dec 8, 2022 at 9:18 AM Damien Duportal  
> wrote:
>
>> > Given this is the first time (I think) that a non-LTS JDK is provided, 
>> what are the plans around supporting this? 
>>
>> We did not have any plan as we did not thought that much. Interesting 
>> point!
>>
>> > Will it be removed once JDK 20 exists?
>>
>> I guess yes. That would break pipelines using JDK19 though. Would that 
>> make sense to provide a support policy in the infra that would explain we 
>> follow the JDK lifecycles? 
>>
>> Also, would that make sense to, instead, provide a "jdk-edge" that would 
>> be always the latest non LTS JDK instead (intermediate status: if there are 
>> no version AND it's name edge, we make it explicit that it could break at 
>> any time)?
>> Le jeudi 8 décembre 2022 à 17:09:34 UTC+1, db...@cloudbees.com a écrit :
>>
>>> On Thu, Dec 8, 2022 at 11:02 AM 'Stephane Merle' via Jenkins Developers <
>>> jenkin...@googlegroups.com> wrote:
>>>
 Hello dear developers,

 I’m happy to announce that in order to allow contributors to prepare 
 the future of Jenkins by working in advance with new JDK, we’ve added 
 JDK19 
 on ci.jenkins.io.

>>>
>>> Given this is the first time (I think) that a non-LTS JDK is provided, 
>>> what are the plans around supporting this? Will it be removed once JDK 20 
>>> exists? Once JDK 21 (next LTS) exists? Will it be supported indefinitely?
>>>
>> -- 
>> 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 jenkinsci-de...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/jenkinsci-dev/ba7929ca-ae1e-4619-a31b-4b01be0068a3n%40googlegroups.com
>>  
>> 
>> .
>>
>
>
> -- 
> Website: http://earl-of-code.com
>

-- 
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 jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/091d8d5b-8164-420c-b5fc-b6b86583bf2en%40googlegroups.com.

Re: Proposal to ensure new plugin hosting requests use Maven instead of Gradle

['wfoll...@cloudbees.com' via Jenkins Developers]

+1

On Thursday, December 8, 2022 at 8:27:13 AM UTC-8 Adrien Lecharpentier 
wrote:

> +1 as well from me.
>
> Le jeu. 8 déc. 2022 à 17:19, Damien Duportal  a 
> écrit :
>
>> +1
>>
>> Le mercredi 7 décembre 2022 à 15:49:42 UTC+1, bma...@gmail.com a écrit :
>>
>>> +1.
>>>
>>> At least such a move will make it very explicit for any new plugin that 
>>> only Maven really has /production/ support for Jenkins plugin dev.
>>>
>>> I think that we should still "allow" new plugins to use Gradle if they 
>>> wish so. But then they'll be very well aware that they got to be ready for 
>>> a lot of pain and much meta-work around the tooling itself for developing 
>>> their plugins.
>>> Which right now might be overlooked by new developers joining the 
>>> community and thinking that choosing one or another is simply a matter of 
>>> taste and habits.
>>>
>>> Le mer. 7 déc. 2022 à 15:19, Basil Crow  a écrit :
>>>
 +1

 On Wed, Dec 7, 2022 at 2:20 AM Alexander Brandes  
 wrote:
 >
 > Hey everyone,
 >
 > the Gradle JPI plugin lacks fundamental support of the jenkins.io 
 infrastructure.
 > There's no support for automated releases (CD, JEP-229), missing 
 metadata for the plugin page and a few other limitations, which don't make 
 it a great experience using it.
 >
 > Additionally, worth to note, the components mentioned above aren't 
 new. People are proactively switching away from Gradle to Maven for better 
 support and acceptance of our tooling, see ivy-plugin/49 for example.
 >
 > For the reasons stated, I would like to propose, that new plugin 
 hosting requests use Maven, to have better toolchain support.
 > I would be ready to lift this restriction again if the JPI plugin 
 developers provide the same scope of tools like we have for Maven.
 >
 > Best,
 > Alexander Brandes, for the hosting team
 >
 > --
 > 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 jenkinsci-de...@googlegroups.com.
 > To view this discussion on the web visit 
 https://groups.google.com/d/msgid/jenkinsci-dev/bb8f56d3-727b-481a-9132-17bf5eddbbcdn%40googlegroups.com
 .

 -- 
 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 jenkinsci-de...@googlegroups.com.

>>> To view this discussion on the web visit 
 https://groups.google.com/d/msgid/jenkinsci-dev/CAFwNDjq9xnyvJFoB33n07jORm7Hw6fSBf8FY5ho5FdGMDAiKug%40mail.gmail.com
 .

>>> -- 
>> 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 jenkinsci-de...@googlegroups.com.
>>
> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/jenkinsci-dev/5f43f822-37e4-45e2-85a2-3c60840ffcdfn%40googlegroups.com
>>  
>> 
>> .
>>
>

-- 
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 jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/d1c3337b-075d-4978-8baa-78ef4d5a18d2n%40googlegroups.com.

Re: End of year holidays and Jenkins 2.375.2 release schedule

['wfoll...@cloudbees.com' via Jenkins Developers]

For the delay of the LTS realease, with pleasure! :-)

For the RC, no opinion.

On Tuesday, November 22, 2022 at 3:53:47 PM UTC+1 Mark Waite wrote:

> In the past few years, we've  taken a break from our regular LTS schedule 
> over the holiday season.  I propose we take a break this year, though with 
> a variation from past years.
>
> The 2.375.1 LTS release is scheduled for Nov 30.  Four weeks after that 
> would be Dec 28.  I propose that we move the 2.375.2 release candidate date 
> one week to Dec 21 and then delay the 2.375.2 LTS release by two weeks 
> until Jan 11, 2023.
>
> I propose that release dates continue on a 4 week cadence after the Jan 
> 11, 2023 release, so the dates would be:
>
>- Nov 30, 2022 - Jenkins 2.375.1 release
>- Dec 21, 2022 - Jenkins 2.375.2 release candidate
>- Jan 11, 2023 - Jenkins 2.375.2 release
>- Jan 25, 2023 - Jenkins 2.375.3 release candidate
>- Feb 8, 2023 - Jenkins 2.375.3 release
>
> Comments and discussion are welcomed.
>
> Mark Waite
>

-- 
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 jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/633d0536-bbde-4a07-9d28-deb88afd0e8bn%40googlegroups.com.

Re: Next LTS baseline selection

['wfoll...@cloudbees.com' via Jenkins Developers]

FTR 2.375 was released ~4h ago, the changelog page is not even updated (to 
receive the feedback).
With the list of regression/bug fix it seems to be a good candidate, but I 
think we should monitor carefully the user feedbacks and be ready to 
provide backports to a previous version.

To ease this kind of discussion, it could be interesting to introduce only 
very minor features or bug fixes before the LTS selection, so that we have 
more time to test them. But it's a different topic :p

On Monday, October 24, 2022 at 11:36:01 PM UTC+2 mc.ca...@gmail.com wrote:

> +1 for 2.375
>
> On Monday, 24 October 2022 at 23:12:43 UTC+2 m...@basilcrow.com wrote:
>
>> I feel strongly that the following fixes be included in the next LTS 
>> release:
>>
>> jenkinsci/jenkins#7208 - Fix for weather icon issue that many users
>> have complained about (included in the forthcoming 2.375)
>> jenkinsci/jenkins#7270 - Important fix for Java 17 users (included in
>> the forthcoming 2.375)
>> jenkinsci/jenkins#7273 - Fix for regression in queue maintenance
>> introduced in 2.361 (included in the forthcoming 2.375)
>> jenkinsci/jenkins#7275 - Update bundled plugins with security fixes
>> (included in the forthcoming 2.375)
>> jenkinsci/jenkins#7277 and jenkinsci/winstone#296 - Fix for WebSocket
>> regression introduced in the last LTS that many users have complained
>> about (included in the forthcoming 2.375)
>> jenkinsci/jenkins#7286 - Fix for regression in safe restart page
>> introduced in 2.374 (included in the forthcoming 2.375)
>>
>> Based on the above 2.375 could make a good candidate. Note that 2.375
>> also contains a number of significant frontend changes that have not
>> yet received widespread adoption:
>>
>> jenkinsci/jenkins#6912 - Improve breadcrumb bar accessibility
>> jenkinsci/jenkins#7049 - Update the design of notifications
>> jenkinsci/jenkins#7197 - Update design of Manage Users page
>>
>> Assuming that no issues with the abovementioned regression fixes and
>> frontend changes are discovered next week, my vote would be for 2.375.
>>
>

-- 
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 jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/8af5bfe7-1176-42c8-b275-ec5ccce449adn%40googlegroups.com.

Re: Proposal: Alexander Brandes (@NotMyFault) to join the Core team

['wfoll...@cloudbees.com' via Jenkins Developers]

+1, thanks Alex for the several contributions you did over the recent 
period. Looking forward for the next period ;)

On Thursday, October 13, 2022 at 3:12:04 PM UTC+2 Kevin Martens wrote:

> +1 from me too!
>
> On Thu, Oct 13, 2022 at 5:52 AM 'Olblak' via Jenkins Developers <
> jenkin...@googlegroups.com> wrote:
>
>> +1  :) 
>>
>> On Thu, Oct 13, 2022, at 11:39 AM, 'Stephane Merle' via Jenkins 
>> Developers wrote:
>>
>> +1 for me too
>> good luck Alexander
>>
>> On Thu, Oct 13, 2022 at 9:44 AM 'Daniel Beck' via Jenkins Developers <
>> jenkin...@googlegroups.com> wrote:
>>
>>
>>
>> On Thu, Oct 13, 2022 at 9:11 AM Tim Jacomb  wrote:
>>
>> I would like to propose Alexander Brandes (@NotMyFault 
>> ) to join the Jenkins Core team.
>>
>>
>> +1 
>>
>>
>> -- 
>> 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 jenkinsci-de...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/jenkinsci-dev/CAMo7PtJFQvvfqtNixCGOk34quz7Fm_bu0as_QNOVxX%2BXY5jvwA%40mail.gmail.com
>>  
>> 
>> .
>>
>>
>> -- 
>> 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 jenkinsci-de...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/jenkinsci-dev/CAO%2B-N1qxoBRFwKk4%3DJdVY%2B_gns%2BCaMd8J_DC9xuWnRqzEfYDZA%40mail.gmail.com
>>  
>> 
>> .
>>
>>
>> -- 
>> 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 jenkinsci-de...@googlegroups.com.
>>
> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/jenkinsci-dev/b67d978b-bc39-4cb4-a2a3-3ad69cdf621c%40app.fastmail.com
>>  
>> 
>> .
>>
>
>
> -- 
> Kevin Martens
> Technical Content Developer
> CloudBees, Inc.
>
>
> E: kmar...@cloudbees.com
>
> Pronouns: He/Him/His
>
>

-- 
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 jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/064e9092-f0a4-40c3-b4a6-9100f8911dc1n%40googlegroups.com.

Re: GSoC Project - Plugin Health Score Survey for Maintainers

['wfoll...@cloudbees.com' via Jenkins Developers]

Hello Dheeraj,

Are you able to share the data distribution for the individual probes you 
already have in place? This will greatly help us understanding what should 
be done with the rules.

E.g. if all plugins have a code coverage of 50%+, the weight should take 
that into consideration, in opposition to the situation where only the top 
5% of the plugin have more than 5% of coverage.
>From my PoV the project has two goals, showing the current situation and 
also providing guidance about what to improve on a plugin, to follow the 
good practices.

Thanks in advance,

Wadeck

On Wednesday, June 29, 2022 at 8:15:08 PM UTC+2 jodhadhe...@gmail.com wrote:

> Hello Jenkins Contributors!
>
> My name is Dheeraj Singh Jodha and I'm selected as a Google Summer Of Code 
> 2022 student for the Jenkins project where I'm part of a group of 4 people 
> currently working on the project that is titled Plugin Health Scoring 
> System 
> 
> .
>
> Briefly, the Plugin Health Score is a composite score of various different 
> probes related to Jenkins Plugins. These different probes will have 
> different weights(value) and focus on different areas(think administrative 
> metrics, code quality, best practices, and security) and we will generate a 
> final score for each plugin within the Jenkins ecosystem.
>
> As communicated earlier in one of the previous emails, we're now very 
> happy to share with you the Community-wide Survey link!
>
> Please find the link here: https://forms.gle/T6LLqQGYgKke2b8e9
>
> Your 5 mins spent on this survey would help us deliver the best results 
> for our project. Thank you in advance!
>
> Regards,
> Dheeraj
>

-- 
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 jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/cc2dc61a-03a8-4695-8f6b-4436189f9690n%40googlegroups.com.

Re: Security approval required on UI-related PRs in Jenkins core

['wfoll...@cloudbees.com' via Jenkins Developers]

The team got "triage" permission, so that they can add the newly created 
label "security-approved", so that it's easier to understand when it's good 
to go. That will also "solve" Daniel's concern about regular review ;-)

On Wednesday, June 22, 2022 at 9:30:47 PM UTC+2 db...@cloudbees.com wrote:

> On Wed, Jun 22, 2022 at 9:26 PM 'wfoll...@cloudbees.com' via Jenkins 
> Developers  wrote:
>
>> Great idea Alex =>  *@jenkinsci/core-security-review* created
>>
>> Thanks for the feedback and yes Tim, I will allocate more people to those 
>> reviews, compared to the hosting requests that were mainly out-of-order 
>> stuff we are doing.
>>
>
> I would like to retain the ability to review core PRs without those 
> reviews automatically counting towards security review, so please be 
> mindful in the handling of this reviewer group. (In particular, me 
> requesting changes for other reasons should not carry the same weight as 
> rejecting a PR for security reasons.)
>

-- 
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 jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/cdc1485d-e683-4033-aff5-3b1410e10481n%40googlegroups.com.

Re: Security approval required on UI-related PRs in Jenkins core

['wfoll...@cloudbees.com' via Jenkins Developers]

Great idea Alex =>  *@jenkinsci/core-security-review* created

Thanks for the feedback and yes Tim, I will allocate more people to those 
reviews, compared to the hosting requests that were mainly out-of-order 
stuff we are doing.

On Wednesday, June 22, 2022 at 8:57:15 PM UTC+2 mc.ca...@gmail.com wrote:

> 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 timja...@gmail.com 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, 'wfoll...@cloudbees.com' via Jenkins 
>> Developers  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 jenkinsci-de...@googlegroups.com.
>>> 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 jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/7822b682-e525-46c5-9ed4-7bd45b6a0881n%40googlegroups.com.

Security approval required on UI-related PRs in Jenkins core

['wfoll...@cloudbees.com' via Jenkins Developers]

Today the Jenkins project released a security version 
 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 jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/7846d76d-2bc0-4829-a4a2-d9035e10592fn%40googlegroups.com.

Re: Backporting for LTS 2.346.1 started

['wfoll...@cloudbees.com' via Jenkins Developers]

Hey there, especially Tim, 

The next question related to the extra week delay, what do you expect to do 
for the .2 LTS release? It seems that currently it's still scheduled in 3 
weeks. 

Wadeck

On Tuesday, June 7, 2022 at 11:05:49 PM UTC+2 timja...@gmail.com wrote:

> Fine to delay the extra week
>
> On Tue, 7 Jun 2022 at 12:01, Alexander Brandes  wrote:
>
>> Hey Wadeck,
>>
>> thanks for the clarification from the views of the security team, that 
>> sounds reasonable. I'd want to go ahead and merge the PR later today, 
>> considering nobody expressed blocking reviews in over a week.
>>
>> To 1), that's a call Tim has to agree to as well. But like you already 
>> stated, delaying them might not be the best solution, however, I have no 
>> strong objections about it, if the security team needs a bit more time in 
>> advance.
>>
>> ~ Alex
>>
>> On Tuesday, 7 June 2022 at 18:20:52 UTC+2 wfoll...@cloudbees.com wrote:
>>
>>> Hey there, especially Alex,
>>>
>>> Usually we have a two weeks period for the RC, once the backports are 
>>> merged. In this case, we have a PR that is still pending, ~one week after 
>>> the expected delay.
>>> PR in question: https://github.com/jenkinsci/jenkins/pull/6618
>>>
>>> So, two questions:
>>> 1) Is it OK if we are *postponing the release by one additional week*? 
>>> a) to have two weeks of test for the RC, b) to get more time for the 
>>> security release that requires to have that PR merged. It would mean that 
>>> the LTS will be released on June 22. (and thus the Java 11 should be 
>>> postponed again)
>>> 2) When do you plan to merge the PR?
>>>
>>> The second wave of backports seems to contain important fixes, so 
>>> postponing those seems to be not really an option.
>>>
>>> Best regards,
>>>
>>> Wadeck
>>> On Tuesday, May 31, 2022 at 8:37:24 PM UTC+2 m...@basilcrow.com wrote:
>>>
 On Fri, May 27, 2022 at 3:03 AM Alexander Brandes  
 wrote: 
 > 
 > If there are no objections against it, I'd like to use the additional 
 time and start a secondary backporting process from past weekly releases 
 to 
 integrate the new LTS candidates. 

 +1 

>>> -- 
>> 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 jenkinsci-de...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/jenkinsci-dev/5c711ab6-94ba-446d-bf30-e1659fa82368n%40googlegroups.com
>>  
>> 
>> .
>>
>

-- 
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 jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/4f0ee34b-5f27-4dd1-bd9b-444c6cd97ad4n%40googlegroups.com.

Re: Backporting for LTS 2.346.1 started

['wfoll...@cloudbees.com' via Jenkins Developers]

Hey there, especially Alex,

Usually we have a two weeks period for the RC, once the backports are 
merged. In this case, we have a PR that is still pending, ~one week after 
the expected delay.
PR in question: https://github.com/jenkinsci/jenkins/pull/6618

So, two questions:
1) Is it OK if we are *postponing the release by one additional week*? a) 
to have two weeks of test for the RC, b) to get more time for the security 
release that requires to have that PR merged. It would mean that the LTS 
will be released on June 22. (and thus the Java 11 should be postponed 
again)
2) When do you plan to merge the PR?

The second wave of backports seems to contain important fixes, so 
postponing those seems to be not really an option.

Best regards,

Wadeck
On Tuesday, May 31, 2022 at 8:37:24 PM UTC+2 m...@basilcrow.com wrote:

> On Fri, May 27, 2022 at 3:03 AM Alexander Brandes  
> wrote:
> >
> > If there are no objections against it, I'd like to use the additional 
> time and start a secondary backporting process from past weekly releases to 
> integrate the new LTS candidates.
>
> +1
>

-- 
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 jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/2f425abe-e8e9-4002-bb3c-1f4219d8a344n%40googlegroups.com.

Re: Correct permission checks to add

['wfoll...@cloudbees.com' via Jenkins Developers]

Hello, 

Superficial read => I imagine you should use Item.CONFIGURE and not the 
generic Permission.CONFIGURE.

Wadeck

On Thursday, April 28, 2022 at 1:12:47 AM UTC+2 tim.va...@gmail.com wrote:

> Hi,
>
> I added the Jenkins security scan to my plugin on GitHub and resolved all 
> the issues.Or, so I thought.
>
> One of the main classes of reported issues (aside from adding @POST to 
> pretty much all Stapler doXXX methods) was the "no access check done".
>
> While most of the methods I have (mostly doCheck and DoFill...Items) are 
> very simple (no file/net/... access), I figured it would not hurt to add a 
> basic check either.
>
> For the bulk of the methods, typically involved in configuring a step, I 
> did the following:
> - add an @AncestorInPath Item item parameter to the method
> - add if (item != null) item.checkPermission(Permission.CONFIGURE); near 
> the top of the method.
>
> This seemed to make sense - you'd need to have access to the Configure 
> menu item to see the interface that calls those methods anyway
>
> For those bits related to the global tool setup, I simply use Jenkins.get
> ().checkPermission(Jenkins.MANAGE); instead. Again, this seems to make 
> sense, given the tool setup lives among the Manage Jenkins options.
>
> However, when I set up users and activate the matrix strategy, then a user 
> who has the Job/Configure permission will get an Unauthorized error under 
> one of the drop-downs, saying they do not have the N/A/GenericConfigure 
> permission.
>
> Does this mean I should be testing for FreeStyleProject.CONFIGURE instead 
> (these Permission things seem rather hard to discover, I must say)? Or will 
> that prevent using the same UI/methods in other contexts (e.g. what 
> permissions make the pipeline syntax generator available? that uses the 
> same interface as the freestyle project configuration)?
>
> Am I right in using checkPermission, or should I be using 
> checkAnyPermission to check for multiples (say Permission.CONFIGURE, 
> FreeStyleProject,CONFIGURE, Jenkins.MANAGE)?
> Or should I be using has(Any)Permission() and simply fail silently (i.e. 
> return OK validation, or filling no items)?
>
> If the suggestion is "just don't do any checking if there's no real need" 
> then I would really appreciate a way to be able to declare that in code so 
> that the security scan will not raise an issue for it. E.g. a @Unsecured 
> annotation or an empty Jenkins.noPermissionsNeeded() method that will 
> satisfy the "Stapler methods must check access rights" requirement.
> Come to that, if a method doesn't really need @POST, is there any harm 
> (e.g. a perf hit) in adding it? If so, maybe a @GET/@NoPOST annotation to 
> say "this does not need @POST, stop bugging me" would be nice too.
> Security scans become less useful if they mostly produce false positives.
>
> Thanks in advance for any guidance.
>

-- 
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 jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/9ef11edb-e1d3-4226-9086-34097166fa03n%40googlegroups.com.

Re: File Leak Detector

['wfoll...@cloudbees.com' via Jenkins Developers]

+1

On Tuesday, March 1, 2022 at 1:02:21 PM UTC+1 manuel.ramon...@gmail.com 
wrote:

> +1
>
> On Tue, Mar 1, 2022 at 12:28 PM Oleg Nenashev  wrote:
>
>> +1
>>
>>
>> On Tuesday, March 1, 2022 at 8:36:47 AM UTC+1 timja...@gmail.com wrote:
>>
>>> +1
>>>
>>> On Tue, 1 Mar 2022 at 01:26, Mark Waite  wrote:
>>>


 On Monday, February 28, 2022 at 6:13:52 PM UTC-7 Basil Crow wrote:

> kohsuke/file-leak-detector has not seen commits since 2018. There are 
> a number of open PRs that need to be processed and released, including 
> important PRs to add Java 11 support (see JENKINS-52308). 
>
> We recently moved mock-javamail from Kohsuke's GitHub organization to 
> the Jenkins GitHub organization. In the process, I also modernized the 
> library and transferred release permissions to the core team. 
>
> I would like to propose we do the same for kohsuke/file-leak-detector. 
> I am willing to do the modernization work, just as I did for 
> mock-javamail. 
>
> Please let me know what you think. If there is consensus in favor of 
> this plan, I will open a GitHub issue and ping Kohsuke.


 +1 from me. 

 -- 
 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 jenkinsci-de...@googlegroups.com.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/jenkinsci-dev/72ca6c90-018e-414c-9f3e-c84eddbdd466n%40googlegroups.com
  
 
 .

>>> -- 
>> 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 jenkinsci-de...@googlegroups.com.
>>
> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/jenkinsci-dev/2bc3ddce-97bc-4e56-a958-575530dba938n%40googlegroups.com
>>  
>> 
>> .
>>
>

-- 
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 jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/545d0af0-8250-4f25-b78a-de4940c5c6a1n%40googlegroups.com.

Re: Backporting for LTS 2.319.3 started

['wfoll...@cloudbees.com' via Jenkins Developers]

Please Ilde, also include https://issues.jenkins.io/browse/JENKINS-67702 to 
prevent scanners to complain about XStream

On Monday, January 31, 2022 at 9:56:23 AM UTC+1 Vincent Latombe wrote:

> +1 from me to backport it.
>
> Vincent
>
>
> Le lun. 31 janv. 2022 à 09:43, 'Ildefonso Montero' via Jenkins Developers <
> jenkin...@googlegroups.com> a écrit :
>
>> No issues from my side to include it. Looking for more opinions about it.
>>
>> On Sun, Jan 30, 2022 at 11:45 AM timja...@gmail.com  
>> wrote:
>>
>>> There's been a request for 
>>> https://issues.jenkins.io/browse/JENKINS-67635 to be backported
>>>
>>> Just merged in https://github.com/jenkinsci/jenkins/pull/6193
>>>
>>> Any thoughts?
>>>
>>> On Monday, 17 January 2022 at 15:24:27 UTC imon...@cloudbees.com wrote:
>>>
 Backporting has started and the RC is scheduled for next Wednesday 
 2022-01-26

 Candidates: https://issues.jenkins-ci.org/issues/?filter=12146
 Fixed: 
 https://issues.jenkins-ci.org/issues/?jql=labels%20%3D%202.319.3-fixed
 Rejected: 
 https://issues.jenkins-ci.org/issues/?jql=labels%20%3D%202.319.3-rejected



 -- 

 Ildefonso Montero Pérez
 Senior Software Engineer

 CloudBees, Inc



 E: imon...@cloudbees.com

>>> -- 
>>> 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 jenkinsci-de...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/jenkinsci-dev/079fc51e-91d8-4292-ab16-682a8b5e6bf3n%40googlegroups.com
>>>  
>>> 
>>> .
>>>
>>
>>
>> -- 
>>
>> Ildefonso Montero Pérez
>> Senior Software Engineer
>>
>> CloudBees, Inc
>>
>>
>>
>> E: imon...@cloudbees.com
>>
>> -- 
>> 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 jenkinsci-de...@googlegroups.com.
>>
> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BUGhi9fZ6SjTN3mJjf3F60dTFiMzUYj3YCe-AoA%2BN%3Dak1d2tA%40mail.gmail.com
>>  
>> 
>> .
>>
>

-- 
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 jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/81469e25-a61d-42e8-a420-a9b71298566dn%40googlegroups.com.

Re: Release team members

['wfoll...@cloudbees.com' via Jenkins Developers]

Good initiative Tim, thank you :) 

(yes you can add me ^^)

Wadeck

On Friday, September 24, 2021 at 9:52:30 AM UTC+2 Ildefonso Montero wrote:

> No issues from my side :-) Thanks for driving this Tim!
>
> On Thu, Sep 23, 2021 at 9:29 PM Mark Waite  wrote:
>
>> I would like to be a member of that group.
>>
>> On Wed, Sep 22, 2021 at 11:49 PM Tim Jacomb  wrote:
>>
>>> Hello
>>>
>>> Continuing from 
>>> https://groups.google.com/g/jenkinsci-dev/c/YhXRKybGgMg/m/IRjH_VykCwAJ 
>>>
>>> I would like to invite the previous release leads to join the release 
>>> team officially in jenkinsci/jenkins-infra GitHub organisations:
>>>
>>>
>>>- 
>>>
>>>Beatriz Muñoz (@bmunozm)
>>>- 
>>>
>>>Ildefonso Montero (@imonteroperez)
>>>- 
>>>
>>>Mark Waite (@MarkEWaite)
>>>- 
>>>
>>>Raihaan Shouhell (@res0nance)
>>>- 
>>>
>>>Basil Crow (@basil)
>>>
>>>
>>> Daniel, Olivier (olblak), Wadeck, Oleg you are all in the team in 
>>> jenkins-infra, would you like to join the team in jenkinsci as well?
>>>
>>> If you would like to join then please reply to this email.
>>>
>>> For others if you would like to get involved in a release then consider 
>>> stepping up for a release lead role for an LTS release or joining the 
>>> #jenkins-release room on Libera IRC
>>>
>>> Thanks
>>> Tim
>>>
>>> -- 
>>> 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 jenkinsci-de...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/jenkinsci-dev/CAH-3BieVaZAEP3wJBVzpKe1g5YvjEBcRag49vSJ-Fy8Q2%3DDQCw%40mail.gmail.com
>>>  
>>> 
>>> .
>>>
>> -- 
>> 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 jenkinsci-de...@googlegroups.com.
>>
> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/jenkinsci-dev/CAO49JtFtg4-tYwuqB%3DqnA0tvR4MDiL2j%3D_QhaFHtnC8%3DrCmHPQ%40mail.gmail.com
>>  
>> 
>> .
>>
>
>
> -- 
>
> Ildefonso Montero Pérez
> Senior Software Engineer
>
> CloudBees, Inc
>
>
>
> E: imon...@cloudbees.com
>

-- 
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 jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/2bda6d62-3252-4bb7-97fc-29980ed32465n%40googlegroups.com.