Skip to content

HOTFIX: check logic of KAFKA-2515 should be on buffer.limit()#332

Closed
guozhangwang wants to merge 2 commits into
apache:trunkfrom
guozhangwang:K2515-hotfix
Closed

HOTFIX: check logic of KAFKA-2515 should be on buffer.limit()#332
guozhangwang wants to merge 2 commits into
apache:trunkfrom
guozhangwang:K2515-hotfix

Conversation

@guozhangwang

Copy link
Copy Markdown
Contributor

No description provided.

@guozhangwang

Copy link
Copy Markdown
Contributor Author

Ping @junrao @ewencp for reviews.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

an non-empty => a non-empty

@junrao

junrao commented Oct 20, 2015

Copy link
Copy Markdown
Contributor

Thanks for the patch. Just a minor comment. Otherwise, LGTM.

@ewencp

ewencp commented Oct 20, 2015

Copy link
Copy Markdown
Contributor

Agreed, LGTM and validated that this was (at least one case...) causing the system tests to fail.

@asfgit asfgit closed this in 8f32617 Oct 20, 2015
@guozhangwang
guozhangwang deleted the K2515-hotfix branch October 7, 2016 21:47
wyuka pushed a commit to wyuka/kafka that referenced this pull request May 16, 2022
LI_DESCRIPTION =
Linkedin internal system blocks jar import on dependencies that declares a dependency transitively.
For example, with a dependency chain

```
A > B > C
```

when C is found vulnerable, both A & B will be blocked, which is normal.

However, if A pins a fixed C' and the dependency becomes

```
A > B > C
  > C'

// Which should resolve to A, B, C'
```
A is still blocked even if the whole dependency resolution does not
include vulnerable C, because the system still blocks B, and it thinks
"A is not usable without B", thus rejecting importing A.

In order to get over this, we have to down pin B to a lib that already
exists internally (in this specific use case, all non-`databind` `jackson`
dependencies) while maintaining the directly vulnerable library C (in
this case, `jackson-databind`) pinned to a fixed, non-vulnerable
version.

TICKET = CVE-2020-36518, KAFKA-13775
EXIT_CRITERIA = "When upstream bumps all `jackson` series to >= `2.13.3`"
wyuka pushed a commit to wyuka/kafka that referenced this pull request Jun 16, 2022
LI_DESCRIPTION =
Linkedin internal system blocks jar import on dependencies that declares a dependency transitively.
For example, with a dependency chain

```
A > B > C
```

when C is found vulnerable, both A & B will be blocked, which is normal.

However, if A pins a fixed C' and the dependency becomes

```
A > B > C
  > C'

// Which should resolve to A, B, C'
```
A is still blocked even if the whole dependency resolution does not
include vulnerable C, because the system still blocks B, and it thinks
"A is not usable without B", thus rejecting importing A.

In order to get over this, we have to down pin B to a lib that already
exists internally (in this specific use case, all non-`databind` `jackson`
dependencies) while maintaining the directly vulnerable library C (in
this case, `jackson-databind`) pinned to a fixed, non-vulnerable
version.

TICKET = CVE-2020-36518, KAFKA-13775
EXIT_CRITERIA = "When upstream bumps all `jackson` series to >= `2.13.3`"
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants