[GitHub] [maven-parent] olamy commented on pull request #81: [MPOM-348] Drop configuration for not used Maven Changes Plugin

2022-11-18 Thread GitBox


olamy commented on PR #81:
URL: https://github.com/apache/maven-parent/pull/81#issuecomment-1320819620

   @slachiewicz as asked in a previous comment please update the release 
process documentation here 
https://maven.apache.org/developers/release/maven-project-release-procedure.html
 as `Create an announcement` with using `maven-changes-plugin` will certainly 
not work anymore with this change.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



[jira] [Commented] (MASSEMBLY-941) file permissions removed during assembly:single since 3.2.0

2022-11-18 Thread Herve Boutemy (Jira)


[ 
https://issues.apache.org/jira/browse/MASSEMBLY-941?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17636072#comment-17636072
 ] 

Herve Boutemy commented on MASSEMBLY-941:
-

the CI failure has been replaced by an update in the IT to detect the 3 results 
that can happen based on the build environment: 
https://github.com/apache/maven-assembly-plugin/pull/96/files#diff-d86fc1c81521b5c46f82fc589730ee4ab5d8279caccdf8629ada1018cbc50a5e

just run the IT, and you should not see any failure because the IT has been 
updated to detect in which case you are running (without forcing you to 
configure your env to one precise case of the 3)

> file permissions removed during assembly:single since 3.2.0
> ---
>
> Key: MASSEMBLY-941
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-941
> Project: Maven Assembly Plugin
>  Issue Type: Bug
>  Components: permissions
>Affects Versions: 3.2.0, 3.3.0
>Reporter: Christopher Tubbs
>Assignee: Herve Boutemy
>Priority: Critical
> Fix For: next-release
>
>
> Since 3.2.0, existing file permissions seem to be ignored when creating a 
> tarball assembly, and files stored in the assembly do not have their original 
> file permissions preserved.
> Using version 3.1.1 of this plugin and earlier, when creating a tar.gz, 
> existing file permissions are normally preserved. This is now broken in 
> 3.2.0, unless the component descriptor explicitly sets the fileModes.
> This was discovered trying to prepare a release candidate for Apache Accumulo 
> using the apache-23.pom parent POM's predefined `source-release-tar` 
> descriptor using the `single` goal. We noticed that the resulting 
> source-release tarball had stripped all the executable permissions from our 
> scripts, instead of preserving them. This makes the resulting source release 
> more difficult to build from source.
> A source-release assembly, and any other assembly that does not specify the 
> file permissions explicitly, should preserve the existing file permissions, 
> just as it used to with 3.1.1 and earlier.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[GitHub] [maven-mvnd] gnodet merged pull request #735: Upgrade to groovy 4

2022-11-18 Thread GitBox


gnodet merged PR #735:
URL: https://github.com/apache/maven-mvnd/pull/735


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



[GitHub] [maven-assembly-plugin] JLLeitschuh opened a new pull request, #99: [SECURITY] Fix Temporary File Information Disclosure Vulnerability

2022-11-18 Thread GitBox


JLLeitschuh opened a new pull request, #99:
URL: https://github.com/apache/maven-assembly-plugin/pull/99

   
   # Security Vulnerability Fix
   
   This pull request fixes a Temporary File Information Disclosure 
Vulnerability, which existed in this project.
   
   ## Preamble
   
   The system temporary directory is shared between all users on most unix-like 
systems (not MacOS, or Windows). Thus, code interacting with the system 
temporary directory must be careful about file interactions in this directory, 
and must ensure that the correct file posix permissions are set.
   
   This PR was generated because a call to `File.createTempFile(..)` was 
detected in this repository in a way that makes this project vulnerable to 
local information disclosure.
   With the default uname configuration, `File.createTempFile(..)` creates a 
file with the permissions `-rw-r--r--`. This means that any other user on the 
system can read the contents of this file.
   
   ### Impact
   
   Information in this file is visible to other local users, allowing a 
malicious actor co-resident on the same machine to view potentially sensitive 
files.
   
    Other Examples
   
- [CVE-2020-15250](https://github.com/advisories/GHSA-269g-pwp5-87pp) - 
junit-team/junit
- [CVE-2021-21364](https://github.com/advisories/GHSA-hpv8-9rq5-hq7w) - 
swagger-api/swagger-codegen
- [CVE-2022-24823](https://github.com/advisories/GHSA-5mcr-gq6c-3hq2) - 
netty/netty
- [CVE-2022-24823](https://github.com/advisories/GHSA-269q-hmxg-m83q) - 
netty/netty
   
   # The Fix
   
   The fix has been to convert the logic above to use the following API that 
was introduced in Java 1.7.
   
   ```java
   File tmpDir = Files.createTempFile("temp dir").toFile();
   ```
   
   The API both creates the file securely, ie. with a random, non-conflicting 
name, with file permissions that only allow the currently executing user to 
read or write the contents of this file.
   By default, `Files.createTempFile("temp dir")` will create a file with the 
permissions `-rw---`, which only allows the user that created the file to 
view/write the file contents.
   
   # :arrow_right: Vulnerability Disclosure :arrow_left:
   
   :wave: Vulnerability disclosure is a super important part of the 
vulnerability handling process and should not be skipped! This may be 
completely new to you, and that's okay, I'm here to assist!
   
   First question, do we need to perform vulnerability disclosure? It depends!
   
1. Is the vulnerable code only in tests or example code? No disclosure 
required!
2. Is the vulnerable code in code shipped to your end users? Vulnerability 
disclosure is probably required!
   
   ## Vulnerability Disclosure How-To
   
   You have a few options options to perform vulnerability disclosure. However, 
I'd like to suggest the following 2 options:
   
1. Request a CVE number from GitHub by creating a repository-level [GitHub 
Security 
Advisory](https://docs.github.com/en/code-security/repository-security-advisories/creating-a-repository-security-advisory).
 This has the advantage that, if you provide sufficient information, GitHub 
will automatically generate Dependabot alerts for your downstream consumers, 
resolving this vulnerability more quickly.
2. Reach out to the team at Snyk to assist with CVE issuance. They can be 
reached at the [Snyk's Disclosure Email](mailto:rep...@snyk.io).
   
   ## Detecting this and Future Vulnerabilities
   
   This vulnerability was automatically detected by GitHub's CodeQL using this 
[CodeQL 
Query](https://codeql.github.com/codeql-query-help/java/java-local-temp-file-or-directory-information-disclosure/).
   
   You can automatically detect future vulnerabilities like this by enabling 
the free (for open-source) [GitHub 
Action](https://github.com/github/codeql-action).
   
   I'm not an employee of GitHub, I'm simply an open-source security researcher.
   
   ## Source
   
   This contribution was automatically generated with an 
[OpenRewrite](https://github.com/openrewrite/rewrite) [refactoring 
recipe](https://docs.openrewrite.org/), which was lovingly hand crafted to 
bring this security fix to your repository.
   
   The source code that generated this PR can be found here:
   
[SecureTempFileCreation](https://github.com/openrewrite/rewrite-java-security/blob/main/src/main/java/org/openrewrite/java/security/SecureTempFileCreation.java)
   
   ## Opting-Out
   
   If you'd like to opt-out of future automated security vulnerability fixes 
like this, please consider adding a file called
   `.github/GH-ROBOTS.txt` to your repository with the line:
   
   ```
   User-agent: JLLeitschuh/security-research
   Disallow: *
   ```
   
   This bot will respect the [ROBOTS.txt](https://moz.com/learn/seo/robotstxt) 
format for future contributions.
   
   Alternatively, if this project is no longer actively maintained, consider 

[GitHub] [maven-assembly-plugin] JLLeitschuh opened a new pull request, #98: [SECURITY] Fix Temporary File Information Disclosure Vulnerability

2022-11-18 Thread GitBox


JLLeitschuh opened a new pull request, #98:
URL: https://github.com/apache/maven-assembly-plugin/pull/98

   
   # Security Vulnerability Fix
   
   This pull request fixes a Temporary File Information Disclosure 
Vulnerability, which existed in this project.
   
   ## Preamble
   
   The system temporary directory is shared between all users on most unix-like 
systems (not MacOS, or Windows). Thus, code interacting with the system 
temporary directory must be careful about file interactions in this directory, 
and must ensure that the correct file posix permissions are set.
   
   This PR was generated because a call to `File.createTempFile(..)` was 
detected in this repository in a way that makes this project vulnerable to 
local information disclosure.
   With the default uname configuration, `File.createTempFile(..)` creates a 
file with the permissions `-rw-r--r--`. This means that any other user on the 
system can read the contents of this file.
   
   ### Impact
   
   Information in this file is visible to other local users, allowing a 
malicious actor co-resident on the same machine to view potentially sensitive 
files.
   
    Other Examples
   
- [CVE-2020-15250](https://github.com/advisories/GHSA-269g-pwp5-87pp) - 
junit-team/junit
- [CVE-2021-21364](https://github.com/advisories/GHSA-hpv8-9rq5-hq7w) - 
swagger-api/swagger-codegen
- [CVE-2022-24823](https://github.com/advisories/GHSA-5mcr-gq6c-3hq2) - 
netty/netty
- [CVE-2022-24823](https://github.com/advisories/GHSA-269q-hmxg-m83q) - 
netty/netty
   
   # The Fix
   
   The fix has been to convert the logic above to use the following API that 
was introduced in Java 1.7.
   
   ```java
   File tmpDir = Files.createTempFile("temp dir").toFile();
   ```
   
   The API both creates the file securely, ie. with a random, non-conflicting 
name, with file permissions that only allow the currently executing user to 
read or write the contents of this file.
   By default, `Files.createTempFile("temp dir")` will create a file with the 
permissions `-rw---`, which only allows the user that created the file to 
view/write the file contents.
   
   # :arrow_right: Vulnerability Disclosure :arrow_left:
   
   :wave: Vulnerability disclosure is a super important part of the 
vulnerability handling process and should not be skipped! This may be 
completely new to you, and that's okay, I'm here to assist!
   
   First question, do we need to perform vulnerability disclosure? It depends!
   
1. Is the vulnerable code only in tests or example code? No disclosure 
required!
2. Is the vulnerable code in code shipped to your end users? Vulnerability 
disclosure is probably required!
   
   ## Vulnerability Disclosure How-To
   
   You have a few options options to perform vulnerability disclosure. However, 
I'd like to suggest the following 2 options:
   
1. Request a CVE number from GitHub by creating a repository-level [GitHub 
Security 
Advisory](https://docs.github.com/en/code-security/repository-security-advisories/creating-a-repository-security-advisory).
 This has the advantage that, if you provide sufficient information, GitHub 
will automatically generate Dependabot alerts for your downstream consumers, 
resolving this vulnerability more quickly.
2. Reach out to the team at Snyk to assist with CVE issuance. They can be 
reached at the [Snyk's Disclosure Email](mailto:rep...@snyk.io).
   
   ## Detecting this and Future Vulnerabilities
   
   This vulnerability was automatically detected by GitHub's CodeQL using this 
[CodeQL 
Query](https://codeql.github.com/codeql-query-help/java/java-local-temp-file-or-directory-information-disclosure/).
   
   You can automatically detect future vulnerabilities like this by enabling 
the free (for open-source) [GitHub 
Action](https://github.com/github/codeql-action).
   
   I'm not an employee of GitHub, I'm simply an open-source security researcher.
   
   ## Source
   
   This contribution was automatically generated with an 
[OpenRewrite](https://github.com/openrewrite/rewrite) [refactoring 
recipe](https://docs.openrewrite.org/), which was lovingly hand crafted to 
bring this security fix to your repository.
   
   The source code that generated this PR can be found here:
   
[SecureTempFileCreation](https://github.com/openrewrite/rewrite-java-security/blob/main/src/main/java/org/openrewrite/java/security/SecureTempFileCreation.java)
   
   ## Opting-Out
   
   If you'd like to opt-out of future automated security vulnerability fixes 
like this, please consider adding a file called
   `.github/GH-ROBOTS.txt` to your repository with the line:
   
   ```
   User-agent: JLLeitschuh/security-research
   Disallow: *
   ```
   
   This bot will respect the [ROBOTS.txt](https://moz.com/learn/seo/robotstxt) 
format for future contributions.
   
   Alternatively, if this project is no longer actively maintained, consider 

[GitHub] [maven-artifact-transfer] JLLeitschuh opened a new pull request, #80: [SECURITY] Fix Temporary File Information Disclosure Vulnerability

2022-11-18 Thread GitBox


JLLeitschuh opened a new pull request, #80:
URL: https://github.com/apache/maven-artifact-transfer/pull/80

   
   # Security Vulnerability Fix
   
   This pull request fixes a Temporary File Information Disclosure 
Vulnerability, which existed in this project.
   
   ## Preamble
   
   The system temporary directory is shared between all users on most unix-like 
systems (not MacOS, or Windows). Thus, code interacting with the system 
temporary directory must be careful about file interactions in this directory, 
and must ensure that the correct file posix permissions are set.
   
   This PR was generated because a call to `File.createTempFile(..)` was 
detected in this repository in a way that makes this project vulnerable to 
local information disclosure.
   With the default uname configuration, `File.createTempFile(..)` creates a 
file with the permissions `-rw-r--r--`. This means that any other user on the 
system can read the contents of this file.
   
   ### Impact
   
   Information in this file is visible to other local users, allowing a 
malicious actor co-resident on the same machine to view potentially sensitive 
files.
   
    Other Examples
   
- [CVE-2020-15250](https://github.com/advisories/GHSA-269g-pwp5-87pp) - 
junit-team/junit
- [CVE-2021-21364](https://github.com/advisories/GHSA-hpv8-9rq5-hq7w) - 
swagger-api/swagger-codegen
- [CVE-2022-24823](https://github.com/advisories/GHSA-5mcr-gq6c-3hq2) - 
netty/netty
- [CVE-2022-24823](https://github.com/advisories/GHSA-269q-hmxg-m83q) - 
netty/netty
   
   # The Fix
   
   The fix has been to convert the logic above to use the following API that 
was introduced in Java 1.7.
   
   ```java
   File tmpDir = Files.createTempFile("temp dir").toFile();
   ```
   
   The API both creates the file securely, ie. with a random, non-conflicting 
name, with file permissions that only allow the currently executing user to 
read or write the contents of this file.
   By default, `Files.createTempFile("temp dir")` will create a file with the 
permissions `-rw---`, which only allows the user that created the file to 
view/write the file contents.
   
   # :arrow_right: Vulnerability Disclosure :arrow_left:
   
   :wave: Vulnerability disclosure is a super important part of the 
vulnerability handling process and should not be skipped! This may be 
completely new to you, and that's okay, I'm here to assist!
   
   First question, do we need to perform vulnerability disclosure? It depends!
   
1. Is the vulnerable code only in tests or example code? No disclosure 
required!
2. Is the vulnerable code in code shipped to your end users? Vulnerability 
disclosure is probably required!
   
   ## Vulnerability Disclosure How-To
   
   You have a few options options to perform vulnerability disclosure. However, 
I'd like to suggest the following 2 options:
   
1. Request a CVE number from GitHub by creating a repository-level [GitHub 
Security 
Advisory](https://docs.github.com/en/code-security/repository-security-advisories/creating-a-repository-security-advisory).
 This has the advantage that, if you provide sufficient information, GitHub 
will automatically generate Dependabot alerts for your downstream consumers, 
resolving this vulnerability more quickly.
2. Reach out to the team at Snyk to assist with CVE issuance. They can be 
reached at the [Snyk's Disclosure Email](mailto:rep...@snyk.io).
   
   ## Detecting this and Future Vulnerabilities
   
   This vulnerability was automatically detected by GitHub's CodeQL using this 
[CodeQL 
Query](https://codeql.github.com/codeql-query-help/java/java-local-temp-file-or-directory-information-disclosure/).
   
   You can automatically detect future vulnerabilities like this by enabling 
the free (for open-source) [GitHub 
Action](https://github.com/github/codeql-action).
   
   I'm not an employee of GitHub, I'm simply an open-source security researcher.
   
   ## Source
   
   This contribution was automatically generated with an 
[OpenRewrite](https://github.com/openrewrite/rewrite) [refactoring 
recipe](https://docs.openrewrite.org/), which was lovingly hand crafted to 
bring this security fix to your repository.
   
   The source code that generated this PR can be found here:
   
[SecureTempFileCreation](https://github.com/openrewrite/rewrite-java-security/blob/main/src/main/java/org/openrewrite/java/security/SecureTempFileCreation.java)
   
   ## Opting-Out
   
   If you'd like to opt-out of future automated security vulnerability fixes 
like this, please consider adding a file called
   `.github/GH-ROBOTS.txt` to your repository with the line:
   
   ```
   User-agent: JLLeitschuh/security-research
   Disallow: *
   ```
   
   This bot will respect the [ROBOTS.txt](https://moz.com/learn/seo/robotstxt) 
format for future contributions.
   
   Alternatively, if this project is no longer actively maintained, consider 

[GitHub] [maven-verifier] JLLeitschuh opened a new pull request, #62: [SECURITY] Fix Temporary File Information Disclosure Vulnerability

2022-11-18 Thread GitBox


JLLeitschuh opened a new pull request, #62:
URL: https://github.com/apache/maven-verifier/pull/62

   
   # Security Vulnerability Fix
   
   This pull request fixes a Temporary File Information Disclosure 
Vulnerability, which existed in this project.
   
   ## Preamble
   
   The system temporary directory is shared between all users on most unix-like 
systems (not MacOS, or Windows). Thus, code interacting with the system 
temporary directory must be careful about file interactions in this directory, 
and must ensure that the correct file posix permissions are set.
   
   This PR was generated because a call to `File.createTempFile(..)` was 
detected in this repository in a way that makes this project vulnerable to 
local information disclosure.
   With the default uname configuration, `File.createTempFile(..)` creates a 
file with the permissions `-rw-r--r--`. This means that any other user on the 
system can read the contents of this file.
   
   ### Impact
   
   Information in this file is visible to other local users, allowing a 
malicious actor co-resident on the same machine to view potentially sensitive 
files.
   
    Other Examples
   
- [CVE-2020-15250](https://github.com/advisories/GHSA-269g-pwp5-87pp) - 
junit-team/junit
- [CVE-2021-21364](https://github.com/advisories/GHSA-hpv8-9rq5-hq7w) - 
swagger-api/swagger-codegen
- [CVE-2022-24823](https://github.com/advisories/GHSA-5mcr-gq6c-3hq2) - 
netty/netty
- [CVE-2022-24823](https://github.com/advisories/GHSA-269q-hmxg-m83q) - 
netty/netty
   
   # The Fix
   
   The fix has been to convert the logic above to use the following API that 
was introduced in Java 1.7.
   
   ```java
   File tmpDir = Files.createTempFile("temp dir").toFile();
   ```
   
   The API both creates the file securely, ie. with a random, non-conflicting 
name, with file permissions that only allow the currently executing user to 
read or write the contents of this file.
   By default, `Files.createTempFile("temp dir")` will create a file with the 
permissions `-rw---`, which only allows the user that created the file to 
view/write the file contents.
   
   # :arrow_right: Vulnerability Disclosure :arrow_left:
   
   :wave: Vulnerability disclosure is a super important part of the 
vulnerability handling process and should not be skipped! This may be 
completely new to you, and that's okay, I'm here to assist!
   
   First question, do we need to perform vulnerability disclosure? It depends!
   
1. Is the vulnerable code only in tests or example code? No disclosure 
required!
2. Is the vulnerable code in code shipped to your end users? Vulnerability 
disclosure is probably required!
   
   ## Vulnerability Disclosure How-To
   
   You have a few options options to perform vulnerability disclosure. However, 
I'd like to suggest the following 2 options:
   
1. Request a CVE number from GitHub by creating a repository-level [GitHub 
Security 
Advisory](https://docs.github.com/en/code-security/repository-security-advisories/creating-a-repository-security-advisory).
 This has the advantage that, if you provide sufficient information, GitHub 
will automatically generate Dependabot alerts for your downstream consumers, 
resolving this vulnerability more quickly.
2. Reach out to the team at Snyk to assist with CVE issuance. They can be 
reached at the [Snyk's Disclosure Email](mailto:rep...@snyk.io).
   
   ## Detecting this and Future Vulnerabilities
   
   This vulnerability was automatically detected by GitHub's CodeQL using this 
[CodeQL 
Query](https://codeql.github.com/codeql-query-help/java/java-local-temp-file-or-directory-information-disclosure/).
   
   You can automatically detect future vulnerabilities like this by enabling 
the free (for open-source) [GitHub 
Action](https://github.com/github/codeql-action).
   
   I'm not an employee of GitHub, I'm simply an open-source security researcher.
   
   ## Source
   
   This contribution was automatically generated with an 
[OpenRewrite](https://github.com/openrewrite/rewrite) [refactoring 
recipe](https://docs.openrewrite.org/), which was lovingly hand crafted to 
bring this security fix to your repository.
   
   The source code that generated this PR can be found here:
   
[SecureTempFileCreation](https://github.com/openrewrite/rewrite-java-security/blob/main/src/main/java/org/openrewrite/java/security/SecureTempFileCreation.java)
   
   ## Opting-Out
   
   If you'd like to opt-out of future automated security vulnerability fixes 
like this, please consider adding a file called
   `.github/GH-ROBOTS.txt` to your repository with the line:
   
   ```
   User-agent: JLLeitschuh/security-research
   Disallow: *
   ```
   
   This bot will respect the [ROBOTS.txt](https://moz.com/learn/seo/robotstxt) 
format for future contributions.
   
   Alternatively, if this project is no longer actively maintained, consider 

[GitHub] [maven-shared-io] JLLeitschuh opened a new pull request, #18: [SECURITY] Fix Temporary File Information Disclosure Vulnerability

2022-11-18 Thread GitBox


JLLeitschuh opened a new pull request, #18:
URL: https://github.com/apache/maven-shared-io/pull/18

   
   # Security Vulnerability Fix
   
   This pull request fixes a Temporary File Information Disclosure 
Vulnerability, which existed in this project.
   
   ## Preamble
   
   The system temporary directory is shared between all users on most unix-like 
systems (not MacOS, or Windows). Thus, code interacting with the system 
temporary directory must be careful about file interactions in this directory, 
and must ensure that the correct file posix permissions are set.
   
   This PR was generated because a call to `File.createTempFile(..)` was 
detected in this repository in a way that makes this project vulnerable to 
local information disclosure.
   With the default uname configuration, `File.createTempFile(..)` creates a 
file with the permissions `-rw-r--r--`. This means that any other user on the 
system can read the contents of this file.
   
   ### Impact
   
   Information in this file is visible to other local users, allowing a 
malicious actor co-resident on the same machine to view potentially sensitive 
files.
   
    Other Examples
   
- [CVE-2020-15250](https://github.com/advisories/GHSA-269g-pwp5-87pp) - 
junit-team/junit
- [CVE-2021-21364](https://github.com/advisories/GHSA-hpv8-9rq5-hq7w) - 
swagger-api/swagger-codegen
- [CVE-2022-24823](https://github.com/advisories/GHSA-5mcr-gq6c-3hq2) - 
netty/netty
- [CVE-2022-24823](https://github.com/advisories/GHSA-269q-hmxg-m83q) - 
netty/netty
   
   # The Fix
   
   The fix has been to convert the logic above to use the following API that 
was introduced in Java 1.7.
   
   ```java
   File tmpDir = Files.createTempFile("temp dir").toFile();
   ```
   
   The API both creates the file securely, ie. with a random, non-conflicting 
name, with file permissions that only allow the currently executing user to 
read or write the contents of this file.
   By default, `Files.createTempFile("temp dir")` will create a file with the 
permissions `-rw---`, which only allows the user that created the file to 
view/write the file contents.
   
   # :arrow_right: Vulnerability Disclosure :arrow_left:
   
   :wave: Vulnerability disclosure is a super important part of the 
vulnerability handling process and should not be skipped! This may be 
completely new to you, and that's okay, I'm here to assist!
   
   First question, do we need to perform vulnerability disclosure? It depends!
   
1. Is the vulnerable code only in tests or example code? No disclosure 
required!
2. Is the vulnerable code in code shipped to your end users? Vulnerability 
disclosure is probably required!
   
   ## Vulnerability Disclosure How-To
   
   You have a few options options to perform vulnerability disclosure. However, 
I'd like to suggest the following 2 options:
   
1. Request a CVE number from GitHub by creating a repository-level [GitHub 
Security 
Advisory](https://docs.github.com/en/code-security/repository-security-advisories/creating-a-repository-security-advisory).
 This has the advantage that, if you provide sufficient information, GitHub 
will automatically generate Dependabot alerts for your downstream consumers, 
resolving this vulnerability more quickly.
2. Reach out to the team at Snyk to assist with CVE issuance. They can be 
reached at the [Snyk's Disclosure Email](mailto:rep...@snyk.io).
   
   ## Detecting this and Future Vulnerabilities
   
   This vulnerability was automatically detected by GitHub's CodeQL using this 
[CodeQL 
Query](https://codeql.github.com/codeql-query-help/java/java-local-temp-file-or-directory-information-disclosure/).
   
   You can automatically detect future vulnerabilities like this by enabling 
the free (for open-source) [GitHub 
Action](https://github.com/github/codeql-action).
   
   I'm not an employee of GitHub, I'm simply an open-source security researcher.
   
   ## Source
   
   This contribution was automatically generated with an 
[OpenRewrite](https://github.com/openrewrite/rewrite) [refactoring 
recipe](https://docs.openrewrite.org/), which was lovingly hand crafted to 
bring this security fix to your repository.
   
   The source code that generated this PR can be found here:
   
[SecureTempFileCreation](https://github.com/openrewrite/rewrite-java-security/blob/main/src/main/java/org/openrewrite/java/security/SecureTempFileCreation.java)
   
   ## Opting-Out
   
   If you'd like to opt-out of future automated security vulnerability fixes 
like this, please consider adding a file called
   `.github/GH-ROBOTS.txt` to your repository with the line:
   
   ```
   User-agent: JLLeitschuh/security-research
   Disallow: *
   ```
   
   This bot will respect the [ROBOTS.txt](https://moz.com/learn/seo/robotstxt) 
format for future contributions.
   
   Alternatively, if this project is no longer actively maintained, consider 

[GitHub] [maven-shade-plugin] JLLeitschuh opened a new pull request, #166: [SECURITY] Fix Temporary File Information Disclosure Vulnerability

2022-11-18 Thread GitBox


JLLeitschuh opened a new pull request, #166:
URL: https://github.com/apache/maven-shade-plugin/pull/166

   
   # Security Vulnerability Fix
   
   This pull request fixes a Temporary File Information Disclosure 
Vulnerability, which existed in this project.
   
   ## Preamble
   
   The system temporary directory is shared between all users on most unix-like 
systems (not MacOS, or Windows). Thus, code interacting with the system 
temporary directory must be careful about file interactions in this directory, 
and must ensure that the correct file posix permissions are set.
   
   This PR was generated because a call to `File.createTempFile(..)` was 
detected in this repository in a way that makes this project vulnerable to 
local information disclosure.
   With the default uname configuration, `File.createTempFile(..)` creates a 
file with the permissions `-rw-r--r--`. This means that any other user on the 
system can read the contents of this file.
   
   ### Impact
   
   Information in this file is visible to other local users, allowing a 
malicious actor co-resident on the same machine to view potentially sensitive 
files.
   
    Other Examples
   
- [CVE-2020-15250](https://github.com/advisories/GHSA-269g-pwp5-87pp) - 
junit-team/junit
- [CVE-2021-21364](https://github.com/advisories/GHSA-hpv8-9rq5-hq7w) - 
swagger-api/swagger-codegen
- [CVE-2022-24823](https://github.com/advisories/GHSA-5mcr-gq6c-3hq2) - 
netty/netty
- [CVE-2022-24823](https://github.com/advisories/GHSA-269q-hmxg-m83q) - 
netty/netty
   
   # The Fix
   
   The fix has been to convert the logic above to use the following API that 
was introduced in Java 1.7.
   
   ```java
   File tmpDir = Files.createTempFile("temp dir").toFile();
   ```
   
   The API both creates the file securely, ie. with a random, non-conflicting 
name, with file permissions that only allow the currently executing user to 
read or write the contents of this file.
   By default, `Files.createTempFile("temp dir")` will create a file with the 
permissions `-rw---`, which only allows the user that created the file to 
view/write the file contents.
   
   # :arrow_right: Vulnerability Disclosure :arrow_left:
   
   :wave: Vulnerability disclosure is a super important part of the 
vulnerability handling process and should not be skipped! This may be 
completely new to you, and that's okay, I'm here to assist!
   
   First question, do we need to perform vulnerability disclosure? It depends!
   
1. Is the vulnerable code only in tests or example code? No disclosure 
required!
2. Is the vulnerable code in code shipped to your end users? Vulnerability 
disclosure is probably required!
   
   ## Vulnerability Disclosure How-To
   
   You have a few options options to perform vulnerability disclosure. However, 
I'd like to suggest the following 2 options:
   
1. Request a CVE number from GitHub by creating a repository-level [GitHub 
Security 
Advisory](https://docs.github.com/en/code-security/repository-security-advisories/creating-a-repository-security-advisory).
 This has the advantage that, if you provide sufficient information, GitHub 
will automatically generate Dependabot alerts for your downstream consumers, 
resolving this vulnerability more quickly.
2. Reach out to the team at Snyk to assist with CVE issuance. They can be 
reached at the [Snyk's Disclosure Email](mailto:rep...@snyk.io).
   
   ## Detecting this and Future Vulnerabilities
   
   This vulnerability was automatically detected by GitHub's CodeQL using this 
[CodeQL 
Query](https://codeql.github.com/codeql-query-help/java/java-local-temp-file-or-directory-information-disclosure/).
   
   You can automatically detect future vulnerabilities like this by enabling 
the free (for open-source) [GitHub 
Action](https://github.com/github/codeql-action).
   
   I'm not an employee of GitHub, I'm simply an open-source security researcher.
   
   ## Source
   
   This contribution was automatically generated with an 
[OpenRewrite](https://github.com/openrewrite/rewrite) [refactoring 
recipe](https://docs.openrewrite.org/), which was lovingly hand crafted to 
bring this security fix to your repository.
   
   The source code that generated this PR can be found here:
   
[SecureTempFileCreation](https://github.com/openrewrite/rewrite-java-security/blob/main/src/main/java/org/openrewrite/java/security/SecureTempFileCreation.java)
   
   ## Opting-Out
   
   If you'd like to opt-out of future automated security vulnerability fixes 
like this, please consider adding a file called
   `.github/GH-ROBOTS.txt` to your repository with the line:
   
   ```
   User-agent: JLLeitschuh/security-research
   Disallow: *
   ```
   
   This bot will respect the [ROBOTS.txt](https://moz.com/learn/seo/robotstxt) 
format for future contributions.
   
   Alternatively, if this project is no longer actively maintained, consider 

[GitHub] [maven-resolver] JLLeitschuh opened a new pull request, #224: [SECURITY] Fix Temporary File Information Disclosure Vulnerability

2022-11-18 Thread GitBox


JLLeitschuh opened a new pull request, #224:
URL: https://github.com/apache/maven-resolver/pull/224

   
   # Security Vulnerability Fix
   
   This pull request fixes a Temporary File Information Disclosure 
Vulnerability, which existed in this project.
   
   ## Preamble
   
   The system temporary directory is shared between all users on most unix-like 
systems (not MacOS, or Windows). Thus, code interacting with the system 
temporary directory must be careful about file interactions in this directory, 
and must ensure that the correct file posix permissions are set.
   
   This PR was generated because a call to `File.createTempFile(..)` was 
detected in this repository in a way that makes this project vulnerable to 
local information disclosure.
   With the default uname configuration, `File.createTempFile(..)` creates a 
file with the permissions `-rw-r--r--`. This means that any other user on the 
system can read the contents of this file.
   
   ### Impact
   
   Information in this file is visible to other local users, allowing a 
malicious actor co-resident on the same machine to view potentially sensitive 
files.
   
    Other Examples
   
- [CVE-2020-15250](https://github.com/advisories/GHSA-269g-pwp5-87pp) - 
junit-team/junit
- [CVE-2021-21364](https://github.com/advisories/GHSA-hpv8-9rq5-hq7w) - 
swagger-api/swagger-codegen
- [CVE-2022-24823](https://github.com/advisories/GHSA-5mcr-gq6c-3hq2) - 
netty/netty
- [CVE-2022-24823](https://github.com/advisories/GHSA-269q-hmxg-m83q) - 
netty/netty
   
   # The Fix
   
   The fix has been to convert the logic above to use the following API that 
was introduced in Java 1.7.
   
   ```java
   File tmpDir = Files.createTempFile("temp dir").toFile();
   ```
   
   The API both creates the file securely, ie. with a random, non-conflicting 
name, with file permissions that only allow the currently executing user to 
read or write the contents of this file.
   By default, `Files.createTempFile("temp dir")` will create a file with the 
permissions `-rw---`, which only allows the user that created the file to 
view/write the file contents.
   
   # :arrow_right: Vulnerability Disclosure :arrow_left:
   
   :wave: Vulnerability disclosure is a super important part of the 
vulnerability handling process and should not be skipped! This may be 
completely new to you, and that's okay, I'm here to assist!
   
   First question, do we need to perform vulnerability disclosure? It depends!
   
1. Is the vulnerable code only in tests or example code? No disclosure 
required!
2. Is the vulnerable code in code shipped to your end users? Vulnerability 
disclosure is probably required!
   
   ## Vulnerability Disclosure How-To
   
   You have a few options options to perform vulnerability disclosure. However, 
I'd like to suggest the following 2 options:
   
1. Request a CVE number from GitHub by creating a repository-level [GitHub 
Security 
Advisory](https://docs.github.com/en/code-security/repository-security-advisories/creating-a-repository-security-advisory).
 This has the advantage that, if you provide sufficient information, GitHub 
will automatically generate Dependabot alerts for your downstream consumers, 
resolving this vulnerability more quickly.
2. Reach out to the team at Snyk to assist with CVE issuance. They can be 
reached at the [Snyk's Disclosure Email](mailto:rep...@snyk.io).
   
   ## Detecting this and Future Vulnerabilities
   
   This vulnerability was automatically detected by GitHub's CodeQL using this 
[CodeQL 
Query](https://codeql.github.com/codeql-query-help/java/java-local-temp-file-or-directory-information-disclosure/).
   
   You can automatically detect future vulnerabilities like this by enabling 
the free (for open-source) [GitHub 
Action](https://github.com/github/codeql-action).
   
   I'm not an employee of GitHub, I'm simply an open-source security researcher.
   
   ## Source
   
   This contribution was automatically generated with an 
[OpenRewrite](https://github.com/openrewrite/rewrite) [refactoring 
recipe](https://docs.openrewrite.org/), which was lovingly hand crafted to 
bring this security fix to your repository.
   
   The source code that generated this PR can be found here:
   
[SecureTempFileCreation](https://github.com/openrewrite/rewrite-java-security/blob/main/src/main/java/org/openrewrite/java/security/SecureTempFileCreation.java)
   
   ## Opting-Out
   
   If you'd like to opt-out of future automated security vulnerability fixes 
like this, please consider adding a file called
   `.github/GH-ROBOTS.txt` to your repository with the line:
   
   ```
   User-agent: JLLeitschuh/security-research
   Disallow: *
   ```
   
   This bot will respect the [ROBOTS.txt](https://moz.com/learn/seo/robotstxt) 
format for future contributions.
   
   Alternatively, if this project is no longer actively maintained, consider 

[GitHub] [maven-checkstyle-plugin] JLLeitschuh opened a new pull request, #100: [SECURITY] Fix Temporary File Information Disclosure Vulnerability

2022-11-18 Thread GitBox


JLLeitschuh opened a new pull request, #100:
URL: https://github.com/apache/maven-checkstyle-plugin/pull/100

   
   # Security Vulnerability Fix
   
   This pull request fixes a Temporary File Information Disclosure 
Vulnerability, which existed in this project.
   
   ## Preamble
   
   The system temporary directory is shared between all users on most unix-like 
systems (not MacOS, or Windows). Thus, code interacting with the system 
temporary directory must be careful about file interactions in this directory, 
and must ensure that the correct file posix permissions are set.
   
   This PR was generated because a call to `File.createTempFile(..)` was 
detected in this repository in a way that makes this project vulnerable to 
local information disclosure.
   With the default uname configuration, `File.createTempFile(..)` creates a 
file with the permissions `-rw-r--r--`. This means that any other user on the 
system can read the contents of this file.
   
   ### Impact
   
   Information in this file is visible to other local users, allowing a 
malicious actor co-resident on the same machine to view potentially sensitive 
files.
   
    Other Examples
   
- [CVE-2020-15250](https://github.com/advisories/GHSA-269g-pwp5-87pp) - 
junit-team/junit
- [CVE-2021-21364](https://github.com/advisories/GHSA-hpv8-9rq5-hq7w) - 
swagger-api/swagger-codegen
- [CVE-2022-24823](https://github.com/advisories/GHSA-5mcr-gq6c-3hq2) - 
netty/netty
- [CVE-2022-24823](https://github.com/advisories/GHSA-269q-hmxg-m83q) - 
netty/netty
   
   # The Fix
   
   The fix has been to convert the logic above to use the following API that 
was introduced in Java 1.7.
   
   ```java
   File tmpDir = Files.createTempFile("temp dir").toFile();
   ```
   
   The API both creates the file securely, ie. with a random, non-conflicting 
name, with file permissions that only allow the currently executing user to 
read or write the contents of this file.
   By default, `Files.createTempFile("temp dir")` will create a file with the 
permissions `-rw---`, which only allows the user that created the file to 
view/write the file contents.
   
   # :arrow_right: Vulnerability Disclosure :arrow_left:
   
   :wave: Vulnerability disclosure is a super important part of the 
vulnerability handling process and should not be skipped! This may be 
completely new to you, and that's okay, I'm here to assist!
   
   First question, do we need to perform vulnerability disclosure? It depends!
   
1. Is the vulnerable code only in tests or example code? No disclosure 
required!
2. Is the vulnerable code in code shipped to your end users? Vulnerability 
disclosure is probably required!
   
   ## Vulnerability Disclosure How-To
   
   You have a few options options to perform vulnerability disclosure. However, 
I'd like to suggest the following 2 options:
   
1. Request a CVE number from GitHub by creating a repository-level [GitHub 
Security 
Advisory](https://docs.github.com/en/code-security/repository-security-advisories/creating-a-repository-security-advisory).
 This has the advantage that, if you provide sufficient information, GitHub 
will automatically generate Dependabot alerts for your downstream consumers, 
resolving this vulnerability more quickly.
2. Reach out to the team at Snyk to assist with CVE issuance. They can be 
reached at the [Snyk's Disclosure Email](mailto:rep...@snyk.io).
   
   ## Detecting this and Future Vulnerabilities
   
   This vulnerability was automatically detected by GitHub's CodeQL using this 
[CodeQL 
Query](https://codeql.github.com/codeql-query-help/java/java-local-temp-file-or-directory-information-disclosure/).
   
   You can automatically detect future vulnerabilities like this by enabling 
the free (for open-source) [GitHub 
Action](https://github.com/github/codeql-action).
   
   I'm not an employee of GitHub, I'm simply an open-source security researcher.
   
   ## Source
   
   This contribution was automatically generated with an 
[OpenRewrite](https://github.com/openrewrite/rewrite) [refactoring 
recipe](https://docs.openrewrite.org/), which was lovingly hand crafted to 
bring this security fix to your repository.
   
   The source code that generated this PR can be found here:
   
[SecureTempFileCreation](https://github.com/openrewrite/rewrite-java-security/blob/main/src/main/java/org/openrewrite/java/security/SecureTempFileCreation.java)
   
   ## Opting-Out
   
   If you'd like to opt-out of future automated security vulnerability fixes 
like this, please consider adding a file called
   `.github/GH-ROBOTS.txt` to your repository with the line:
   
   ```
   User-agent: JLLeitschuh/security-research
   Disallow: *
   ```
   
   This bot will respect the [ROBOTS.txt](https://moz.com/learn/seo/robotstxt) 
format for future contributions.
   
   Alternatively, if this project is no longer actively maintained, consider 

[GitHub] [maven-release] JLLeitschuh opened a new pull request, #160: [SECURITY] Fix Temporary File Information Disclosure Vulnerability

2022-11-18 Thread GitBox


JLLeitschuh opened a new pull request, #160:
URL: https://github.com/apache/maven-release/pull/160

   
   # Security Vulnerability Fix
   
   This pull request fixes a Temporary File Information Disclosure 
Vulnerability, which existed in this project.
   
   ## Preamble
   
   The system temporary directory is shared between all users on most unix-like 
systems (not MacOS, or Windows). Thus, code interacting with the system 
temporary directory must be careful about file interactions in this directory, 
and must ensure that the correct file posix permissions are set.
   
   This PR was generated because a call to `File.createTempFile(..)` was 
detected in this repository in a way that makes this project vulnerable to 
local information disclosure.
   With the default uname configuration, `File.createTempFile(..)` creates a 
file with the permissions `-rw-r--r--`. This means that any other user on the 
system can read the contents of this file.
   
   ### Impact
   
   Information in this file is visible to other local users, allowing a 
malicious actor co-resident on the same machine to view potentially sensitive 
files.
   
    Other Examples
   
- [CVE-2020-15250](https://github.com/advisories/GHSA-269g-pwp5-87pp) - 
junit-team/junit
- [CVE-2021-21364](https://github.com/advisories/GHSA-hpv8-9rq5-hq7w) - 
swagger-api/swagger-codegen
- [CVE-2022-24823](https://github.com/advisories/GHSA-5mcr-gq6c-3hq2) - 
netty/netty
- [CVE-2022-24823](https://github.com/advisories/GHSA-269q-hmxg-m83q) - 
netty/netty
   
   # The Fix
   
   The fix has been to convert the logic above to use the following API that 
was introduced in Java 1.7.
   
   ```java
   File tmpDir = Files.createTempFile("temp dir").toFile();
   ```
   
   The API both creates the file securely, ie. with a random, non-conflicting 
name, with file permissions that only allow the currently executing user to 
read or write the contents of this file.
   By default, `Files.createTempFile("temp dir")` will create a file with the 
permissions `-rw---`, which only allows the user that created the file to 
view/write the file contents.
   
   # :arrow_right: Vulnerability Disclosure :arrow_left:
   
   :wave: Vulnerability disclosure is a super important part of the 
vulnerability handling process and should not be skipped! This may be 
completely new to you, and that's okay, I'm here to assist!
   
   First question, do we need to perform vulnerability disclosure? It depends!
   
1. Is the vulnerable code only in tests or example code? No disclosure 
required!
2. Is the vulnerable code in code shipped to your end users? Vulnerability 
disclosure is probably required!
   
   ## Vulnerability Disclosure How-To
   
   You have a few options options to perform vulnerability disclosure. However, 
I'd like to suggest the following 2 options:
   
1. Request a CVE number from GitHub by creating a repository-level [GitHub 
Security 
Advisory](https://docs.github.com/en/code-security/repository-security-advisories/creating-a-repository-security-advisory).
 This has the advantage that, if you provide sufficient information, GitHub 
will automatically generate Dependabot alerts for your downstream consumers, 
resolving this vulnerability more quickly.
2. Reach out to the team at Snyk to assist with CVE issuance. They can be 
reached at the [Snyk's Disclosure Email](mailto:rep...@snyk.io).
   
   ## Detecting this and Future Vulnerabilities
   
   This vulnerability was automatically detected by GitHub's CodeQL using this 
[CodeQL 
Query](https://codeql.github.com/codeql-query-help/java/java-local-temp-file-or-directory-information-disclosure/).
   
   You can automatically detect future vulnerabilities like this by enabling 
the free (for open-source) [GitHub 
Action](https://github.com/github/codeql-action).
   
   I'm not an employee of GitHub, I'm simply an open-source security researcher.
   
   ## Source
   
   This contribution was automatically generated with an 
[OpenRewrite](https://github.com/openrewrite/rewrite) [refactoring 
recipe](https://docs.openrewrite.org/), which was lovingly hand crafted to 
bring this security fix to your repository.
   
   The source code that generated this PR can be found here:
   
[SecureTempFileCreation](https://github.com/openrewrite/rewrite-java-security/blob/main/src/main/java/org/openrewrite/java/security/SecureTempFileCreation.java)
   
   ## Opting-Out
   
   If you'd like to opt-out of future automated security vulnerability fixes 
like this, please consider adding a file called
   `.github/GH-ROBOTS.txt` to your repository with the line:
   
   ```
   User-agent: JLLeitschuh/security-research
   Disallow: *
   ```
   
   This bot will respect the [ROBOTS.txt](https://moz.com/learn/seo/robotstxt) 
format for future contributions.
   
   Alternatively, if this project is no longer actively maintained, consider 

[GitHub] [maven-dependency-plugin] JLLeitschuh opened a new pull request, #264: [SECURITY] Fix Temporary File Information Disclosure Vulnerability

2022-11-18 Thread GitBox


JLLeitschuh opened a new pull request, #264:
URL: https://github.com/apache/maven-dependency-plugin/pull/264

   
   # Security Vulnerability Fix
   
   This pull request fixes a Temporary File Information Disclosure 
Vulnerability, which existed in this project.
   
   ## Preamble
   
   The system temporary directory is shared between all users on most unix-like 
systems (not MacOS, or Windows). Thus, code interacting with the system 
temporary directory must be careful about file interactions in this directory, 
and must ensure that the correct file posix permissions are set.
   
   This PR was generated because a call to `File.createTempFile(..)` was 
detected in this repository in a way that makes this project vulnerable to 
local information disclosure.
   With the default uname configuration, `File.createTempFile(..)` creates a 
file with the permissions `-rw-r--r--`. This means that any other user on the 
system can read the contents of this file.
   
   ### Impact
   
   Information in this file is visible to other local users, allowing a 
malicious actor co-resident on the same machine to view potentially sensitive 
files.
   
    Other Examples
   
- [CVE-2020-15250](https://github.com/advisories/GHSA-269g-pwp5-87pp) - 
junit-team/junit
- [CVE-2021-21364](https://github.com/advisories/GHSA-hpv8-9rq5-hq7w) - 
swagger-api/swagger-codegen
- [CVE-2022-24823](https://github.com/advisories/GHSA-5mcr-gq6c-3hq2) - 
netty/netty
- [CVE-2022-24823](https://github.com/advisories/GHSA-269q-hmxg-m83q) - 
netty/netty
   
   # The Fix
   
   The fix has been to convert the logic above to use the following API that 
was introduced in Java 1.7.
   
   ```java
   File tmpDir = Files.createTempFile("temp dir").toFile();
   ```
   
   The API both creates the file securely, ie. with a random, non-conflicting 
name, with file permissions that only allow the currently executing user to 
read or write the contents of this file.
   By default, `Files.createTempFile("temp dir")` will create a file with the 
permissions `-rw---`, which only allows the user that created the file to 
view/write the file contents.
   
   # :arrow_right: Vulnerability Disclosure :arrow_left:
   
   :wave: Vulnerability disclosure is a super important part of the 
vulnerability handling process and should not be skipped! This may be 
completely new to you, and that's okay, I'm here to assist!
   
   First question, do we need to perform vulnerability disclosure? It depends!
   
1. Is the vulnerable code only in tests or example code? No disclosure 
required!
2. Is the vulnerable code in code shipped to your end users? Vulnerability 
disclosure is probably required!
   
   ## Vulnerability Disclosure How-To
   
   You have a few options options to perform vulnerability disclosure. However, 
I'd like to suggest the following 2 options:
   
1. Request a CVE number from GitHub by creating a repository-level [GitHub 
Security 
Advisory](https://docs.github.com/en/code-security/repository-security-advisories/creating-a-repository-security-advisory).
 This has the advantage that, if you provide sufficient information, GitHub 
will automatically generate Dependabot alerts for your downstream consumers, 
resolving this vulnerability more quickly.
2. Reach out to the team at Snyk to assist with CVE issuance. They can be 
reached at the [Snyk's Disclosure Email](mailto:rep...@snyk.io).
   
   ## Detecting this and Future Vulnerabilities
   
   This vulnerability was automatically detected by GitHub's CodeQL using this 
[CodeQL 
Query](https://codeql.github.com/codeql-query-help/java/java-local-temp-file-or-directory-information-disclosure/).
   
   You can automatically detect future vulnerabilities like this by enabling 
the free (for open-source) [GitHub 
Action](https://github.com/github/codeql-action).
   
   I'm not an employee of GitHub, I'm simply an open-source security researcher.
   
   ## Source
   
   This contribution was automatically generated with an 
[OpenRewrite](https://github.com/openrewrite/rewrite) [refactoring 
recipe](https://docs.openrewrite.org/), which was lovingly hand crafted to 
bring this security fix to your repository.
   
   The source code that generated this PR can be found here:
   
[SecureTempFileCreation](https://github.com/openrewrite/rewrite-java-security/blob/main/src/main/java/org/openrewrite/java/security/SecureTempFileCreation.java)
   
   ## Opting-Out
   
   If you'd like to opt-out of future automated security vulnerability fixes 
like this, please consider adding a file called
   `.github/GH-ROBOTS.txt` to your repository with the line:
   
   ```
   User-agent: JLLeitschuh/security-research
   Disallow: *
   ```
   
   This bot will respect the [ROBOTS.txt](https://moz.com/learn/seo/robotstxt) 
format for future contributions.
   
   Alternatively, if this project is no longer actively maintained, consider 

[GitHub] [maven-dependency-analyzer] JLLeitschuh opened a new pull request, #73: [SECURITY] Fix Temporary File Information Disclosure Vulnerability

2022-11-18 Thread GitBox


JLLeitschuh opened a new pull request, #73:
URL: https://github.com/apache/maven-dependency-analyzer/pull/73

   
   # Security Vulnerability Fix
   
   This pull request fixes a Temporary File Information Disclosure 
Vulnerability, which existed in this project.
   
   ## Preamble
   
   The system temporary directory is shared between all users on most unix-like 
systems (not MacOS, or Windows). Thus, code interacting with the system 
temporary directory must be careful about file interactions in this directory, 
and must ensure that the correct file posix permissions are set.
   
   This PR was generated because a call to `File.createTempFile(..)` was 
detected in this repository in a way that makes this project vulnerable to 
local information disclosure.
   With the default uname configuration, `File.createTempFile(..)` creates a 
file with the permissions `-rw-r--r--`. This means that any other user on the 
system can read the contents of this file.
   
   ### Impact
   
   Information in this file is visible to other local users, allowing a 
malicious actor co-resident on the same machine to view potentially sensitive 
files.
   
    Other Examples
   
- [CVE-2020-15250](https://github.com/advisories/GHSA-269g-pwp5-87pp) - 
junit-team/junit
- [CVE-2021-21364](https://github.com/advisories/GHSA-hpv8-9rq5-hq7w) - 
swagger-api/swagger-codegen
- [CVE-2022-24823](https://github.com/advisories/GHSA-5mcr-gq6c-3hq2) - 
netty/netty
- [CVE-2022-24823](https://github.com/advisories/GHSA-269q-hmxg-m83q) - 
netty/netty
   
   # The Fix
   
   The fix has been to convert the logic above to use the following API that 
was introduced in Java 1.7.
   
   ```java
   File tmpDir = Files.createTempFile("temp dir").toFile();
   ```
   
   The API both creates the file securely, ie. with a random, non-conflicting 
name, with file permissions that only allow the currently executing user to 
read or write the contents of this file.
   By default, `Files.createTempFile("temp dir")` will create a file with the 
permissions `-rw---`, which only allows the user that created the file to 
view/write the file contents.
   
   # :arrow_right: Vulnerability Disclosure :arrow_left:
   
   :wave: Vulnerability disclosure is a super important part of the 
vulnerability handling process and should not be skipped! This may be 
completely new to you, and that's okay, I'm here to assist!
   
   First question, do we need to perform vulnerability disclosure? It depends!
   
1. Is the vulnerable code only in tests or example code? No disclosure 
required!
2. Is the vulnerable code in code shipped to your end users? Vulnerability 
disclosure is probably required!
   
   ## Vulnerability Disclosure How-To
   
   You have a few options options to perform vulnerability disclosure. However, 
I'd like to suggest the following 2 options:
   
1. Request a CVE number from GitHub by creating a repository-level [GitHub 
Security 
Advisory](https://docs.github.com/en/code-security/repository-security-advisories/creating-a-repository-security-advisory).
 This has the advantage that, if you provide sufficient information, GitHub 
will automatically generate Dependabot alerts for your downstream consumers, 
resolving this vulnerability more quickly.
2. Reach out to the team at Snyk to assist with CVE issuance. They can be 
reached at the [Snyk's Disclosure Email](mailto:rep...@snyk.io).
   
   ## Detecting this and Future Vulnerabilities
   
   This vulnerability was automatically detected by GitHub's CodeQL using this 
[CodeQL 
Query](https://codeql.github.com/codeql-query-help/java/java-local-temp-file-or-directory-information-disclosure/).
   
   You can automatically detect future vulnerabilities like this by enabling 
the free (for open-source) [GitHub 
Action](https://github.com/github/codeql-action).
   
   I'm not an employee of GitHub, I'm simply an open-source security researcher.
   
   ## Source
   
   This contribution was automatically generated with an 
[OpenRewrite](https://github.com/openrewrite/rewrite) [refactoring 
recipe](https://docs.openrewrite.org/), which was lovingly hand crafted to 
bring this security fix to your repository.
   
   The source code that generated this PR can be found here:
   
[SecureTempFileCreation](https://github.com/openrewrite/rewrite-java-security/blob/main/src/main/java/org/openrewrite/java/security/SecureTempFileCreation.java)
   
   ## Opting-Out
   
   If you'd like to opt-out of future automated security vulnerability fixes 
like this, please consider adding a file called
   `.github/GH-ROBOTS.txt` to your repository with the line:
   
   ```
   User-agent: JLLeitschuh/security-research
   Disallow: *
   ```
   
   This bot will respect the [ROBOTS.txt](https://moz.com/learn/seo/robotstxt) 
format for future contributions.
   
   Alternatively, if this project is no longer actively maintained, consider 

[GitHub] [maven-plugin-tools] JLLeitschuh opened a new pull request, #176: [SECURITY] Fix Temporary File Information Disclosure Vulnerability

2022-11-18 Thread GitBox


JLLeitschuh opened a new pull request, #176:
URL: https://github.com/apache/maven-plugin-tools/pull/176

   
   # Security Vulnerability Fix
   
   This pull request fixes a Temporary File Information Disclosure 
Vulnerability, which existed in this project.
   
   ## Preamble
   
   The system temporary directory is shared between all users on most unix-like 
systems (not MacOS, or Windows). Thus, code interacting with the system 
temporary directory must be careful about file interactions in this directory, 
and must ensure that the correct file posix permissions are set.
   
   This PR was generated because a call to `File.createTempFile(..)` was 
detected in this repository in a way that makes this project vulnerable to 
local information disclosure.
   With the default uname configuration, `File.createTempFile(..)` creates a 
file with the permissions `-rw-r--r--`. This means that any other user on the 
system can read the contents of this file.
   
   ### Impact
   
   Information in this file is visible to other local users, allowing a 
malicious actor co-resident on the same machine to view potentially sensitive 
files.
   
    Other Examples
   
- [CVE-2020-15250](https://github.com/advisories/GHSA-269g-pwp5-87pp) - 
junit-team/junit
- [CVE-2021-21364](https://github.com/advisories/GHSA-hpv8-9rq5-hq7w) - 
swagger-api/swagger-codegen
- [CVE-2022-24823](https://github.com/advisories/GHSA-5mcr-gq6c-3hq2) - 
netty/netty
- [CVE-2022-24823](https://github.com/advisories/GHSA-269q-hmxg-m83q) - 
netty/netty
   
   # The Fix
   
   The fix has been to convert the logic above to use the following API that 
was introduced in Java 1.7.
   
   ```java
   File tmpDir = Files.createTempFile("temp dir").toFile();
   ```
   
   The API both creates the file securely, ie. with a random, non-conflicting 
name, with file permissions that only allow the currently executing user to 
read or write the contents of this file.
   By default, `Files.createTempFile("temp dir")` will create a file with the 
permissions `-rw---`, which only allows the user that created the file to 
view/write the file contents.
   
   # :arrow_right: Vulnerability Disclosure :arrow_left:
   
   :wave: Vulnerability disclosure is a super important part of the 
vulnerability handling process and should not be skipped! This may be 
completely new to you, and that's okay, I'm here to assist!
   
   First question, do we need to perform vulnerability disclosure? It depends!
   
1. Is the vulnerable code only in tests or example code? No disclosure 
required!
2. Is the vulnerable code in code shipped to your end users? Vulnerability 
disclosure is probably required!
   
   ## Vulnerability Disclosure How-To
   
   You have a few options options to perform vulnerability disclosure. However, 
I'd like to suggest the following 2 options:
   
1. Request a CVE number from GitHub by creating a repository-level [GitHub 
Security 
Advisory](https://docs.github.com/en/code-security/repository-security-advisories/creating-a-repository-security-advisory).
 This has the advantage that, if you provide sufficient information, GitHub 
will automatically generate Dependabot alerts for your downstream consumers, 
resolving this vulnerability more quickly.
2. Reach out to the team at Snyk to assist with CVE issuance. They can be 
reached at the [Snyk's Disclosure Email](mailto:rep...@snyk.io).
   
   ## Detecting this and Future Vulnerabilities
   
   This vulnerability was automatically detected by GitHub's CodeQL using this 
[CodeQL 
Query](https://codeql.github.com/codeql-query-help/java/java-local-temp-file-or-directory-information-disclosure/).
   
   You can automatically detect future vulnerabilities like this by enabling 
the free (for open-source) [GitHub 
Action](https://github.com/github/codeql-action).
   
   I'm not an employee of GitHub, I'm simply an open-source security researcher.
   
   ## Source
   
   This contribution was automatically generated with an 
[OpenRewrite](https://github.com/openrewrite/rewrite) [refactoring 
recipe](https://docs.openrewrite.org/), which was lovingly hand crafted to 
bring this security fix to your repository.
   
   The source code that generated this PR can be found here:
   
[SecureTempFileCreation](https://github.com/openrewrite/rewrite-java-security/blob/main/src/main/java/org/openrewrite/java/security/SecureTempFileCreation.java)
   
   ## Opting-Out
   
   If you'd like to opt-out of future automated security vulnerability fixes 
like this, please consider adding a file called
   `.github/GH-ROBOTS.txt` to your repository with the line:
   
   ```
   User-agent: JLLeitschuh/security-research
   Disallow: *
   ```
   
   This bot will respect the [ROBOTS.txt](https://moz.com/learn/seo/robotstxt) 
format for future contributions.
   
   Alternatively, if this project is no longer actively maintained, consider 

[GitHub] [maven-invoker-plugin] JLLeitschuh opened a new pull request, #152: [SECURITY] Fix Temporary File Information Disclosure Vulnerability

2022-11-18 Thread GitBox


JLLeitschuh opened a new pull request, #152:
URL: https://github.com/apache/maven-invoker-plugin/pull/152

   
   # Security Vulnerability Fix
   
   This pull request fixes a Temporary File Information Disclosure 
Vulnerability, which existed in this project.
   
   ## Preamble
   
   The system temporary directory is shared between all users on most unix-like 
systems (not MacOS, or Windows). Thus, code interacting with the system 
temporary directory must be careful about file interactions in this directory, 
and must ensure that the correct file posix permissions are set.
   
   This PR was generated because a call to `File.createTempFile(..)` was 
detected in this repository in a way that makes this project vulnerable to 
local information disclosure.
   With the default uname configuration, `File.createTempFile(..)` creates a 
file with the permissions `-rw-r--r--`. This means that any other user on the 
system can read the contents of this file.
   
   ### Impact
   
   Information in this file is visible to other local users, allowing a 
malicious actor co-resident on the same machine to view potentially sensitive 
files.
   
    Other Examples
   
- [CVE-2020-15250](https://github.com/advisories/GHSA-269g-pwp5-87pp) - 
junit-team/junit
- [CVE-2021-21364](https://github.com/advisories/GHSA-hpv8-9rq5-hq7w) - 
swagger-api/swagger-codegen
- [CVE-2022-24823](https://github.com/advisories/GHSA-5mcr-gq6c-3hq2) - 
netty/netty
- [CVE-2022-24823](https://github.com/advisories/GHSA-269q-hmxg-m83q) - 
netty/netty
   
   # The Fix
   
   The fix has been to convert the logic above to use the following API that 
was introduced in Java 1.7.
   
   ```java
   File tmpDir = Files.createTempFile("temp dir").toFile();
   ```
   
   The API both creates the file securely, ie. with a random, non-conflicting 
name, with file permissions that only allow the currently executing user to 
read or write the contents of this file.
   By default, `Files.createTempFile("temp dir")` will create a file with the 
permissions `-rw---`, which only allows the user that created the file to 
view/write the file contents.
   
   # :arrow_right: Vulnerability Disclosure :arrow_left:
   
   :wave: Vulnerability disclosure is a super important part of the 
vulnerability handling process and should not be skipped! This may be 
completely new to you, and that's okay, I'm here to assist!
   
   First question, do we need to perform vulnerability disclosure? It depends!
   
1. Is the vulnerable code only in tests or example code? No disclosure 
required!
2. Is the vulnerable code in code shipped to your end users? Vulnerability 
disclosure is probably required!
   
   ## Vulnerability Disclosure How-To
   
   You have a few options options to perform vulnerability disclosure. However, 
I'd like to suggest the following 2 options:
   
1. Request a CVE number from GitHub by creating a repository-level [GitHub 
Security 
Advisory](https://docs.github.com/en/code-security/repository-security-advisories/creating-a-repository-security-advisory).
 This has the advantage that, if you provide sufficient information, GitHub 
will automatically generate Dependabot alerts for your downstream consumers, 
resolving this vulnerability more quickly.
2. Reach out to the team at Snyk to assist with CVE issuance. They can be 
reached at the [Snyk's Disclosure Email](mailto:rep...@snyk.io).
   
   ## Detecting this and Future Vulnerabilities
   
   This vulnerability was automatically detected by GitHub's CodeQL using this 
[CodeQL 
Query](https://codeql.github.com/codeql-query-help/java/java-local-temp-file-or-directory-information-disclosure/).
   
   You can automatically detect future vulnerabilities like this by enabling 
the free (for open-source) [GitHub 
Action](https://github.com/github/codeql-action).
   
   I'm not an employee of GitHub, I'm simply an open-source security researcher.
   
   ## Source
   
   This contribution was automatically generated with an 
[OpenRewrite](https://github.com/openrewrite/rewrite) [refactoring 
recipe](https://docs.openrewrite.org/), which was lovingly hand crafted to 
bring this security fix to your repository.
   
   The source code that generated this PR can be found here:
   
[SecureTempFileCreation](https://github.com/openrewrite/rewrite-java-security/blob/main/src/main/java/org/openrewrite/java/security/SecureTempFileCreation.java)
   
   ## Opting-Out
   
   If you'd like to opt-out of future automated security vulnerability fixes 
like this, please consider adding a file called
   `.github/GH-ROBOTS.txt` to your repository with the line:
   
   ```
   User-agent: JLLeitschuh/security-research
   Disallow: *
   ```
   
   This bot will respect the [ROBOTS.txt](https://moz.com/learn/seo/robotstxt) 
format for future contributions.
   
   Alternatively, if this project is no longer actively maintained, consider 

[GitHub] [maven-install-plugin] JLLeitschuh opened a new pull request, #47: [SECURITY] Fix Temporary File Information Disclosure Vulnerability

2022-11-18 Thread GitBox


JLLeitschuh opened a new pull request, #47:
URL: https://github.com/apache/maven-install-plugin/pull/47

   
   # Security Vulnerability Fix
   
   This pull request fixes a Temporary File Information Disclosure 
Vulnerability, which existed in this project.
   
   ## Preamble
   
   The system temporary directory is shared between all users on most unix-like 
systems (not MacOS, or Windows). Thus, code interacting with the system 
temporary directory must be careful about file interactions in this directory, 
and must ensure that the correct file posix permissions are set.
   
   This PR was generated because a call to `File.createTempFile(..)` was 
detected in this repository in a way that makes this project vulnerable to 
local information disclosure.
   With the default uname configuration, `File.createTempFile(..)` creates a 
file with the permissions `-rw-r--r--`. This means that any other user on the 
system can read the contents of this file.
   
   ### Impact
   
   Information in this file is visible to other local users, allowing a 
malicious actor co-resident on the same machine to view potentially sensitive 
files.
   
    Other Examples
   
- [CVE-2020-15250](https://github.com/advisories/GHSA-269g-pwp5-87pp) - 
junit-team/junit
- [CVE-2021-21364](https://github.com/advisories/GHSA-hpv8-9rq5-hq7w) - 
swagger-api/swagger-codegen
- [CVE-2022-24823](https://github.com/advisories/GHSA-5mcr-gq6c-3hq2) - 
netty/netty
- [CVE-2022-24823](https://github.com/advisories/GHSA-269q-hmxg-m83q) - 
netty/netty
   
   # The Fix
   
   The fix has been to convert the logic above to use the following API that 
was introduced in Java 1.7.
   
   ```java
   File tmpDir = Files.createTempFile("temp dir").toFile();
   ```
   
   The API both creates the file securely, ie. with a random, non-conflicting 
name, with file permissions that only allow the currently executing user to 
read or write the contents of this file.
   By default, `Files.createTempFile("temp dir")` will create a file with the 
permissions `-rw---`, which only allows the user that created the file to 
view/write the file contents.
   
   # :arrow_right: Vulnerability Disclosure :arrow_left:
   
   :wave: Vulnerability disclosure is a super important part of the 
vulnerability handling process and should not be skipped! This may be 
completely new to you, and that's okay, I'm here to assist!
   
   First question, do we need to perform vulnerability disclosure? It depends!
   
1. Is the vulnerable code only in tests or example code? No disclosure 
required!
2. Is the vulnerable code in code shipped to your end users? Vulnerability 
disclosure is probably required!
   
   ## Vulnerability Disclosure How-To
   
   You have a few options options to perform vulnerability disclosure. However, 
I'd like to suggest the following 2 options:
   
1. Request a CVE number from GitHub by creating a repository-level [GitHub 
Security 
Advisory](https://docs.github.com/en/code-security/repository-security-advisories/creating-a-repository-security-advisory).
 This has the advantage that, if you provide sufficient information, GitHub 
will automatically generate Dependabot alerts for your downstream consumers, 
resolving this vulnerability more quickly.
2. Reach out to the team at Snyk to assist with CVE issuance. They can be 
reached at the [Snyk's Disclosure Email](mailto:rep...@snyk.io).
   
   ## Detecting this and Future Vulnerabilities
   
   This vulnerability was automatically detected by GitHub's CodeQL using this 
[CodeQL 
Query](https://codeql.github.com/codeql-query-help/java/java-local-temp-file-or-directory-information-disclosure/).
   
   You can automatically detect future vulnerabilities like this by enabling 
the free (for open-source) [GitHub 
Action](https://github.com/github/codeql-action).
   
   I'm not an employee of GitHub, I'm simply an open-source security researcher.
   
   ## Source
   
   This contribution was automatically generated with an 
[OpenRewrite](https://github.com/openrewrite/rewrite) [refactoring 
recipe](https://docs.openrewrite.org/), which was lovingly hand crafted to 
bring this security fix to your repository.
   
   The source code that generated this PR can be found here:
   
[SecureTempFileCreation](https://github.com/openrewrite/rewrite-java-security/blob/main/src/main/java/org/openrewrite/java/security/SecureTempFileCreation.java)
   
   ## Opting-Out
   
   If you'd like to opt-out of future automated security vulnerability fixes 
like this, please consider adding a file called
   `.github/GH-ROBOTS.txt` to your repository with the line:
   
   ```
   User-agent: JLLeitschuh/security-research
   Disallow: *
   ```
   
   This bot will respect the [ROBOTS.txt](https://moz.com/learn/seo/robotstxt) 
format for future contributions.
   
   Alternatively, if this project is no longer actively maintained, consider 

[GitHub] [maven-gpg-plugin] JLLeitschuh opened a new pull request, #30: [SECURITY] Fix Temporary File Information Disclosure Vulnerability

2022-11-18 Thread GitBox


JLLeitschuh opened a new pull request, #30:
URL: https://github.com/apache/maven-gpg-plugin/pull/30

   
   # Security Vulnerability Fix
   
   This pull request fixes a Temporary File Information Disclosure 
Vulnerability, which existed in this project.
   
   ## Preamble
   
   The system temporary directory is shared between all users on most unix-like 
systems (not MacOS, or Windows). Thus, code interacting with the system 
temporary directory must be careful about file interactions in this directory, 
and must ensure that the correct file posix permissions are set.
   
   This PR was generated because a call to `File.createTempFile(..)` was 
detected in this repository in a way that makes this project vulnerable to 
local information disclosure.
   With the default uname configuration, `File.createTempFile(..)` creates a 
file with the permissions `-rw-r--r--`. This means that any other user on the 
system can read the contents of this file.
   
   ### Impact
   
   Information in this file is visible to other local users, allowing a 
malicious actor co-resident on the same machine to view potentially sensitive 
files.
   
    Other Examples
   
- [CVE-2020-15250](https://github.com/advisories/GHSA-269g-pwp5-87pp) - 
junit-team/junit
- [CVE-2021-21364](https://github.com/advisories/GHSA-hpv8-9rq5-hq7w) - 
swagger-api/swagger-codegen
- [CVE-2022-24823](https://github.com/advisories/GHSA-5mcr-gq6c-3hq2) - 
netty/netty
- [CVE-2022-24823](https://github.com/advisories/GHSA-269q-hmxg-m83q) - 
netty/netty
   
   # The Fix
   
   The fix has been to convert the logic above to use the following API that 
was introduced in Java 1.7.
   
   ```java
   File tmpDir = Files.createTempFile("temp dir").toFile();
   ```
   
   The API both creates the file securely, ie. with a random, non-conflicting 
name, with file permissions that only allow the currently executing user to 
read or write the contents of this file.
   By default, `Files.createTempFile("temp dir")` will create a file with the 
permissions `-rw---`, which only allows the user that created the file to 
view/write the file contents.
   
   # :arrow_right: Vulnerability Disclosure :arrow_left:
   
   :wave: Vulnerability disclosure is a super important part of the 
vulnerability handling process and should not be skipped! This may be 
completely new to you, and that's okay, I'm here to assist!
   
   First question, do we need to perform vulnerability disclosure? It depends!
   
1. Is the vulnerable code only in tests or example code? No disclosure 
required!
2. Is the vulnerable code in code shipped to your end users? Vulnerability 
disclosure is probably required!
   
   ## Vulnerability Disclosure How-To
   
   You have a few options options to perform vulnerability disclosure. However, 
I'd like to suggest the following 2 options:
   
1. Request a CVE number from GitHub by creating a repository-level [GitHub 
Security 
Advisory](https://docs.github.com/en/code-security/repository-security-advisories/creating-a-repository-security-advisory).
 This has the advantage that, if you provide sufficient information, GitHub 
will automatically generate Dependabot alerts for your downstream consumers, 
resolving this vulnerability more quickly.
2. Reach out to the team at Snyk to assist with CVE issuance. They can be 
reached at the [Snyk's Disclosure Email](mailto:rep...@snyk.io).
   
   ## Detecting this and Future Vulnerabilities
   
   This vulnerability was automatically detected by GitHub's CodeQL using this 
[CodeQL 
Query](https://codeql.github.com/codeql-query-help/java/java-local-temp-file-or-directory-information-disclosure/).
   
   You can automatically detect future vulnerabilities like this by enabling 
the free (for open-source) [GitHub 
Action](https://github.com/github/codeql-action).
   
   I'm not an employee of GitHub, I'm simply an open-source security researcher.
   
   ## Source
   
   This contribution was automatically generated with an 
[OpenRewrite](https://github.com/openrewrite/rewrite) [refactoring 
recipe](https://docs.openrewrite.org/), which was lovingly hand crafted to 
bring this security fix to your repository.
   
   The source code that generated this PR can be found here:
   
[SecureTempFileCreation](https://github.com/openrewrite/rewrite-java-security/blob/main/src/main/java/org/openrewrite/java/security/SecureTempFileCreation.java)
   
   ## Opting-Out
   
   If you'd like to opt-out of future automated security vulnerability fixes 
like this, please consider adding a file called
   `.github/GH-ROBOTS.txt` to your repository with the line:
   
   ```
   User-agent: JLLeitschuh/security-research
   Disallow: *
   ```
   
   This bot will respect the [ROBOTS.txt](https://moz.com/learn/seo/robotstxt) 
format for future contributions.
   
   Alternatively, if this project is no longer actively maintained, consider 

[GitHub] [maven-enforcer] JLLeitschuh opened a new pull request, #190: [SECURITY] Fix Temporary File Information Disclosure Vulnerability

2022-11-18 Thread GitBox


JLLeitschuh opened a new pull request, #190:
URL: https://github.com/apache/maven-enforcer/pull/190

   
   # Security Vulnerability Fix
   
   This pull request fixes a Temporary File Information Disclosure 
Vulnerability, which existed in this project.
   
   ## Preamble
   
   The system temporary directory is shared between all users on most unix-like 
systems (not MacOS, or Windows). Thus, code interacting with the system 
temporary directory must be careful about file interactions in this directory, 
and must ensure that the correct file posix permissions are set.
   
   This PR was generated because a call to `File.createTempFile(..)` was 
detected in this repository in a way that makes this project vulnerable to 
local information disclosure.
   With the default uname configuration, `File.createTempFile(..)` creates a 
file with the permissions `-rw-r--r--`. This means that any other user on the 
system can read the contents of this file.
   
   ### Impact
   
   Information in this file is visible to other local users, allowing a 
malicious actor co-resident on the same machine to view potentially sensitive 
files.
   
    Other Examples
   
- [CVE-2020-15250](https://github.com/advisories/GHSA-269g-pwp5-87pp) - 
junit-team/junit
- [CVE-2021-21364](https://github.com/advisories/GHSA-hpv8-9rq5-hq7w) - 
swagger-api/swagger-codegen
- [CVE-2022-24823](https://github.com/advisories/GHSA-5mcr-gq6c-3hq2) - 
netty/netty
- [CVE-2022-24823](https://github.com/advisories/GHSA-269q-hmxg-m83q) - 
netty/netty
   
   # The Fix
   
   The fix has been to convert the logic above to use the following API that 
was introduced in Java 1.7.
   
   ```java
   File tmpDir = Files.createTempFile("temp dir").toFile();
   ```
   
   The API both creates the file securely, ie. with a random, non-conflicting 
name, with file permissions that only allow the currently executing user to 
read or write the contents of this file.
   By default, `Files.createTempFile("temp dir")` will create a file with the 
permissions `-rw---`, which only allows the user that created the file to 
view/write the file contents.
   
   # :arrow_right: Vulnerability Disclosure :arrow_left:
   
   :wave: Vulnerability disclosure is a super important part of the 
vulnerability handling process and should not be skipped! This may be 
completely new to you, and that's okay, I'm here to assist!
   
   First question, do we need to perform vulnerability disclosure? It depends!
   
1. Is the vulnerable code only in tests or example code? No disclosure 
required!
2. Is the vulnerable code in code shipped to your end users? Vulnerability 
disclosure is probably required!
   
   ## Vulnerability Disclosure How-To
   
   You have a few options options to perform vulnerability disclosure. However, 
I'd like to suggest the following 2 options:
   
1. Request a CVE number from GitHub by creating a repository-level [GitHub 
Security 
Advisory](https://docs.github.com/en/code-security/repository-security-advisories/creating-a-repository-security-advisory).
 This has the advantage that, if you provide sufficient information, GitHub 
will automatically generate Dependabot alerts for your downstream consumers, 
resolving this vulnerability more quickly.
2. Reach out to the team at Snyk to assist with CVE issuance. They can be 
reached at the [Snyk's Disclosure Email](mailto:rep...@snyk.io).
   
   ## Detecting this and Future Vulnerabilities
   
   This vulnerability was automatically detected by GitHub's CodeQL using this 
[CodeQL 
Query](https://codeql.github.com/codeql-query-help/java/java-local-temp-file-or-directory-information-disclosure/).
   
   You can automatically detect future vulnerabilities like this by enabling 
the free (for open-source) [GitHub 
Action](https://github.com/github/codeql-action).
   
   I'm not an employee of GitHub, I'm simply an open-source security researcher.
   
   ## Source
   
   This contribution was automatically generated with an 
[OpenRewrite](https://github.com/openrewrite/rewrite) [refactoring 
recipe](https://docs.openrewrite.org/), which was lovingly hand crafted to 
bring this security fix to your repository.
   
   The source code that generated this PR can be found here:
   
[SecureTempFileCreation](https://github.com/openrewrite/rewrite-java-security/blob/main/src/main/java/org/openrewrite/java/security/SecureTempFileCreation.java)
   
   ## Opting-Out
   
   If you'd like to opt-out of future automated security vulnerability fixes 
like this, please consider adding a file called
   `.github/GH-ROBOTS.txt` to your repository with the line:
   
   ```
   User-agent: JLLeitschuh/security-research
   Disallow: *
   ```
   
   This bot will respect the [ROBOTS.txt](https://moz.com/learn/seo/robotstxt) 
format for future contributions.
   
   Alternatively, if this project is no longer actively maintained, consider 

[jira] [Commented] (MNG-7600) LocalRepositoryManager is created to early

2022-11-18 Thread ASF GitHub Bot (Jira)


[ 
https://issues.apache.org/jira/browse/MNG-7600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17636023#comment-17636023
 ] 

ASF GitHub Bot commented on MNG-7600:
-

slawekjaranowski opened a new pull request, #876:
URL: https://github.com/apache/maven/pull/876

   LocalRepositoryManager needs configurations from RepositorySystemSession so 
must be created after session configuration is finished.
   
   ---
   
   Following this checklist to help us incorporate your
   contribution quickly and easily:
   
- [x] Make sure there is a [JIRA 
issue](https://issues.apache.org/jira/browse/MNG) filed
  for the change (usually before you start working on it).  Trivial 
changes like typos do not
  require a JIRA issue. Your pull request should address just this 
issue, without
  pulling in other changes.
- [x] Each commit in the pull request should have a meaningful subject line 
and body.
- [x] Format the pull request title like `[MNG-XXX] SUMMARY`, where you 
replace `MNG-XXX`
  and `SUMMARY` with the appropriate JIRA issue. Best practice is to 
use the JIRA issue
  title in the pull request title and in the first line of the commit 
message.
- [x] Write a pull request description that is detailed enough to 
understand what the pull request does, how, and why.
- [x] Run `mvn clean verify` to make sure basic checks pass. A more 
thorough check will
  be performed on your pull request automatically.
- [x] You have run the [Core IT][core-its] successfully.
   
   If your pull request is about ~20 lines of code you don't need to sign an
   [Individual Contributor License 
Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure
   please ask on the developers list.
   
   To make clear that you license your contribution under
   the [Apache License Version 2.0, January 
2004](http://www.apache.org/licenses/LICENSE-2.0)
   you have to acknowledge this by using the following check-box.
   
- [x] I hereby declare this contribution to be licenced under the [Apache 
License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0)
   
- [x] In any other case, please file an [Apache Individual Contributor 
License Agreement](https://www.apache.org/licenses/icla.pdf).
   
   [core-its]: https://maven.apache.org/core-its/core-it-suite/
   




> LocalRepositoryManager is created to early
> --
>
> Key: MNG-7600
> URL: https://issues.apache.org/jira/browse/MNG-7600
> Project: Maven
>  Issue Type: Bug
>Reporter: Slawomir Jaranowski
>Assignee: Slawomir Jaranowski
>Priority: Major
> Fix For: 3.9.0, 4.0.0, 4.0.0-alpha-3
>
>
> {{LocalRepositoryManager}} needs configurations from 
> {{RepositorySystemSession}}
> so must be created after session configuration is finished.
> In other case only System properties will be available during 
> {{LocalRepositoryManager}} preparation.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[GitHub] [maven] slawekjaranowski opened a new pull request, #876: [MNG-7600] LocalRepositoryManager is created to early

2022-11-18 Thread GitBox


slawekjaranowski opened a new pull request, #876:
URL: https://github.com/apache/maven/pull/876

   LocalRepositoryManager needs configurations from RepositorySystemSession so 
must be created after session configuration is finished.
   
   ---
   
   Following this checklist to help us incorporate your
   contribution quickly and easily:
   
- [x] Make sure there is a [JIRA 
issue](https://issues.apache.org/jira/browse/MNG) filed
  for the change (usually before you start working on it).  Trivial 
changes like typos do not
  require a JIRA issue. Your pull request should address just this 
issue, without
  pulling in other changes.
- [x] Each commit in the pull request should have a meaningful subject line 
and body.
- [x] Format the pull request title like `[MNG-XXX] SUMMARY`, where you 
replace `MNG-XXX`
  and `SUMMARY` with the appropriate JIRA issue. Best practice is to 
use the JIRA issue
  title in the pull request title and in the first line of the commit 
message.
- [x] Write a pull request description that is detailed enough to 
understand what the pull request does, how, and why.
- [x] Run `mvn clean verify` to make sure basic checks pass. A more 
thorough check will
  be performed on your pull request automatically.
- [x] You have run the [Core IT][core-its] successfully.
   
   If your pull request is about ~20 lines of code you don't need to sign an
   [Individual Contributor License 
Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure
   please ask on the developers list.
   
   To make clear that you license your contribution under
   the [Apache License Version 2.0, January 
2004](http://www.apache.org/licenses/LICENSE-2.0)
   you have to acknowledge this by using the following check-box.
   
- [x] I hereby declare this contribution to be licenced under the [Apache 
License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0)
   
- [x] In any other case, please file an [Apache Individual Contributor 
License Agreement](https://www.apache.org/licenses/icla.pdf).
   
   [core-its]: https://maven.apache.org/core-its/core-it-suite/
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



[GitHub] [maven-shared-utils] dependabot[bot] closed pull request #118: Bump slf4j-api from 1.7.36 to 2.0.3

2022-11-18 Thread GitBox


dependabot[bot] closed pull request #118: Bump slf4j-api from 1.7.36 to 2.0.3
URL: https://github.com/apache/maven-shared-utils/pull/118


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



[GitHub] [maven-shared-utils] dependabot[bot] commented on pull request #118: Bump slf4j-api from 1.7.36 to 2.0.3

2022-11-18 Thread GitBox


dependabot[bot] commented on PR #118:
URL: 
https://github.com/apache/maven-shared-utils/pull/118#issuecomment-1320466817

   Superseded by #121.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



[GitHub] [maven-shared-utils] dependabot[bot] opened a new pull request, #121: Bump slf4j-api from 1.7.36 to 2.0.4

2022-11-18 Thread GitBox


dependabot[bot] opened a new pull request, #121:
URL: https://github.com/apache/maven-shared-utils/pull/121

   Bumps [slf4j-api](https://github.com/qos-ch/slf4j) from 1.7.36 to 2.0.4.
   
   Commits
   
   https://github.com/qos-ch/slf4j/commit/35dd7ff1e75cf83ffb6784a9537ff92c865e78b2;>35dd7ff
 removed unused META-INF/services entry
   https://github.com/qos-ch/slf4j/commit/440c2f3000fc0e2d7646f0b3d6e36e8bc2ef2485;>440c2f3
 prepare release 2.0.4
   https://github.com/qos-ch/slf4j/commit/43a36303e5a2338c22ec9aad5b01a401034eb553;>43a3630
 use the class loader that loaded LoggerFactory (instead of the 
threadContextC...
   https://github.com/qos-ch/slf4j/commit/557bf7c0bd4e2c2cd85ef389729107461938dd15;>557bf7c
 [SLF4J-548] Fix ServiceLoader usage in servlet environment
   https://github.com/qos-ch/slf4j/commit/632410565b26e4d67fc7ef2ce4c212380b4e59d1;>6324105
 enhance manifest with capabilities
   https://github.com/qos-ch/slf4j/commit/e540299d58bc5f53cab3236cc1b2f29281982074;>e540299
 edit blurb on release championing
   https://github.com/qos-ch/slf4j/commit/dfb41b06a8e5a6aed5e2856edf099fd324822dcf;>dfb41b0
 Update README.md
   https://github.com/qos-ch/slf4j/commit/47c7cc7fa46d883d46b428aab6ef5562a139;>47c7cc7
 clarify Logger.makeLoggingEventBuilder javadoc
   https://github.com/qos-ch/slf4j/commit/0be1bc15f26f11233ee7f657eb5b50fe552a49f1;>0be1bc1
 Merge branch 'master' of github.com:qos-ch/slf4j
   https://github.com/qos-ch/slf4j/commit/d60690c0b9f0e4c89b71236cee9dc14d967d7778;>d60690c
 more flexible way to
   Additional commits viewable in https://github.com/qos-ch/slf4j/compare/v_1.7.36...v_2.0.4;>compare 
view
   
   
   
   
   
   [![Dependabot compatibility 
score](https://dependabot-badges.githubapp.com/badges/compatibility_score?dependency-name=org.slf4j:slf4j-api=maven=1.7.36=2.0.4)](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
   
   Dependabot will resolve any conflicts with this PR as long as you don't 
alter it yourself. You can also trigger a rebase manually by commenting 
`@dependabot rebase`.
   
   [//]: # (dependabot-automerge-start)
   [//]: # (dependabot-automerge-end)
   
   ---
   
   
   Dependabot commands and options
   
   
   You can trigger Dependabot actions by commenting on this PR:
   - `@dependabot rebase` will rebase this PR
   - `@dependabot recreate` will recreate this PR, overwriting any edits that 
have been made to it
   - `@dependabot merge` will merge this PR after your CI passes on it
   - `@dependabot squash and merge` will squash and merge this PR after your CI 
passes on it
   - `@dependabot cancel merge` will cancel a previously requested merge and 
block automerging
   - `@dependabot reopen` will reopen this PR if it is closed
   - `@dependabot close` will close this PR and stop Dependabot recreating it. 
You can achieve the same result by closing it manually
   - `@dependabot ignore this major version` will close this PR and stop 
Dependabot creating any more for this major version (unless you reopen the PR 
or upgrade to it yourself)
   - `@dependabot ignore this minor version` will close this PR and stop 
Dependabot creating any more for this minor version (unless you reopen the PR 
or upgrade to it yourself)
   - `@dependabot ignore this dependency` will close this PR and stop 
Dependabot creating any more for this dependency (unless you reopen the PR or 
upgrade to it yourself)
   
   
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



[jira] [Created] (MNG-7600) LocalRepositoryManager is created to early

2022-11-18 Thread Slawomir Jaranowski (Jira)
Slawomir Jaranowski created MNG-7600:


 Summary: LocalRepositoryManager is created to early
 Key: MNG-7600
 URL: https://issues.apache.org/jira/browse/MNG-7600
 Project: Maven
  Issue Type: Bug
Reporter: Slawomir Jaranowski
Assignee: Slawomir Jaranowski
 Fix For: 3.9.0, 4.0.0, 4.0.0-alpha-3


{{LocalRepositoryManager}} needs configurations from {{RepositorySystemSession}}
so must be created after session configuration is finished.

In other case only System properties will be available during 
{{LocalRepositoryManager}} preparation.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[GitHub] [maven-filtering] dependabot[bot] opened a new pull request, #56: Bump slf4jVersion from 1.7.36 to 2.0.4

2022-11-18 Thread GitBox


dependabot[bot] opened a new pull request, #56:
URL: https://github.com/apache/maven-filtering/pull/56

   Bumps `slf4jVersion` from 1.7.36 to 2.0.4.
   Updates `slf4j-api` from 1.7.36 to 2.0.4
   
   Commits
   
   https://github.com/qos-ch/slf4j/commit/35dd7ff1e75cf83ffb6784a9537ff92c865e78b2;>35dd7ff
 removed unused META-INF/services entry
   https://github.com/qos-ch/slf4j/commit/440c2f3000fc0e2d7646f0b3d6e36e8bc2ef2485;>440c2f3
 prepare release 2.0.4
   https://github.com/qos-ch/slf4j/commit/43a36303e5a2338c22ec9aad5b01a401034eb553;>43a3630
 use the class loader that loaded LoggerFactory (instead of the 
threadContextC...
   https://github.com/qos-ch/slf4j/commit/557bf7c0bd4e2c2cd85ef389729107461938dd15;>557bf7c
 [SLF4J-548] Fix ServiceLoader usage in servlet environment
   https://github.com/qos-ch/slf4j/commit/632410565b26e4d67fc7ef2ce4c212380b4e59d1;>6324105
 enhance manifest with capabilities
   https://github.com/qos-ch/slf4j/commit/e540299d58bc5f53cab3236cc1b2f29281982074;>e540299
 edit blurb on release championing
   https://github.com/qos-ch/slf4j/commit/dfb41b06a8e5a6aed5e2856edf099fd324822dcf;>dfb41b0
 Update README.md
   https://github.com/qos-ch/slf4j/commit/47c7cc7fa46d883d46b428aab6ef5562a139;>47c7cc7
 clarify Logger.makeLoggingEventBuilder javadoc
   https://github.com/qos-ch/slf4j/commit/0be1bc15f26f11233ee7f657eb5b50fe552a49f1;>0be1bc1
 Merge branch 'master' of github.com:qos-ch/slf4j
   https://github.com/qos-ch/slf4j/commit/d60690c0b9f0e4c89b71236cee9dc14d967d7778;>d60690c
 more flexible way to
   Additional commits viewable in https://github.com/qos-ch/slf4j/compare/v_1.7.36...v_2.0.4;>compare 
view
   
   
   
   
   Updates `slf4j-simple` from 1.7.36 to 2.0.4
   
   Commits
   
   https://github.com/qos-ch/slf4j/commit/35dd7ff1e75cf83ffb6784a9537ff92c865e78b2;>35dd7ff
 removed unused META-INF/services entry
   https://github.com/qos-ch/slf4j/commit/440c2f3000fc0e2d7646f0b3d6e36e8bc2ef2485;>440c2f3
 prepare release 2.0.4
   https://github.com/qos-ch/slf4j/commit/43a36303e5a2338c22ec9aad5b01a401034eb553;>43a3630
 use the class loader that loaded LoggerFactory (instead of the 
threadContextC...
   https://github.com/qos-ch/slf4j/commit/557bf7c0bd4e2c2cd85ef389729107461938dd15;>557bf7c
 [SLF4J-548] Fix ServiceLoader usage in servlet environment
   https://github.com/qos-ch/slf4j/commit/632410565b26e4d67fc7ef2ce4c212380b4e59d1;>6324105
 enhance manifest with capabilities
   https://github.com/qos-ch/slf4j/commit/e540299d58bc5f53cab3236cc1b2f29281982074;>e540299
 edit blurb on release championing
   https://github.com/qos-ch/slf4j/commit/dfb41b06a8e5a6aed5e2856edf099fd324822dcf;>dfb41b0
 Update README.md
   https://github.com/qos-ch/slf4j/commit/47c7cc7fa46d883d46b428aab6ef5562a139;>47c7cc7
 clarify Logger.makeLoggingEventBuilder javadoc
   https://github.com/qos-ch/slf4j/commit/0be1bc15f26f11233ee7f657eb5b50fe552a49f1;>0be1bc1
 Merge branch 'master' of github.com:qos-ch/slf4j
   https://github.com/qos-ch/slf4j/commit/d60690c0b9f0e4c89b71236cee9dc14d967d7778;>d60690c
 more flexible way to
   Additional commits viewable in https://github.com/qos-ch/slf4j/compare/v_1.7.36...v_2.0.4;>compare 
view
   
   
   
   
   
   Dependabot will resolve any conflicts with this PR as long as you don't 
alter it yourself. You can also trigger a rebase manually by commenting 
`@dependabot rebase`.
   
   [//]: # (dependabot-automerge-start)
   [//]: # (dependabot-automerge-end)
   
   ---
   
   
   Dependabot commands and options
   
   
   You can trigger Dependabot actions by commenting on this PR:
   - `@dependabot rebase` will rebase this PR
   - `@dependabot recreate` will recreate this PR, overwriting any edits that 
have been made to it
   - `@dependabot merge` will merge this PR after your CI passes on it
   - `@dependabot squash and merge` will squash and merge this PR after your CI 
passes on it
   - `@dependabot cancel merge` will cancel a previously requested merge and 
block automerging
   - `@dependabot reopen` will reopen this PR if it is closed
   - `@dependabot close` will close this PR and stop Dependabot recreating it. 
You can achieve the same result by closing it manually
   - `@dependabot ignore this major version` will close this PR and stop 
Dependabot creating any more for this major version (unless you reopen the PR 
or upgrade to it yourself)
   - `@dependabot ignore this minor version` will close this PR and stop 
Dependabot creating any more for this minor version (unless you reopen the PR 
or upgrade to it yourself)
   - `@dependabot ignore this dependency` will close this PR and stop 
Dependabot creating any more for this dependency (unless you reopen the PR or 
upgrade to it yourself)
   
   
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org

For queries about this service, 

[jira] [Commented] (MNG-7338) Reduce carbon footprint in CI

2022-11-18 Thread Hudson (Jira)


[ 
https://issues.apache.org/jira/browse/MNG-7338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17635938#comment-17635938
 ] 

Hudson commented on MNG-7338:
-

Build unstable in Jenkins: Maven » Maven TLP » maven » PR-869 #3

See https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven/job/PR-869/3/

> Reduce carbon footprint in CI
> -
>
> Key: MNG-7338
> URL: https://issues.apache.org/jira/browse/MNG-7338
> Project: Maven
>  Issue Type: Bug
>Reporter: Jörg Hohwiller
>Assignee: Martin Kanters
>Priority: Major
>
> MNG-4198 was closed with a simple workaround to add {{-B}} option.
> However, if you look at the real world you will notice that in travis, 
> circle-ci, jenkins, github-actions, etc. 99% of the builds do not use it (not 
> even by defaults from the makers of build templates) and hence 80% of the log 
> files are pure spam and waste:
> {code}
> Progress (2): 0.9/2.6 MB | 160/502 kB
> Progress (2): 0.9/2.6 MB | 164/502 kB
> Progress (2): 0.9/2.6 MB | 168/502 kB
> Progress (2): 0.9/2.6 MB | 172/502 kB
> Progress (2): 0.9/2.6 MB | 176/502 kB
> Progress (2): 0.9/2.6 MB | 180/502 kB
> Progress (2): 0.9/2.6 MB | 180/502 kB
> Progress (2): 1.0/2.6 MB | 180/502 kB
> Progress (2): 1.0/2.6 MB | 184/502 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 4.1/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 8.2/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 12/196 kB 
> Progress (3): 1.0/2.6 MB | 184/502 kB | 16/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 20/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 25/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 29/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 33/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 37/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 41/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 45/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 49/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 53/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 57/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 61/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 66/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 70/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 74/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 78/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 82/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 86/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 90/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 94/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 98/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 102/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 106/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 111/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 188/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 193/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 197/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 201/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 205/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 209/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 213/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 217/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 221/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 225/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 229/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 233/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 238/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 242/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 246/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 250/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 254/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 258/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 262/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 266/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 270/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 274/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 279/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 283/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 287/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 291/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 295/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 299/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 303/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 307/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 311/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 311/502 kB | 115/196 kB
> Progress (4): 1.0/2.6 MB | 311/502 kB | 115/196 kB | 4.1/220 kB
> Progress (4): 1.0/2.6 MB | 311/502 kB | 115/196 kB | 8.2/220 kB
> Progress (4): 1.0/2.6 MB | 311/502 kB | 115/196 kB | 12/220 kB 
> Progress (4): 1.0/2.6 MB | 311/502 kB | 115/196 kB | 16/220 kB
> Progress (4): 1.0/2.6 MB | 311/502 kB | 115/196 kB | 20/220 kB
> Progress (4): 1.0/2.6 MB | 311/502 kB | 115/196 kB | 

[jira] [Commented] (MNG-6720) MultiThreadedBuilder: wait for parallel running projects when using --fail-fast

2022-11-18 Thread Hudson (Jira)


[ 
https://issues.apache.org/jira/browse/MNG-6720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17635939#comment-17635939
 ] 

Hudson commented on MNG-6720:
-

Build unstable in Jenkins: Maven » Maven TLP » maven » PR-869 #3

See https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven/job/PR-869/3/

> MultiThreadedBuilder: wait for parallel running projects when using 
> --fail-fast
> ---
>
> Key: MNG-6720
> URL: https://issues.apache.org/jira/browse/MNG-6720
> Project: Maven
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 3.5.4, 3.6.1
>Reporter: Stefan Oehme
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.6.2
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> When a project fails using --fail-fast mode, other projects that are 
> currently running in parallel are not finished before the "session finished" 
> event is sent. This leads to issues for extensions that rely on the 
> documented order of events, which says that "session finished" is only sent 
> "after all projects have been finished/skipped".
> In our case, we close a service on "session finished", and that service is 
> needed to execute goals. The goals that were running in parallel at that time 
> then fail, saying that our service was closed, giving our users the 
> impression that there is a bug in our code.
> The relevant line is 
> [here|https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/lifecycle/internal/builder/multithreaded/MultiThreadedBuilder.java#L179].
>  Instead of using `poll`, which simply returns when the parallel projects 
> aren't finished yet, the code should shut down the executor and wait for it 
> to complete the outstanding parallel work.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Commented] (MNG-7338) Reduce carbon footprint in CI

2022-11-18 Thread ASF GitHub Bot (Jira)


[ 
https://issues.apache.org/jira/browse/MNG-7338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17635922#comment-17635922
 ] 

ASF GitHub Bot commented on MNG-7338:
-

MartinKanters commented on code in PR #869:
URL: https://github.com/apache/maven/pull/869#discussion_r1026584591


##
maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java:
##
@@ -1438,6 +1446,33 @@ private MavenExecutionRequest populateRequest( 
CliRequest cliRequest, MavenExecu
 return request;
 }
 
+private void disableInteractiveModeIfNeeded( final CliRequest cliRequest, 
final MavenExecutionRequest request )
+{
+CommandLine commandLine = cliRequest.getCommandLine();
+if ( commandLine.hasOption( FORCE_INTERACTIVE ) )
+{
+return;
+}
+
+boolean runningOnCI = isRunningOnCI( cliRequest.getSystemProperties() 
);
+if ( runningOnCI )
+{
+slf4jLogger.info( "Detected a CI build, because the environment 
variable CI equals \"true\". "
++ "Disable this detection by removing that variable or adding 
--force-interactive." );

Review Comment:
   I agree! That is much clearer for the users. I will change it.





> Reduce carbon footprint in CI
> -
>
> Key: MNG-7338
> URL: https://issues.apache.org/jira/browse/MNG-7338
> Project: Maven
>  Issue Type: Bug
>Reporter: Jörg Hohwiller
>Assignee: Martin Kanters
>Priority: Major
>
> MNG-4198 was closed with a simple workaround to add {{-B}} option.
> However, if you look at the real world you will notice that in travis, 
> circle-ci, jenkins, github-actions, etc. 99% of the builds do not use it (not 
> even by defaults from the makers of build templates) and hence 80% of the log 
> files are pure spam and waste:
> {code}
> Progress (2): 0.9/2.6 MB | 160/502 kB
> Progress (2): 0.9/2.6 MB | 164/502 kB
> Progress (2): 0.9/2.6 MB | 168/502 kB
> Progress (2): 0.9/2.6 MB | 172/502 kB
> Progress (2): 0.9/2.6 MB | 176/502 kB
> Progress (2): 0.9/2.6 MB | 180/502 kB
> Progress (2): 0.9/2.6 MB | 180/502 kB
> Progress (2): 1.0/2.6 MB | 180/502 kB
> Progress (2): 1.0/2.6 MB | 184/502 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 4.1/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 8.2/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 12/196 kB 
> Progress (3): 1.0/2.6 MB | 184/502 kB | 16/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 20/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 25/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 29/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 33/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 37/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 41/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 45/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 49/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 53/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 57/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 61/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 66/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 70/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 74/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 78/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 82/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 86/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 90/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 94/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 98/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 102/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 106/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 111/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 188/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 193/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 197/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 201/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 205/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 209/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 213/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 217/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 221/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 225/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 229/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 233/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 238/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 242/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 246/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 250/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 254/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 258/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 262/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 266/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 270/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 274/502 kB 

[GitHub] [maven] MartinKanters commented on a diff in pull request #869: [MNG-7338] Automatically activate batch-mode and make output quiet when running in CI.

2022-11-18 Thread GitBox


MartinKanters commented on code in PR #869:
URL: https://github.com/apache/maven/pull/869#discussion_r1026584591


##
maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java:
##
@@ -1438,6 +1446,33 @@ private MavenExecutionRequest populateRequest( 
CliRequest cliRequest, MavenExecu
 return request;
 }
 
+private void disableInteractiveModeIfNeeded( final CliRequest cliRequest, 
final MavenExecutionRequest request )
+{
+CommandLine commandLine = cliRequest.getCommandLine();
+if ( commandLine.hasOption( FORCE_INTERACTIVE ) )
+{
+return;
+}
+
+boolean runningOnCI = isRunningOnCI( cliRequest.getSystemProperties() 
);
+if ( runningOnCI )
+{
+slf4jLogger.info( "Detected a CI build, because the environment 
variable CI equals \"true\". "
++ "Disable this detection by removing that variable or adding 
--force-interactive." );

Review Comment:
   I agree! That is much clearer for the users. I will change it.



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



[GitHub] [maven-integration-testing] MartinKanters commented on pull request #209: [MNG-7338] Disable CI mode for certain tests which verify on log statements.

2022-11-18 Thread GitBox


MartinKanters commented on PR #209:
URL: 
https://github.com/apache/maven-integration-testing/pull/209#issuecomment-1320187938

   > > I agree. I tried to remove it using 
`verifier.getEnvironmentVariables().remove( "CI" );`, but that doesn't work 
unfortunately.
   > 
   > Should work with:
   > 
   > ```
   > verifier.addEnvironemnt( "CI", null );
   > ```
   > 
   > but needs a maven-sahred-utils 3.3.4 ... as I see 0.9 is used in tests 
   
   Right.. not sure if that's worth the effort for this change haha. I tried it 
quickly but didn't see an addEnvironment variable method. I did see that 
invoking setEnvironment with a `null` value should remove it from the 
environment variables. But that didn't work before. I think that's because 
those environment vars are probably merged later with the actual environment 
variables (which would add CI=true again) 
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



[jira] [Comment Edited] (MENFORCER-422) Support declaring external banned dependencies in an external file/URL

2022-11-18 Thread Jimisola Laursen (Jira)


[ 
https://issues.apache.org/jira/browse/MENFORCER-422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17635890#comment-17635890
 ] 

Jimisola Laursen edited comment on MENFORCER-422 at 11/18/22 2:17 PM:
--

Ok. Went with the file solution and using 
https://github.com/gastaldi/enforcer-rules meanwhile :) Works well. Thanks!


was (Author: JIRAUSER281352):
Ok. Went with the file solution and using 
https://github.com/gastaldi/enforcer-rules meanwhile :)

> Support declaring external banned dependencies in an external file/URL
> --
>
> Key: MENFORCER-422
> URL: https://issues.apache.org/jira/browse/MENFORCER-422
> Project: Maven Enforcer Plugin
>  Issue Type: New Feature
>Reporter: George Gastaldi
>Assignee: Peter Palaga
>Priority: Major
> Fix For: next-release
>
>
> There are some use cases where the list of banned dependencies declared in an 
> enforcer plugin configuration needs to be reused in another project. It would 
> be nice if the {{bannedDependencies}} rule could read the list of banned 
> dependencies from an external file/URL



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Commented] (MENFORCER-422) Support declaring external banned dependencies in an external file/URL

2022-11-18 Thread Jimisola Laursen (Jira)


[ 
https://issues.apache.org/jira/browse/MENFORCER-422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17635890#comment-17635890
 ] 

Jimisola Laursen commented on MENFORCER-422:


Ok. Went with the file solution and using 
https://github.com/gastaldi/enforcer-rules meanwhile :)

> Support declaring external banned dependencies in an external file/URL
> --
>
> Key: MENFORCER-422
> URL: https://issues.apache.org/jira/browse/MENFORCER-422
> Project: Maven Enforcer Plugin
>  Issue Type: New Feature
>Reporter: George Gastaldi
>Assignee: Peter Palaga
>Priority: Major
> Fix For: next-release
>
>
> There are some use cases where the list of banned dependencies declared in an 
> enforcer plugin configuration needs to be reused in another project. It would 
> be nice if the {{bannedDependencies}} rule could read the list of banned 
> dependencies from an external file/URL



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Commented] (MENFORCER-422) Support declaring external banned dependencies in an external file/URL

2022-11-18 Thread George Gastaldi (Jira)


[ 
https://issues.apache.org/jira/browse/MENFORCER-422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17635870#comment-17635870
 ] 

George Gastaldi commented on MENFORCER-422:
---

That's the plugin's classpath. The idea is that you bundle the enforcer rules 
in a maven artifact and add a \{{}} to that artifact in the 
maven-enforcer-plugin dependencies' element

> Support declaring external banned dependencies in an external file/URL
> --
>
> Key: MENFORCER-422
> URL: https://issues.apache.org/jira/browse/MENFORCER-422
> Project: Maven Enforcer Plugin
>  Issue Type: New Feature
>Reporter: George Gastaldi
>Assignee: Peter Palaga
>Priority: Major
> Fix For: next-release
>
>
> There are some use cases where the list of banned dependencies declared in an 
> enforcer plugin configuration needs to be reused in another project. It would 
> be nice if the {{bannedDependencies}} rule could read the list of banned 
> dependencies from an external file/URL



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[GitHub] [maven-plugin-tools] dependabot[bot] opened a new pull request, #175: Bump slf4jVersion from 1.7.5 to 2.0.4

2022-11-18 Thread GitBox


dependabot[bot] opened a new pull request, #175:
URL: https://github.com/apache/maven-plugin-tools/pull/175

   Bumps `slf4jVersion` from 1.7.5 to 2.0.4.
   Updates `slf4j-api` from 1.7.5 to 2.0.4
   
   Commits
   
   https://github.com/qos-ch/slf4j/commit/35dd7ff1e75cf83ffb6784a9537ff92c865e78b2;>35dd7ff
 removed unused META-INF/services entry
   https://github.com/qos-ch/slf4j/commit/440c2f3000fc0e2d7646f0b3d6e36e8bc2ef2485;>440c2f3
 prepare release 2.0.4
   https://github.com/qos-ch/slf4j/commit/43a36303e5a2338c22ec9aad5b01a401034eb553;>43a3630
 use the class loader that loaded LoggerFactory (instead of the 
threadContextC...
   https://github.com/qos-ch/slf4j/commit/557bf7c0bd4e2c2cd85ef389729107461938dd15;>557bf7c
 [SLF4J-548] Fix ServiceLoader usage in servlet environment
   https://github.com/qos-ch/slf4j/commit/632410565b26e4d67fc7ef2ce4c212380b4e59d1;>6324105
 enhance manifest with capabilities
   https://github.com/qos-ch/slf4j/commit/e540299d58bc5f53cab3236cc1b2f29281982074;>e540299
 edit blurb on release championing
   https://github.com/qos-ch/slf4j/commit/dfb41b06a8e5a6aed5e2856edf099fd324822dcf;>dfb41b0
 Update README.md
   https://github.com/qos-ch/slf4j/commit/47c7cc7fa46d883d46b428aab6ef5562a139;>47c7cc7
 clarify Logger.makeLoggingEventBuilder javadoc
   https://github.com/qos-ch/slf4j/commit/0be1bc15f26f11233ee7f657eb5b50fe552a49f1;>0be1bc1
 Merge branch 'master' of github.com:qos-ch/slf4j
   https://github.com/qos-ch/slf4j/commit/d60690c0b9f0e4c89b71236cee9dc14d967d7778;>d60690c
 more flexible way to
   Additional commits viewable in https://github.com/qos-ch/slf4j/compare/v_1.7.5...v_2.0.4;>compare 
view
   
   
   
   
   Updates `slf4j-simple` from 1.7.5 to 2.0.4
   
   Commits
   
   https://github.com/qos-ch/slf4j/commit/35dd7ff1e75cf83ffb6784a9537ff92c865e78b2;>35dd7ff
 removed unused META-INF/services entry
   https://github.com/qos-ch/slf4j/commit/440c2f3000fc0e2d7646f0b3d6e36e8bc2ef2485;>440c2f3
 prepare release 2.0.4
   https://github.com/qos-ch/slf4j/commit/43a36303e5a2338c22ec9aad5b01a401034eb553;>43a3630
 use the class loader that loaded LoggerFactory (instead of the 
threadContextC...
   https://github.com/qos-ch/slf4j/commit/557bf7c0bd4e2c2cd85ef389729107461938dd15;>557bf7c
 [SLF4J-548] Fix ServiceLoader usage in servlet environment
   https://github.com/qos-ch/slf4j/commit/632410565b26e4d67fc7ef2ce4c212380b4e59d1;>6324105
 enhance manifest with capabilities
   https://github.com/qos-ch/slf4j/commit/e540299d58bc5f53cab3236cc1b2f29281982074;>e540299
 edit blurb on release championing
   https://github.com/qos-ch/slf4j/commit/dfb41b06a8e5a6aed5e2856edf099fd324822dcf;>dfb41b0
 Update README.md
   https://github.com/qos-ch/slf4j/commit/47c7cc7fa46d883d46b428aab6ef5562a139;>47c7cc7
 clarify Logger.makeLoggingEventBuilder javadoc
   https://github.com/qos-ch/slf4j/commit/0be1bc15f26f11233ee7f657eb5b50fe552a49f1;>0be1bc1
 Merge branch 'master' of github.com:qos-ch/slf4j
   https://github.com/qos-ch/slf4j/commit/d60690c0b9f0e4c89b71236cee9dc14d967d7778;>d60690c
 more flexible way to
   Additional commits viewable in https://github.com/qos-ch/slf4j/compare/v_1.7.5...v_2.0.4;>compare 
view
   
   
   
   
   
   Dependabot will resolve any conflicts with this PR as long as you don't 
alter it yourself. You can also trigger a rebase manually by commenting 
`@dependabot rebase`.
   
   [//]: # (dependabot-automerge-start)
   [//]: # (dependabot-automerge-end)
   
   ---
   
   
   Dependabot commands and options
   
   
   You can trigger Dependabot actions by commenting on this PR:
   - `@dependabot rebase` will rebase this PR
   - `@dependabot recreate` will recreate this PR, overwriting any edits that 
have been made to it
   - `@dependabot merge` will merge this PR after your CI passes on it
   - `@dependabot squash and merge` will squash and merge this PR after your CI 
passes on it
   - `@dependabot cancel merge` will cancel a previously requested merge and 
block automerging
   - `@dependabot reopen` will reopen this PR if it is closed
   - `@dependabot close` will close this PR and stop Dependabot recreating it. 
You can achieve the same result by closing it manually
   - `@dependabot ignore this major version` will close this PR and stop 
Dependabot creating any more for this major version (unless you reopen the PR 
or upgrade to it yourself)
   - `@dependabot ignore this minor version` will close this PR and stop 
Dependabot creating any more for this minor version (unless you reopen the PR 
or upgrade to it yourself)
   - `@dependabot ignore this dependency` will close this PR and stop 
Dependabot creating any more for this dependency (unless you reopen the PR or 
upgrade to it yourself)
   
   
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org

For queries about this service, 

[jira] [Commented] (MENFORCER-422) Support declaring external banned dependencies in an external file/URL

2022-11-18 Thread Jimisola Laursen (Jira)


[ 
https://issues.apache.org/jira/browse/MENFORCER-422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17635843#comment-17635843
 ] 

Jimisola Laursen commented on MENFORCER-422:


[~gastaldi] It's not clear to me where I place files if I use "classpath:". 
This is the classpath for Maven Enforcer and if so where is it per default and 
can I change it? Or  is it the classpath of the actual Maven project?

Will probably go with non-classpath option for now but it might need some 
documentation. I looked at the PR and didn't see it explained there.

> Support declaring external banned dependencies in an external file/URL
> --
>
> Key: MENFORCER-422
> URL: https://issues.apache.org/jira/browse/MENFORCER-422
> Project: Maven Enforcer Plugin
>  Issue Type: New Feature
>Reporter: George Gastaldi
>Assignee: Peter Palaga
>Priority: Major
> Fix For: next-release
>
>
> There are some use cases where the list of banned dependencies declared in an 
> enforcer plugin configuration needs to be reused in another project. It would 
> be nice if the {{bannedDependencies}} rule could read the list of banned 
> dependencies from an external file/URL



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Commented] (MNG-7316) MavenProject.getAttachedArtifacts() regression with 3.8.1

2022-11-18 Thread Michael Osipov (Jira)


[ 
https://issues.apache.org/jira/browse/MNG-7316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17635840#comment-17635840
 ] 

Michael Osipov commented on MNG-7316:
-

[~laeubi], I don't object other, likely reasonable use cases.
[~ggregory], well, me not because I conside it not correct. I want to hear 
[~chtompki] reasoning before I do anything.

> MavenProject.getAttachedArtifacts() regression with 3.8.1
> -
>
> Key: MNG-7316
> URL: https://issues.apache.org/jira/browse/MNG-7316
> Project: Maven
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 3.8.2, 3.8.3
>Reporter: Gary D. Gregory
>Priority: Critical
> Fix For: waiting-for-feedback, wontfix-candidate
>
>
> The method {{MavenProject.getAttachedArtifacts()}} as of 3.8.2 breaks 
> releasing components for us at Apache Commons using our Maven Release plugin 
> because the list returned is now immutable, we now get an exception when 
> calling {{remove()}} on the collection returned by the API; see 
> [https://github.com/apache/commons-release-plugin/blob/master/src/main/java/org/apache/commons/release/plugin/mojos/CommonsDistributionDetachmentMojo.java#L137]
> This worked fine in 3.8.1, may you please change it back for 3.8.4?
> We cannot use Maven 3.8.2 and 3.8.3 to release our components.
> ([~michael-o]: Ironically, I discovered this trying to create a release 
> candidate for Apache Commons CLI.)
> The exception in 3.8.3:
> {quote}Caused by: java.lang.UnsupportedOperationException
>  at java.util.Collections$UnmodifiableCollection.remove 
> (Collections.java:1060)
>  at 
> org.apache.commons.release.plugin.mojos.CommonsDistributionDetachmentMojo.execute
>  (CommonsDistributionDetachmentMojo.java:136)
>  at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo 
> (DefaultBuildPluginManager.java:137)
> {quote}
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[GitHub] [maven-jxr] dependabot[bot] opened a new pull request, #85: Bump slf4j-simple from 1.7.36 to 2.0.4

2022-11-18 Thread GitBox


dependabot[bot] opened a new pull request, #85:
URL: https://github.com/apache/maven-jxr/pull/85

   Bumps [slf4j-simple](https://github.com/qos-ch/slf4j) from 1.7.36 to 2.0.4.
   
   Commits
   
   https://github.com/qos-ch/slf4j/commit/35dd7ff1e75cf83ffb6784a9537ff92c865e78b2;>35dd7ff
 removed unused META-INF/services entry
   https://github.com/qos-ch/slf4j/commit/440c2f3000fc0e2d7646f0b3d6e36e8bc2ef2485;>440c2f3
 prepare release 2.0.4
   https://github.com/qos-ch/slf4j/commit/43a36303e5a2338c22ec9aad5b01a401034eb553;>43a3630
 use the class loader that loaded LoggerFactory (instead of the 
threadContextC...
   https://github.com/qos-ch/slf4j/commit/557bf7c0bd4e2c2cd85ef389729107461938dd15;>557bf7c
 [SLF4J-548] Fix ServiceLoader usage in servlet environment
   https://github.com/qos-ch/slf4j/commit/632410565b26e4d67fc7ef2ce4c212380b4e59d1;>6324105
 enhance manifest with capabilities
   https://github.com/qos-ch/slf4j/commit/e540299d58bc5f53cab3236cc1b2f29281982074;>e540299
 edit blurb on release championing
   https://github.com/qos-ch/slf4j/commit/dfb41b06a8e5a6aed5e2856edf099fd324822dcf;>dfb41b0
 Update README.md
   https://github.com/qos-ch/slf4j/commit/47c7cc7fa46d883d46b428aab6ef5562a139;>47c7cc7
 clarify Logger.makeLoggingEventBuilder javadoc
   https://github.com/qos-ch/slf4j/commit/0be1bc15f26f11233ee7f657eb5b50fe552a49f1;>0be1bc1
 Merge branch 'master' of github.com:qos-ch/slf4j
   https://github.com/qos-ch/slf4j/commit/d60690c0b9f0e4c89b71236cee9dc14d967d7778;>d60690c
 more flexible way to
   Additional commits viewable in https://github.com/qos-ch/slf4j/compare/v_1.7.36...v_2.0.4;>compare 
view
   
   
   
   
   
   [![Dependabot compatibility 
score](https://dependabot-badges.githubapp.com/badges/compatibility_score?dependency-name=org.slf4j:slf4j-simple=maven=1.7.36=2.0.4)](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
   
   Dependabot will resolve any conflicts with this PR as long as you don't 
alter it yourself. You can also trigger a rebase manually by commenting 
`@dependabot rebase`.
   
   [//]: # (dependabot-automerge-start)
   [//]: # (dependabot-automerge-end)
   
   ---
   
   
   Dependabot commands and options
   
   
   You can trigger Dependabot actions by commenting on this PR:
   - `@dependabot rebase` will rebase this PR
   - `@dependabot recreate` will recreate this PR, overwriting any edits that 
have been made to it
   - `@dependabot merge` will merge this PR after your CI passes on it
   - `@dependabot squash and merge` will squash and merge this PR after your CI 
passes on it
   - `@dependabot cancel merge` will cancel a previously requested merge and 
block automerging
   - `@dependabot reopen` will reopen this PR if it is closed
   - `@dependabot close` will close this PR and stop Dependabot recreating it. 
You can achieve the same result by closing it manually
   - `@dependabot ignore this major version` will close this PR and stop 
Dependabot creating any more for this major version (unless you reopen the PR 
or upgrade to it yourself)
   - `@dependabot ignore this minor version` will close this PR and stop 
Dependabot creating any more for this minor version (unless you reopen the PR 
or upgrade to it yourself)
   - `@dependabot ignore this dependency` will close this PR and stop 
Dependabot creating any more for this dependency (unless you reopen the PR or 
upgrade to it yourself)
   
   
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



[GitHub] [maven-jxr] dependabot[bot] opened a new pull request, #84: Bump slf4j-api from 1.7.36 to 2.0.4

2022-11-18 Thread GitBox


dependabot[bot] opened a new pull request, #84:
URL: https://github.com/apache/maven-jxr/pull/84

   Bumps [slf4j-api](https://github.com/qos-ch/slf4j) from 1.7.36 to 2.0.4.
   
   Commits
   
   https://github.com/qos-ch/slf4j/commit/35dd7ff1e75cf83ffb6784a9537ff92c865e78b2;>35dd7ff
 removed unused META-INF/services entry
   https://github.com/qos-ch/slf4j/commit/440c2f3000fc0e2d7646f0b3d6e36e8bc2ef2485;>440c2f3
 prepare release 2.0.4
   https://github.com/qos-ch/slf4j/commit/43a36303e5a2338c22ec9aad5b01a401034eb553;>43a3630
 use the class loader that loaded LoggerFactory (instead of the 
threadContextC...
   https://github.com/qos-ch/slf4j/commit/557bf7c0bd4e2c2cd85ef389729107461938dd15;>557bf7c
 [SLF4J-548] Fix ServiceLoader usage in servlet environment
   https://github.com/qos-ch/slf4j/commit/632410565b26e4d67fc7ef2ce4c212380b4e59d1;>6324105
 enhance manifest with capabilities
   https://github.com/qos-ch/slf4j/commit/e540299d58bc5f53cab3236cc1b2f29281982074;>e540299
 edit blurb on release championing
   https://github.com/qos-ch/slf4j/commit/dfb41b06a8e5a6aed5e2856edf099fd324822dcf;>dfb41b0
 Update README.md
   https://github.com/qos-ch/slf4j/commit/47c7cc7fa46d883d46b428aab6ef5562a139;>47c7cc7
 clarify Logger.makeLoggingEventBuilder javadoc
   https://github.com/qos-ch/slf4j/commit/0be1bc15f26f11233ee7f657eb5b50fe552a49f1;>0be1bc1
 Merge branch 'master' of github.com:qos-ch/slf4j
   https://github.com/qos-ch/slf4j/commit/d60690c0b9f0e4c89b71236cee9dc14d967d7778;>d60690c
 more flexible way to
   Additional commits viewable in https://github.com/qos-ch/slf4j/compare/v_1.7.36...v_2.0.4;>compare 
view
   
   
   
   
   
   [![Dependabot compatibility 
score](https://dependabot-badges.githubapp.com/badges/compatibility_score?dependency-name=org.slf4j:slf4j-api=maven=1.7.36=2.0.4)](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
   
   Dependabot will resolve any conflicts with this PR as long as you don't 
alter it yourself. You can also trigger a rebase manually by commenting 
`@dependabot rebase`.
   
   [//]: # (dependabot-automerge-start)
   [//]: # (dependabot-automerge-end)
   
   ---
   
   
   Dependabot commands and options
   
   
   You can trigger Dependabot actions by commenting on this PR:
   - `@dependabot rebase` will rebase this PR
   - `@dependabot recreate` will recreate this PR, overwriting any edits that 
have been made to it
   - `@dependabot merge` will merge this PR after your CI passes on it
   - `@dependabot squash and merge` will squash and merge this PR after your CI 
passes on it
   - `@dependabot cancel merge` will cancel a previously requested merge and 
block automerging
   - `@dependabot reopen` will reopen this PR if it is closed
   - `@dependabot close` will close this PR and stop Dependabot recreating it. 
You can achieve the same result by closing it manually
   - `@dependabot ignore this major version` will close this PR and stop 
Dependabot creating any more for this major version (unless you reopen the PR 
or upgrade to it yourself)
   - `@dependabot ignore this minor version` will close this PR and stop 
Dependabot creating any more for this minor version (unless you reopen the PR 
or upgrade to it yourself)
   - `@dependabot ignore this dependency` will close this PR and stop 
Dependabot creating any more for this dependency (unless you reopen the PR or 
upgrade to it yourself)
   
   
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



[jira] [Commented] (MNG-7316) MavenProject.getAttachedArtifacts() regression with 3.8.1

2022-11-18 Thread Gary D. Gregory (Jira)


[ 
https://issues.apache.org/jira/browse/MNG-7316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17635829#comment-17635829
 ] 

Gary D. Gregory commented on MNG-7316:
--

Hi [~michael-o] CC [~chtompki] 

As long as the plugin works, I am not so concerned about how the internals are 
implemented. If you are able to take the time and Rob cannot, I'd appreciate 
the help on a rewrite. 

> MavenProject.getAttachedArtifacts() regression with 3.8.1
> -
>
> Key: MNG-7316
> URL: https://issues.apache.org/jira/browse/MNG-7316
> Project: Maven
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 3.8.2, 3.8.3
>Reporter: Gary D. Gregory
>Priority: Critical
> Fix For: waiting-for-feedback, wontfix-candidate
>
>
> The method {{MavenProject.getAttachedArtifacts()}} as of 3.8.2 breaks 
> releasing components for us at Apache Commons using our Maven Release plugin 
> because the list returned is now immutable, we now get an exception when 
> calling {{remove()}} on the collection returned by the API; see 
> [https://github.com/apache/commons-release-plugin/blob/master/src/main/java/org/apache/commons/release/plugin/mojos/CommonsDistributionDetachmentMojo.java#L137]
> This worked fine in 3.8.1, may you please change it back for 3.8.4?
> We cannot use Maven 3.8.2 and 3.8.3 to release our components.
> ([~michael-o]: Ironically, I discovered this trying to create a release 
> candidate for Apache Commons CLI.)
> The exception in 3.8.3:
> {quote}Caused by: java.lang.UnsupportedOperationException
>  at java.util.Collections$UnmodifiableCollection.remove 
> (Collections.java:1060)
>  at 
> org.apache.commons.release.plugin.mojos.CommonsDistributionDetachmentMojo.execute
>  (CommonsDistributionDetachmentMojo.java:136)
>  at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo 
> (DefaultBuildPluginManager.java:137)
> {quote}
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[GitHub] [maven] cstamas opened a new pull request, #875: Chained LRM

2022-11-18 Thread GitBox


cstamas opened a new pull request, #875:
URL: https://github.com/apache/maven/pull/875

   Not for production, but usable in testing environments.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



[GitHub] [maven-resolver] cstamas opened a new pull request, #223: Chained LRM

2022-11-18 Thread GitBox


cstamas opened a new pull request, #223:
URL: https://github.com/apache/maven-resolver/pull/223

   Not for production, but usable in testing environments.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



[jira] [Commented] (MNG-7316) MavenProject.getAttachedArtifacts() regression with 3.8.1

2022-11-18 Thread Jira


[ 
https://issues.apache.org/jira/browse/MNG-7316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17635824#comment-17635824
 ] 

Christoph Läubrich commented on MNG-7316:
-

As mentioned above, Tycho needs this to remove items that where attached by 
*other* mojos, in this case the compiled results or attached sources are 
compared against a remote service and probably replaced by some other file or 
even removed completely.

> MavenProject.getAttachedArtifacts() regression with 3.8.1
> -
>
> Key: MNG-7316
> URL: https://issues.apache.org/jira/browse/MNG-7316
> Project: Maven
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 3.8.2, 3.8.3
>Reporter: Gary D. Gregory
>Priority: Critical
> Fix For: waiting-for-feedback, wontfix-candidate
>
>
> The method {{MavenProject.getAttachedArtifacts()}} as of 3.8.2 breaks 
> releasing components for us at Apache Commons using our Maven Release plugin 
> because the list returned is now immutable, we now get an exception when 
> calling {{remove()}} on the collection returned by the API; see 
> [https://github.com/apache/commons-release-plugin/blob/master/src/main/java/org/apache/commons/release/plugin/mojos/CommonsDistributionDetachmentMojo.java#L137]
> This worked fine in 3.8.1, may you please change it back for 3.8.4?
> We cannot use Maven 3.8.2 and 3.8.3 to release our components.
> ([~michael-o]: Ironically, I discovered this trying to create a release 
> candidate for Apache Commons CLI.)
> The exception in 3.8.3:
> {quote}Caused by: java.lang.UnsupportedOperationException
>  at java.util.Collections$UnmodifiableCollection.remove 
> (Collections.java:1060)
>  at 
> org.apache.commons.release.plugin.mojos.CommonsDistributionDetachmentMojo.execute
>  (CommonsDistributionDetachmentMojo.java:136)
>  at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo 
> (DefaultBuildPluginManager.java:137)
> {quote}
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Commented] (MNG-7316) MavenProject.getAttachedArtifacts() regression with 3.8.1

2022-11-18 Thread Michael Osipov (Jira)


[ 
https://issues.apache.org/jira/browse/MNG-7316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17635822#comment-17635822
 ] 

Michael Osipov commented on MNG-7316:
-

[~ggregory], I checked the code back then and it does attach and remove just to 
calculate the hash form the provided list. I think this is just unnecessary.

> MavenProject.getAttachedArtifacts() regression with 3.8.1
> -
>
> Key: MNG-7316
> URL: https://issues.apache.org/jira/browse/MNG-7316
> Project: Maven
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 3.8.2, 3.8.3
>Reporter: Gary D. Gregory
>Priority: Critical
> Fix For: waiting-for-feedback, wontfix-candidate
>
>
> The method {{MavenProject.getAttachedArtifacts()}} as of 3.8.2 breaks 
> releasing components for us at Apache Commons using our Maven Release plugin 
> because the list returned is now immutable, we now get an exception when 
> calling {{remove()}} on the collection returned by the API; see 
> [https://github.com/apache/commons-release-plugin/blob/master/src/main/java/org/apache/commons/release/plugin/mojos/CommonsDistributionDetachmentMojo.java#L137]
> This worked fine in 3.8.1, may you please change it back for 3.8.4?
> We cannot use Maven 3.8.2 and 3.8.3 to release our components.
> ([~michael-o]: Ironically, I discovered this trying to create a release 
> candidate for Apache Commons CLI.)
> The exception in 3.8.3:
> {quote}Caused by: java.lang.UnsupportedOperationException
>  at java.util.Collections$UnmodifiableCollection.remove 
> (Collections.java:1060)
>  at 
> org.apache.commons.release.plugin.mojos.CommonsDistributionDetachmentMojo.execute
>  (CommonsDistributionDetachmentMojo.java:136)
>  at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo 
> (DefaultBuildPluginManager.java:137)
> {quote}
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Commented] (MNG-7316) MavenProject.getAttachedArtifacts() regression with 3.8.1

2022-11-18 Thread Gary D. Gregory (Jira)


[ 
https://issues.apache.org/jira/browse/MNG-7316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17635818#comment-17635818
 ] 

Gary D. Gregory commented on MNG-7316:
--

Hi [~michael-o] CC [~chtompki] 

This is part of the black magic of Maven and our plugin that I don't know; I 
hope [~chtompki] can provide an answer. 

 

> MavenProject.getAttachedArtifacts() regression with 3.8.1
> -
>
> Key: MNG-7316
> URL: https://issues.apache.org/jira/browse/MNG-7316
> Project: Maven
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 3.8.2, 3.8.3
>Reporter: Gary D. Gregory
>Priority: Critical
> Fix For: waiting-for-feedback, wontfix-candidate
>
>
> The method {{MavenProject.getAttachedArtifacts()}} as of 3.8.2 breaks 
> releasing components for us at Apache Commons using our Maven Release plugin 
> because the list returned is now immutable, we now get an exception when 
> calling {{remove()}} on the collection returned by the API; see 
> [https://github.com/apache/commons-release-plugin/blob/master/src/main/java/org/apache/commons/release/plugin/mojos/CommonsDistributionDetachmentMojo.java#L137]
> This worked fine in 3.8.1, may you please change it back for 3.8.4?
> We cannot use Maven 3.8.2 and 3.8.3 to release our components.
> ([~michael-o]: Ironically, I discovered this trying to create a release 
> candidate for Apache Commons CLI.)
> The exception in 3.8.3:
> {quote}Caused by: java.lang.UnsupportedOperationException
>  at java.util.Collections$UnmodifiableCollection.remove 
> (Collections.java:1060)
>  at 
> org.apache.commons.release.plugin.mojos.CommonsDistributionDetachmentMojo.execute
>  (CommonsDistributionDetachmentMojo.java:136)
>  at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo 
> (DefaultBuildPluginManager.java:137)
> {quote}
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[GitHub] [maven-pmd-plugin] dependabot[bot] closed pull request #97: Bump slf4jVersion from 1.7.36 to 2.0.3

2022-11-18 Thread GitBox


dependabot[bot] closed pull request #97: Bump slf4jVersion from 1.7.36 to 2.0.3
URL: https://github.com/apache/maven-pmd-plugin/pull/97


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



[GitHub] [maven-pmd-plugin] dependabot[bot] commented on pull request #97: Bump slf4jVersion from 1.7.36 to 2.0.3

2022-11-18 Thread GitBox


dependabot[bot] commented on PR #97:
URL: https://github.com/apache/maven-pmd-plugin/pull/97#issuecomment-1319855364

   Superseded by #102.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



[GitHub] [maven-pmd-plugin] dependabot[bot] opened a new pull request, #102: Bump slf4jVersion from 1.7.36 to 2.0.4

2022-11-18 Thread GitBox


dependabot[bot] opened a new pull request, #102:
URL: https://github.com/apache/maven-pmd-plugin/pull/102

   Bumps `slf4jVersion` from 1.7.36 to 2.0.4.
   Updates `slf4j-api` from 1.7.36 to 2.0.4
   
   Commits
   
   https://github.com/qos-ch/slf4j/commit/35dd7ff1e75cf83ffb6784a9537ff92c865e78b2;>35dd7ff
 removed unused META-INF/services entry
   https://github.com/qos-ch/slf4j/commit/440c2f3000fc0e2d7646f0b3d6e36e8bc2ef2485;>440c2f3
 prepare release 2.0.4
   https://github.com/qos-ch/slf4j/commit/43a36303e5a2338c22ec9aad5b01a401034eb553;>43a3630
 use the class loader that loaded LoggerFactory (instead of the 
threadContextC...
   https://github.com/qos-ch/slf4j/commit/557bf7c0bd4e2c2cd85ef389729107461938dd15;>557bf7c
 [SLF4J-548] Fix ServiceLoader usage in servlet environment
   https://github.com/qos-ch/slf4j/commit/632410565b26e4d67fc7ef2ce4c212380b4e59d1;>6324105
 enhance manifest with capabilities
   https://github.com/qos-ch/slf4j/commit/e540299d58bc5f53cab3236cc1b2f29281982074;>e540299
 edit blurb on release championing
   https://github.com/qos-ch/slf4j/commit/dfb41b06a8e5a6aed5e2856edf099fd324822dcf;>dfb41b0
 Update README.md
   https://github.com/qos-ch/slf4j/commit/47c7cc7fa46d883d46b428aab6ef5562a139;>47c7cc7
 clarify Logger.makeLoggingEventBuilder javadoc
   https://github.com/qos-ch/slf4j/commit/0be1bc15f26f11233ee7f657eb5b50fe552a49f1;>0be1bc1
 Merge branch 'master' of github.com:qos-ch/slf4j
   https://github.com/qos-ch/slf4j/commit/d60690c0b9f0e4c89b71236cee9dc14d967d7778;>d60690c
 more flexible way to
   Additional commits viewable in https://github.com/qos-ch/slf4j/compare/v_1.7.36...v_2.0.4;>compare 
view
   
   
   
   
   Updates `jul-to-slf4j` from 1.7.36 to 2.0.4
   
   Commits
   
   https://github.com/qos-ch/slf4j/commit/35dd7ff1e75cf83ffb6784a9537ff92c865e78b2;>35dd7ff
 removed unused META-INF/services entry
   https://github.com/qos-ch/slf4j/commit/440c2f3000fc0e2d7646f0b3d6e36e8bc2ef2485;>440c2f3
 prepare release 2.0.4
   https://github.com/qos-ch/slf4j/commit/43a36303e5a2338c22ec9aad5b01a401034eb553;>43a3630
 use the class loader that loaded LoggerFactory (instead of the 
threadContextC...
   https://github.com/qos-ch/slf4j/commit/557bf7c0bd4e2c2cd85ef389729107461938dd15;>557bf7c
 [SLF4J-548] Fix ServiceLoader usage in servlet environment
   https://github.com/qos-ch/slf4j/commit/632410565b26e4d67fc7ef2ce4c212380b4e59d1;>6324105
 enhance manifest with capabilities
   https://github.com/qos-ch/slf4j/commit/e540299d58bc5f53cab3236cc1b2f29281982074;>e540299
 edit blurb on release championing
   https://github.com/qos-ch/slf4j/commit/dfb41b06a8e5a6aed5e2856edf099fd324822dcf;>dfb41b0
 Update README.md
   https://github.com/qos-ch/slf4j/commit/47c7cc7fa46d883d46b428aab6ef5562a139;>47c7cc7
 clarify Logger.makeLoggingEventBuilder javadoc
   https://github.com/qos-ch/slf4j/commit/0be1bc15f26f11233ee7f657eb5b50fe552a49f1;>0be1bc1
 Merge branch 'master' of github.com:qos-ch/slf4j
   https://github.com/qos-ch/slf4j/commit/d60690c0b9f0e4c89b71236cee9dc14d967d7778;>d60690c
 more flexible way to
   Additional commits viewable in https://github.com/qos-ch/slf4j/compare/v_1.7.36...v_2.0.4;>compare 
view
   
   
   
   
   Updates `slf4j-simple` from 1.7.36 to 2.0.4
   
   Commits
   
   https://github.com/qos-ch/slf4j/commit/35dd7ff1e75cf83ffb6784a9537ff92c865e78b2;>35dd7ff
 removed unused META-INF/services entry
   https://github.com/qos-ch/slf4j/commit/440c2f3000fc0e2d7646f0b3d6e36e8bc2ef2485;>440c2f3
 prepare release 2.0.4
   https://github.com/qos-ch/slf4j/commit/43a36303e5a2338c22ec9aad5b01a401034eb553;>43a3630
 use the class loader that loaded LoggerFactory (instead of the 
threadContextC...
   https://github.com/qos-ch/slf4j/commit/557bf7c0bd4e2c2cd85ef389729107461938dd15;>557bf7c
 [SLF4J-548] Fix ServiceLoader usage in servlet environment
   https://github.com/qos-ch/slf4j/commit/632410565b26e4d67fc7ef2ce4c212380b4e59d1;>6324105
 enhance manifest with capabilities
   https://github.com/qos-ch/slf4j/commit/e540299d58bc5f53cab3236cc1b2f29281982074;>e540299
 edit blurb on release championing
   https://github.com/qos-ch/slf4j/commit/dfb41b06a8e5a6aed5e2856edf099fd324822dcf;>dfb41b0
 Update README.md
   https://github.com/qos-ch/slf4j/commit/47c7cc7fa46d883d46b428aab6ef5562a139;>47c7cc7
 clarify Logger.makeLoggingEventBuilder javadoc
   https://github.com/qos-ch/slf4j/commit/0be1bc15f26f11233ee7f657eb5b50fe552a49f1;>0be1bc1
 Merge branch 'master' of github.com:qos-ch/slf4j
   https://github.com/qos-ch/slf4j/commit/d60690c0b9f0e4c89b71236cee9dc14d967d7778;>d60690c
 more flexible way to
   Additional commits viewable in https://github.com/qos-ch/slf4j/compare/v_1.7.36...v_2.0.4;>compare 
view
   
   
   
   
   
   Dependabot will resolve any conflicts with this PR as long as you don't 
alter it yourself. You can also trigger a rebase manually by commenting 
`@dependabot rebase`.
   
   [//]: # (dependabot-automerge-start)
   [//]: # (dependabot-automerge-end)
   
   ---
   

[jira] [Commented] (MRESOLVER-269) Allow more compact storage of provided checksums

2022-11-18 Thread Hudson (Jira)


[ 
https://issues.apache.org/jira/browse/MRESOLVER-269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17635795#comment-17635795
 ] 

Hudson commented on MRESOLVER-269:
--

Build succeeded in Jenkins: Maven » Maven TLP » maven-resolver » master #88

See 
https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven-resolver/job/master/88/

> Allow more compact storage of provided checksums
> 
>
> Key: MRESOLVER-269
> URL: https://issues.apache.org/jira/browse/MRESOLVER-269
> Project: Maven Resolver
>  Issue Type: Improvement
>  Components: Resolver
>Reporter: Rafael Winterhalter
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 1.9.0
>
>
> While the repository layout makes sense for storage outside of a project, it 
> would be more convenient to store checksums in a single file (per algorithm) 
> when keeping checksums along when storing these checksums within a project. 
> This makes the storage easier to version control and avoids the overhead of 
> storing a lot of files in version control what often creates some overhead.
> Ideally, Maven could support such files out of the box by shipping a provider 
> for such files.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Commented] (MRESOLVER-269) Allow more compact storage of provided checksums

2022-11-18 Thread ASF GitHub Bot (Jira)


[ 
https://issues.apache.org/jira/browse/MRESOLVER-269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17635793#comment-17635793
 ] 

ASF GitHub Bot commented on MRESOLVER-269:
--

cstamas merged PR #222:
URL: https://github.com/apache/maven-resolver/pull/222




> Allow more compact storage of provided checksums
> 
>
> Key: MRESOLVER-269
> URL: https://issues.apache.org/jira/browse/MRESOLVER-269
> Project: Maven Resolver
>  Issue Type: Improvement
>  Components: Resolver
>Reporter: Rafael Winterhalter
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 1.9.0
>
>
> While the repository layout makes sense for storage outside of a project, it 
> would be more convenient to store checksums in a single file (per algorithm) 
> when keeping checksums along when storing these checksums within a project. 
> This makes the storage easier to version control and avoids the overhead of 
> storing a lot of files in version control what often creates some overhead.
> Ideally, Maven could support such files out of the box by shipping a provider 
> for such files.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Closed] (MRESOLVER-296) FileProcessor.write( File, InputStream ) is defunct

2022-11-18 Thread Tamas Cservenak (Jira)


 [ 
https://issues.apache.org/jira/browse/MRESOLVER-296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tamas Cservenak closed MRESOLVER-296.
-
Resolution: Fixed

> FileProcessor.write( File, InputStream ) is defunct
> ---
>
> Key: MRESOLVER-296
> URL: https://issues.apache.org/jira/browse/MRESOLVER-296
> Project: Maven Resolver
>  Issue Type: Bug
>  Components: Resolver
>Affects Versions: 1.9.1
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Blocker
> Fix For: 1.9.2
>
>
> The FileProcessor.write( File, InputStream ) is wrong, it always fails. This 
> method is used ONLY when FileTransformer is present.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[GitHub] [maven-resolver] cstamas merged pull request #222: [MRESOLVER-269] FileProcessor.write( File, InputStream ) is defunct

2022-11-18 Thread GitBox


cstamas merged PR #222:
URL: https://github.com/apache/maven-resolver/pull/222


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



[jira] [Commented] (MNG-7586) Update Maven Resolver to 1.9.1

2022-11-18 Thread Hudson (Jira)


[ 
https://issues.apache.org/jira/browse/MNG-7586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17635776#comment-17635776
 ] 

Hudson commented on MNG-7586:
-

Build succeeded in Jenkins: Maven » Maven TLP » maven » maven-3.9.x #84

See 
https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven/job/maven-3.9.x/84/

> Update Maven Resolver to 1.9.1
> --
>
> Key: MNG-7586
> URL: https://issues.apache.org/jira/browse/MNG-7586
> Project: Maven
>  Issue Type: Dependency upgrade
>  Components: Dependencies
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 3.9.0, 4.0.0-alpha-3
>
>




--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Commented] (MNG-7316) MavenProject.getAttachedArtifacts() regression with 3.8.1

2022-11-18 Thread Michael Osipov (Jira)


[ 
https://issues.apache.org/jira/browse/MNG-7316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17635759#comment-17635759
 ] 

Michael Osipov commented on MNG-7316:
-

[~ggregory], regardless of the revert, the actually question for Commons 
remains: Why attach when it is removed afterwards? Why not attach it in the 
first place?

I think a revert would be reasonable, but still open how to handle with 3.9.0 
and 4. Obvioulsy, an API improvement is required, e.g., {{#removeArtifact()}} 
or similar.

> MavenProject.getAttachedArtifacts() regression with 3.8.1
> -
>
> Key: MNG-7316
> URL: https://issues.apache.org/jira/browse/MNG-7316
> Project: Maven
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 3.8.2, 3.8.3
>Reporter: Gary D. Gregory
>Priority: Critical
> Fix For: waiting-for-feedback, wontfix-candidate
>
>
> The method {{MavenProject.getAttachedArtifacts()}} as of 3.8.2 breaks 
> releasing components for us at Apache Commons using our Maven Release plugin 
> because the list returned is now immutable, we now get an exception when 
> calling {{remove()}} on the collection returned by the API; see 
> [https://github.com/apache/commons-release-plugin/blob/master/src/main/java/org/apache/commons/release/plugin/mojos/CommonsDistributionDetachmentMojo.java#L137]
> This worked fine in 3.8.1, may you please change it back for 3.8.4?
> We cannot use Maven 3.8.2 and 3.8.3 to release our components.
> ([~michael-o]: Ironically, I discovered this trying to create a release 
> candidate for Apache Commons CLI.)
> The exception in 3.8.3:
> {quote}Caused by: java.lang.UnsupportedOperationException
>  at java.util.Collections$UnmodifiableCollection.remove 
> (Collections.java:1060)
>  at 
> org.apache.commons.release.plugin.mojos.CommonsDistributionDetachmentMojo.execute
>  (CommonsDistributionDetachmentMojo.java:136)
>  at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo 
> (DefaultBuildPluginManager.java:137)
> {quote}
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[GitHub] [maven-dependency-plugin] dependabot[bot] commented on pull request #263: Bump slf4j-simple from 1.7.36 to 2.0.4

2022-11-18 Thread GitBox


dependabot[bot] commented on PR #263:
URL: 
https://github.com/apache/maven-dependency-plugin/pull/263#issuecomment-1319683397

   OK, I won't notify you about version 2.x.x again, unless you re-open this 
PR. 


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



[GitHub] [maven-dependency-plugin] slachiewicz commented on pull request #263: Bump slf4j-simple from 1.7.36 to 2.0.4

2022-11-18 Thread GitBox


slachiewicz commented on PR #263:
URL: 
https://github.com/apache/maven-dependency-plugin/pull/263#issuecomment-1319683367

   @dependabot ignore this major version


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



[GitHub] [maven-dependency-plugin] dependabot[bot] closed pull request #263: Bump slf4j-simple from 1.7.36 to 2.0.4

2022-11-18 Thread GitBox


dependabot[bot] closed pull request #263: Bump slf4j-simple from 1.7.36 to 2.0.4
URL: https://github.com/apache/maven-dependency-plugin/pull/263


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



[GitHub] [maven-site-plugin] dependabot[bot] commented on pull request #109: Bump slf4jVersion from 1.7.36 to 2.0.4

2022-11-18 Thread GitBox


dependabot[bot] commented on PR #109:
URL: 
https://github.com/apache/maven-site-plugin/pull/109#issuecomment-1319681789

   OK, I won't notify you about version 2.x.x again, unless you re-open this 
PR. 


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



[GitHub] [maven-site-plugin] dependabot[bot] closed pull request #109: Bump slf4jVersion from 1.7.36 to 2.0.4

2022-11-18 Thread GitBox


dependabot[bot] closed pull request #109: Bump slf4jVersion from 1.7.36 to 2.0.4
URL: https://github.com/apache/maven-site-plugin/pull/109


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



[GitHub] [maven-site-plugin] slachiewicz commented on pull request #109: Bump slf4jVersion from 1.7.36 to 2.0.4

2022-11-18 Thread GitBox


slachiewicz commented on PR #109:
URL: 
https://github.com/apache/maven-site-plugin/pull/109#issuecomment-1319681753

   @dependabot ignore this major version


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



[GitHub] [maven-indexer] dependabot[bot] commented on pull request #266: Bump slf4j.version from 1.7.36 to 2.0.4

2022-11-18 Thread GitBox


dependabot[bot] commented on PR #266:
URL: https://github.com/apache/maven-indexer/pull/266#issuecomment-1319681566

   OK, I won't notify you about version 2.x.x again, unless you re-open this 
PR. 


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



[GitHub] [maven-indexer] slachiewicz commented on pull request #266: Bump slf4j.version from 1.7.36 to 2.0.4

2022-11-18 Thread GitBox


slachiewicz commented on PR #266:
URL: https://github.com/apache/maven-indexer/pull/266#issuecomment-1319681534

   @dependabot ignore this major version


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



[GitHub] [maven-indexer] dependabot[bot] closed pull request #266: Bump slf4j.version from 1.7.36 to 2.0.4

2022-11-18 Thread GitBox


dependabot[bot] closed pull request #266: Bump slf4j.version from 1.7.36 to 
2.0.4
URL: https://github.com/apache/maven-indexer/pull/266


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



[GitHub] [maven-script-interpreter] dependabot[bot] commented on pull request #82: Bump slf4j.version from 1.7.36 to 2.0.4

2022-11-18 Thread GitBox


dependabot[bot] commented on PR #82:
URL: 
https://github.com/apache/maven-script-interpreter/pull/82#issuecomment-1319681315

   OK, I won't notify you about version 2.x.x again, unless you re-open this 
PR. 


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



[GitHub] [maven-script-interpreter] dependabot[bot] closed pull request #82: Bump slf4j.version from 1.7.36 to 2.0.4

2022-11-18 Thread GitBox


dependabot[bot] closed pull request #82: Bump slf4j.version from 1.7.36 to 2.0.4
URL: https://github.com/apache/maven-script-interpreter/pull/82


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



[GitHub] [maven-script-interpreter] slachiewicz commented on pull request #82: Bump slf4j.version from 1.7.36 to 2.0.4

2022-11-18 Thread GitBox


slachiewicz commented on PR #82:
URL: 
https://github.com/apache/maven-script-interpreter/pull/82#issuecomment-1319681285

   @dependabot ignore this major version


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



[GitHub] [maven-shade-plugin] dependabot[bot] commented on pull request #165: Bump slf4j.version from 1.7.32 to 2.0.4

2022-11-18 Thread GitBox


dependabot[bot] commented on PR #165:
URL: 
https://github.com/apache/maven-shade-plugin/pull/165#issuecomment-1319681133

   OK, I won't notify you about version 2.x.x again, unless you re-open this 
PR. 


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



[GitHub] [maven-shade-plugin] dependabot[bot] closed pull request #165: Bump slf4j.version from 1.7.32 to 2.0.4

2022-11-18 Thread GitBox


dependabot[bot] closed pull request #165: Bump slf4j.version from 1.7.32 to 
2.0.4
URL: https://github.com/apache/maven-shade-plugin/pull/165


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



[GitHub] [maven-shade-plugin] slachiewicz commented on pull request #165: Bump slf4j.version from 1.7.32 to 2.0.4

2022-11-18 Thread GitBox


slachiewicz commented on PR #165:
URL: 
https://github.com/apache/maven-shade-plugin/pull/165#issuecomment-1319681090

   @dependabot ignore this major version


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



[GitHub] [maven-invoker-plugin] dependabot[bot] commented on pull request #151: Bump slf4j-simple from 1.7.36 to 2.0.4

2022-11-18 Thread GitBox


dependabot[bot] commented on PR #151:
URL: 
https://github.com/apache/maven-invoker-plugin/pull/151#issuecomment-1319680806

   OK, I won't notify you about version 2.x.x again, unless you re-open this 
PR. 


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



[GitHub] [maven-invoker-plugin] dependabot[bot] closed pull request #151: Bump slf4j-simple from 1.7.36 to 2.0.4

2022-11-18 Thread GitBox


dependabot[bot] closed pull request #151: Bump slf4j-simple from 1.7.36 to 2.0.4
URL: https://github.com/apache/maven-invoker-plugin/pull/151


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



[GitHub] [maven-invoker-plugin] slachiewicz commented on pull request #151: Bump slf4j-simple from 1.7.36 to 2.0.4

2022-11-18 Thread GitBox


slachiewicz commented on PR #151:
URL: 
https://github.com/apache/maven-invoker-plugin/pull/151#issuecomment-1319680751

   @dependabot ignore this major version


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



[GitHub] [maven-checkstyle-plugin] dependabot[bot] commented on pull request #99: Bump slf4j-simple from 1.7.36 to 2.0.4

2022-11-18 Thread GitBox


dependabot[bot] commented on PR #99:
URL: 
https://github.com/apache/maven-checkstyle-plugin/pull/99#issuecomment-1319680224

   OK, I won't notify you about version 2.x.x again, unless you re-open this 
PR. 


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



[GitHub] [maven-checkstyle-plugin] dependabot[bot] closed pull request #99: Bump slf4j-simple from 1.7.36 to 2.0.4

2022-11-18 Thread GitBox


dependabot[bot] closed pull request #99: Bump slf4j-simple from 1.7.36 to 2.0.4
URL: https://github.com/apache/maven-checkstyle-plugin/pull/99


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



[GitHub] [maven-checkstyle-plugin] slachiewicz commented on pull request #99: Bump slf4j-simple from 1.7.36 to 2.0.4

2022-11-18 Thread GitBox


slachiewicz commented on PR #99:
URL: 
https://github.com/apache/maven-checkstyle-plugin/pull/99#issuecomment-1319680183

   @dependabot ignore this major version


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



[GitHub] [maven-verifier] slachiewicz commented on pull request #61: Bump slf4j-simple from 1.7.36 to 2.0.4

2022-11-18 Thread GitBox


slachiewicz commented on PR #61:
URL: https://github.com/apache/maven-verifier/pull/61#issuecomment-1319679405

   @dependabot ignore this major version


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



[GitHub] [maven-verifier] dependabot[bot] commented on pull request #61: Bump slf4j-simple from 1.7.36 to 2.0.4

2022-11-18 Thread GitBox


dependabot[bot] commented on PR #61:
URL: https://github.com/apache/maven-verifier/pull/61#issuecomment-1319679449

   OK, I won't notify you about version 2.x.x again, unless you re-open this 
PR. 


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



[GitHub] [maven-verifier] dependabot[bot] closed pull request #61: Bump slf4j-simple from 1.7.36 to 2.0.4

2022-11-18 Thread GitBox


dependabot[bot] closed pull request #61: Bump slf4j-simple from 1.7.36 to 2.0.4
URL: https://github.com/apache/maven-verifier/pull/61


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org