Re: [VOTE] PIP-280 : Refactor CLI Argument Parsing Logic for Measurement Units using JCommander's custom converter
+1 (non-binding) Thanks, Ran Gao On 2023/07/07 09:25:22 Joo Hyuk Kim wrote: > Hi community, > > This PIP has received a couple of approvals in github PR link [1] > So I thought it's time to vote. > > ## Motivation > > In the current Pulsar codebase, the logic to parse CLI arguments for > measurement units like time and bytes is > > scattered across various CLI classes. Each value read has its distinct > parsing implementation, leading to a lack of code > > reuse. > > > ## Goals > > > This PIP is to refactor the argument parsing logic to leverage the > `@Parameter.converter` > > functionality provided by JCommander [link 3]. This will isolate the > measurement-specific parsing logic and increase > > code > > reusability. > > > ### In Scope > > > - Refactor all `Cmd` classes to utilize the converter functionality of > JCommander. This will streamline the parsing > > logic and simplify the codebase. > > - Refer to bottom section "Concrete Example", before "Links" > > - Or on-going PR with small use case in > https://github.com/apache/pulsar/pull/20663 > > > ## links > > > [1] PR : https://github.com/apache/pulsar/pull/20691 > > > > Best regards, > > JooHyukKim (Vince) >
CVE-2023-37579: Apache Pulsar Function Worker: Incorrect Authorization for Function Worker Can Leak Sink/Source Credentials
Affected versions: - Apache Pulsar Function Worker before 2.10.4 - Apache Pulsar Function Worker 2.11.0 Description: Incorrect Authorization vulnerability in Apache Software Foundation Apache Pulsar Function Worker. This issue affects Apache Pulsar: before 2.10.4, and 2.11.0. Any authenticated user can retrieve a source's configuration or a sink's configuration without authorization. Many sources and sinks contain credentials in the configuration, which could lead to leaked credentials. This vulnerability is mitigated by the fact that there is not a known way for an authenticated user to enumerate another tenant's sources or sinks, meaning the source or sink name would need to be guessed in order to exploit this vulnerability. The recommended mitigation for impacted users is to upgrade the Pulsar Function Worker to a patched version. 2.10 Pulsar Function Worker users should upgrade to at least 2.10.4. 2.11 Pulsar Function Worker users should upgrade to at least 2.11.1. 3.0 Pulsar Function Worker users are unaffected. Any users running the Pulsar Function Worker for 2.9.* and earlier should upgrade to one of the above patched versions. Credit: Michael Marshall of DataStax (finder) References: https://pulsar.apache.org/ https://www.cve.org/CVERecord?id=CVE-2023-37579
CVE-2023-31007: Apache Pulsar: Broker does not always disconnect client when authentication data expires
Affected versions: - Apache Pulsar before 2.9.5 - Apache Pulsar 2.10.0 through 2.10.3 - Apache Pulsar 2.11.0 Description: Improper Authentication vulnerability in Apache Software Foundation Apache Pulsar Broker allows a client to stay connected to a broker after authentication data expires if the client connected through the Pulsar Proxy when the broker is configured with authenticateOriginalAuthData=false or if a client connects directly to a broker with a specially crafted connect command when the broker is configured with authenticateOriginalAuthData=false. This issue affects Apache Pulsar: through 2.9.4, from 2.10.0 through 2.10.3, 2.11.0. 2.9 Pulsar Broker users should upgrade to at least 2.9.5. 2.10 Pulsar Broker users should upgrade to at least 2.10.4. 2.11 Pulsar Broker users should upgrade to at least 2.11.1. 3.0 Pulsar Broker users are unaffected. Any users running the Pulsar Broker for 2.8.* and earlier should upgrade to one of the above patched versions. Credit: Michael Marshall of DataStax (finder) References: https://pulsar.apache.org/ https://www.cve.org/CVERecord?id=CVE-2023-31007
CVE-2023-30429: Apache Pulsar: Incorrect Authorization for Function Worker when using mTLS Authentication through Pulsar Proxy
Affected versions: - Apache Pulsar before 2.10.4 - Apache Pulsar 2.11.0 Description: Incorrect Authorization vulnerability in Apache Software Foundation Apache Pulsar. This issue affects Apache Pulsar: before 2.10.4, and 2.11.0. When a client connects to the Pulsar Function Worker via the Pulsar Proxy where the Pulsar Proxy uses mTLS authentication to authenticate with the Pulsar Function Worker, the Pulsar Function Worker incorrectly performs authorization by using the Proxy's role for authorization instead of the client's role, which can lead to privilege escalation, especially if the proxy is configured with a superuser role. The recommended mitigation for impacted users is to upgrade the Pulsar Function Worker to a patched version. 2.10 Pulsar Function Worker users should upgrade to at least 2.10.4. 2.11 Pulsar Function Worker users should upgrade to at least 2.11.1. 3.0 Pulsar Function Worker users are unaffected. Any users running the Pulsar Function Worker for 2.9.* and earlier should upgrade to one of the above patched versions. Credit: Michael Marshall of DataStax (finder) References: https://pulsar.apache.org/ https://www.cve.org/CVERecord?id=CVE-2023-30429
CVE-2023-30428: Apache Pulsar Broker: Incorrect Authorization Validation for Rest Producer
Affected versions: - Apache Pulsar Broker 2.9.0 through 2.9.5 - Apache Pulsar Broker 2.10.0 before 2.10.4 - Apache Pulsar Broker 2.11.0 Description: Incorrect Authorization vulnerability in Apache Software Foundation Apache Pulsar Broker's Rest Producer allows authenticated user with a custom HTTP header to produce a message to any topic using the broker's admin role. This issue affects Apache Pulsar Brokers: from 2.9.0 through 2.9.5, from 2.10.0 before 2.10.4, 2.11.0. The vulnerability is exploitable when an attacker can connect directly to the Pulsar Broker. If an attacker is connecting through the Pulsar Proxy, there is no known way to exploit this authorization vulnerability. There are two known risks for affected users. First, an attacker could produce garbage messages to any topic in the cluster. Second, an attacker could produce messages to the topic level policies topic for other tenants and influence topic settings that could lead to exfiltration and/or deletion of messages for other tenants. 2.8 Pulsar Broker users and earlier are unaffected. 2.9 Pulsar Broker users should upgrade to one of the patched versions. 2.10 Pulsar Broker users should upgrade to at least 2.10.4. 2.11 Pulsar Broker users should upgrade to at least 2.11.1. 3.0 Pulsar Broker users are unaffected. Credit: Michael Marshall of DataStax (finder) References: https://pulsar.apache.org/ https://www.cve.org/CVERecord?id=CVE-2023-30428
Re: [VOTE] PIP-280 : Refactor CLI Argument Parsing Logic for Measurement Units using JCommander's custom converter
Hi community, Thank you all for your participation. We may close the vote with the following result. 1 of (+1 non-binding) - Zili Chen 3 of (+1 binding) - Yunze Xu - Mattison (Qiang Zhao) - Nicolò Boschi Best regards JooHyukKim (Vince) On Tue, Jul 11, 2023 at 7:04 PM Joo Hyuk Kim wrote: > > As long as we don't introduce any breaking change and the new parameters > > are covered by unit test > > Made a commit(Link [1]) to improve considerations > > Link [1] > https://github.com/apache/pulsar/pull/20691/commits/96515b85e97a56133a512165c981361fab939ec1 > > Thanks, > JooHyukKim (Vince) > > On Tue, Jul 11, 2023 at 6:58 PM Joo Hyuk Kim wrote: > >> > As long as we don't introduce any breaking change and the new >> parameters are covered by unit test >> >> Hello, thank you for your feedback. >> I agree and will add following to PIP file. >> "The refactored parameters should maintain coverage. " >> >> On Tue, Jul 11, 2023 at 6:34 PM Nicolò Boschi >> wrote: >> >>> +1 binding >>> As long as we don't introduce any breaking change and the new parameters >>> are covered by unit test >>> >>> Thanks, >>> Nicolò Boschi >>> >>> >>> Il giorno mar 11 lug 2023 alle ore 05:00 Qiang Zhao < >>> mattisonc...@apache.org> >>> ha scritto: >>> >>> > +1(binding) >>> > >>> > Best, >>> > Mattison >>> > >>> > On 2023/07/07 09:25:22 Joo Hyuk Kim wrote: >>> > > Hi community, >>> > > >>> > > This PIP has received a couple of approvals in github PR link [1] >>> > > So I thought it's time to vote. >>> > > >>> > > ## Motivation >>> > > >>> > > In the current Pulsar codebase, the logic to parse CLI arguments for >>> > > measurement units like time and bytes is >>> > > >>> > > scattered across various CLI classes. Each value read has its >>> distinct >>> > > parsing implementation, leading to a lack of code >>> > > >>> > > reuse. >>> > > >>> > > >>> > > ## Goals >>> > > >>> > > >>> > > This PIP is to refactor the argument parsing logic to leverage the >>> > > `@Parameter.converter` >>> > > >>> > > functionality provided by JCommander [link 3]. This will isolate the >>> > > measurement-specific parsing logic and increase >>> > > >>> > > code >>> > > >>> > > reusability. >>> > > >>> > > >>> > > ### In Scope >>> > > >>> > > >>> > > - Refactor all `Cmd` classes to utilize the converter functionality >>> of >>> > > JCommander. This will streamline the parsing >>> > > >>> > > logic and simplify the codebase. >>> > > >>> > > - Refer to bottom section "Concrete Example", before "Links" >>> > > >>> > > - Or on-going PR with small use case in >>> > > https://github.com/apache/pulsar/pull/20663 >>> > > >>> > > >>> > > ## links >>> > > >>> > > >>> > > [1] PR : https://github.com/apache/pulsar/pull/20691 >>> > > >>> > > >>> > > >>> > > Best regards, >>> > > >>> > > JooHyukKim (Vince) >>> > > >>> > >>> >>
Re: [VOTE] PIP-280 : Refactor CLI Argument Parsing Logic for Measurement Units using JCommander's custom converter
> As long as we don't introduce any breaking change and the new parameters > are covered by unit test Made a commit(Link [1]) to improve considerations Link [1] https://github.com/apache/pulsar/pull/20691/commits/96515b85e97a56133a512165c981361fab939ec1 Thanks, JooHyukKim (Vince) On Tue, Jul 11, 2023 at 6:58 PM Joo Hyuk Kim wrote: > > As long as we don't introduce any breaking change and the new parameters > are covered by unit test > > Hello, thank you for your feedback. > I agree and will add following to PIP file. > "The refactored parameters should maintain coverage. " > > On Tue, Jul 11, 2023 at 6:34 PM Nicolò Boschi > wrote: > >> +1 binding >> As long as we don't introduce any breaking change and the new parameters >> are covered by unit test >> >> Thanks, >> Nicolò Boschi >> >> >> Il giorno mar 11 lug 2023 alle ore 05:00 Qiang Zhao < >> mattisonc...@apache.org> >> ha scritto: >> >> > +1(binding) >> > >> > Best, >> > Mattison >> > >> > On 2023/07/07 09:25:22 Joo Hyuk Kim wrote: >> > > Hi community, >> > > >> > > This PIP has received a couple of approvals in github PR link [1] >> > > So I thought it's time to vote. >> > > >> > > ## Motivation >> > > >> > > In the current Pulsar codebase, the logic to parse CLI arguments for >> > > measurement units like time and bytes is >> > > >> > > scattered across various CLI classes. Each value read has its distinct >> > > parsing implementation, leading to a lack of code >> > > >> > > reuse. >> > > >> > > >> > > ## Goals >> > > >> > > >> > > This PIP is to refactor the argument parsing logic to leverage the >> > > `@Parameter.converter` >> > > >> > > functionality provided by JCommander [link 3]. This will isolate the >> > > measurement-specific parsing logic and increase >> > > >> > > code >> > > >> > > reusability. >> > > >> > > >> > > ### In Scope >> > > >> > > >> > > - Refactor all `Cmd` classes to utilize the converter functionality of >> > > JCommander. This will streamline the parsing >> > > >> > > logic and simplify the codebase. >> > > >> > > - Refer to bottom section "Concrete Example", before "Links" >> > > >> > > - Or on-going PR with small use case in >> > > https://github.com/apache/pulsar/pull/20663 >> > > >> > > >> > > ## links >> > > >> > > >> > > [1] PR : https://github.com/apache/pulsar/pull/20691 >> > > >> > > >> > > >> > > Best regards, >> > > >> > > JooHyukKim (Vince) >> > > >> > >> >
Re: [VOTE] PIP-280 : Refactor CLI Argument Parsing Logic for Measurement Units using JCommander's custom converter
> As long as we don't introduce any breaking change and the new parameters are covered by unit test Hello, thank you for your feedback. I agree and will add following to PIP file. "The refactored parameters should maintain coverage. " On Tue, Jul 11, 2023 at 6:34 PM Nicolò Boschi wrote: > +1 binding > As long as we don't introduce any breaking change and the new parameters > are covered by unit test > > Thanks, > Nicolò Boschi > > > Il giorno mar 11 lug 2023 alle ore 05:00 Qiang Zhao < > mattisonc...@apache.org> > ha scritto: > > > +1(binding) > > > > Best, > > Mattison > > > > On 2023/07/07 09:25:22 Joo Hyuk Kim wrote: > > > Hi community, > > > > > > This PIP has received a couple of approvals in github PR link [1] > > > So I thought it's time to vote. > > > > > > ## Motivation > > > > > > In the current Pulsar codebase, the logic to parse CLI arguments for > > > measurement units like time and bytes is > > > > > > scattered across various CLI classes. Each value read has its distinct > > > parsing implementation, leading to a lack of code > > > > > > reuse. > > > > > > > > > ## Goals > > > > > > > > > This PIP is to refactor the argument parsing logic to leverage the > > > `@Parameter.converter` > > > > > > functionality provided by JCommander [link 3]. This will isolate the > > > measurement-specific parsing logic and increase > > > > > > code > > > > > > reusability. > > > > > > > > > ### In Scope > > > > > > > > > - Refactor all `Cmd` classes to utilize the converter functionality of > > > JCommander. This will streamline the parsing > > > > > > logic and simplify the codebase. > > > > > > - Refer to bottom section "Concrete Example", before "Links" > > > > > > - Or on-going PR with small use case in > > > https://github.com/apache/pulsar/pull/20663 > > > > > > > > > ## links > > > > > > > > > [1] PR : https://github.com/apache/pulsar/pull/20691 > > > > > > > > > > > > Best regards, > > > > > > JooHyukKim (Vince) > > > > > >
Re: [VOTE] PIP-280 : Refactor CLI Argument Parsing Logic for Measurement Units using JCommander's custom converter
+1 binding As long as we don't introduce any breaking change and the new parameters are covered by unit test Thanks, Nicolò Boschi Il giorno mar 11 lug 2023 alle ore 05:00 Qiang Zhao ha scritto: > +1(binding) > > Best, > Mattison > > On 2023/07/07 09:25:22 Joo Hyuk Kim wrote: > > Hi community, > > > > This PIP has received a couple of approvals in github PR link [1] > > So I thought it's time to vote. > > > > ## Motivation > > > > In the current Pulsar codebase, the logic to parse CLI arguments for > > measurement units like time and bytes is > > > > scattered across various CLI classes. Each value read has its distinct > > parsing implementation, leading to a lack of code > > > > reuse. > > > > > > ## Goals > > > > > > This PIP is to refactor the argument parsing logic to leverage the > > `@Parameter.converter` > > > > functionality provided by JCommander [link 3]. This will isolate the > > measurement-specific parsing logic and increase > > > > code > > > > reusability. > > > > > > ### In Scope > > > > > > - Refactor all `Cmd` classes to utilize the converter functionality of > > JCommander. This will streamline the parsing > > > > logic and simplify the codebase. > > > > - Refer to bottom section "Concrete Example", before "Links" > > > > - Or on-going PR with small use case in > > https://github.com/apache/pulsar/pull/20663 > > > > > > ## links > > > > > > [1] PR : https://github.com/apache/pulsar/pull/20691 > > > > > > > > Best regards, > > > > JooHyukKim (Vince) > > >
