[GitHub] [maven-parent] olamy commented on pull request #81: [MPOM-348] Drop configuration for not used Maven Changes Plugin
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
[ 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
[ 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
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
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
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
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
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
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
[ 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
[ 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
[ 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.
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.
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
[ 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
[ 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
[ 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
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
[ 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
[ 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
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
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
[ 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
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
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
[ 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
[ 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
[ 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
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
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
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
[ 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
[ 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
[ 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
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
[ 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
[ 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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