Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

vendor: golang.org/x/sys v0.18.0, golang.org/x/term v0.18.0, golang.org/x/crypto v0.21.0, golang.org/x/net v0.23.0 #4998

Merged
merged 4 commits into from
Apr 9, 2024

Commits on Apr 9, 2024

  1. vendor: golang.org/x/sys v0.18.0

    full diff: golang/sys@v0.16.0...v0.18.0
    
    Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
    thaJeztah committed Apr 9, 2024
    Configuration menu
    Copy the full SHA
    9a2133f View commit details
    Browse the repository at this point in the history
  2. vendor: golang.org/x/term v0.18.0

    no changes in vendored code
    
    full diff: golang/term@v0.15.0...v0.18.0
    
    Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
    thaJeztah committed Apr 9, 2024
    Configuration menu
    Copy the full SHA
    c7a50eb View commit details
    Browse the repository at this point in the history
  3. vendor: golang.org/x/net v0.22.0, golang.org/x/crypto v0.21.0

    full diffs changes relevant to vendored code:
    
    - golang/net@v0.19.0...v0.22.0
        - http2: remove suspicious uint32->v conversion in frame code
        - http2: send an error of FLOW_CONTROL_ERROR when exceed the maximum octets
    - golang/crypto@v0.17.0...v0.21.0
        - (no changes in vendored code)
    
    Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
    thaJeztah committed Apr 9, 2024
    Configuration menu
    Copy the full SHA
    4745b95 View commit details
    Browse the repository at this point in the history
  4. vendor: golang.org/x/net v0.23.0

    full diff: golang/net@v0.22.0...v0.23.0
    
    Includes a fix for CVE-2023-45288, which is also addressed in go1.22.2
    and go1.21.9;
    
    > http2: close connections when receiving too many headers
    >
    > Maintaining HPACK state requires that we parse and process
    > all HEADERS and CONTINUATION frames on a connection.
    > When a request's headers exceed MaxHeaderBytes, we don't
    > allocate memory to store the excess headers but we do
    > parse them. This permits an attacker to cause an HTTP/2
    > endpoint to read arbitrary amounts of data, all associated
    > with a request which is going to be rejected.
    >
    > Set a limit on the amount of excess header frames we
    > will process before closing a connection.
    >
    > Thanks to Bartek Nowotarski for reporting this issue.
    
    Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
    thaJeztah committed Apr 9, 2024
    Configuration menu
    Copy the full SHA
    5fcbbde View commit details
    Browse the repository at this point in the history