- Update to 3.0.1 (bsc#1232554, bsc#1232556, CVE-2024-49769, CVE-2024-49768):
    * Fix a bug that would lead to Waitress busy looping on select()
      on a half-open socket due to a race condition that existed when
      creating a new HTTPChannel. See
      https://github.com/Pylons/waitress/pull/435,
      https://github.com/Pylons/waitress/issues/418 and
      https://github.com/Pylons/waitress/security/advisories/GHSA-3f84-rpwh-47g6
    * No longer strip the header values before passing them to the
      WSGI environ. See https://github.com/Pylons/waitress/pull/434
      and https://github.com/Pylons/waitress/issues/432
    * Fix a race condition in Waitress when
      `channel_request_lookahead` is enabled that could lead to HTTP
      request smuggling.
    * See https://github.com/Pylons/waitress/security/advisories/GHSA-9298-4cf8-g4wj

• Files Changed
• Browse Source

- update to 3.0.0:
  * Fixed testing of vendored asyncore code to not rely on
    particular naming for errno's.
  * HTTP Request methods and versions are now validated to meet
    the HTTP standards thereby dropping invalid requests on the floor.
  * No longer close the connection when sending a HEAD request
    response.
  * Always attempt to send the Connection: close response header
    when we are going to close the connection to let the remote
    know in more instances.
  * Document that trusted_proxy may be set to a wildcard value to
    trust all proxies.
  * clear_untrusted_proxy_headers is set to True by default.

    https://github.com/Pylons/waitress/security/advisories/GHSA-4f7p-27jc-3c36
  * Waitress did not properly validate that the HTTP headers it received
    were properly formed, thereby potentially allowing a front-end server
    to treat a request different from Waitress. This could lead to HTTP
  * Waitress won’t accidentally throw away part of the path if it
- Initial package (0.8.3)

• Files Changed
• Browse Source

• Files Changed
• Browse Source

Forwarded request #1100756 from bmwiedemann

Drop sphinx doctrees for reproducible builds

• Files Changed
• Browse Source

• Files Changed
• Browse Source

- Use sphinx-build and do not depend on removed build_sphinx
  in Sphinx 7.0 (boo#1211051).

- add sle15_python_module_pythons (jsc#PED-68)

• Files Changed
• Browse Source

- update to version 2.1.2 (bsc#1200126, CVE-2022-31015):

• Files Changed
• Browse Source

• Files Changed
• Browse Source

• Files Changed
• Browse Source

- update to 2.1.1 (bsc#1197255, CVE-2022-24761):
  * Waitress now validates that chunked encoding extensions are valid, and don’t
    contain invalid characters that are not allowed. They are still skipped/not
    processed, but if they contain invalid data we no longer continue in and return
    a 400 Bad Request. This stops potential HTTP desync/HTTP request smuggling.
    Thanks to Zhang Zeyu for reporting this issue. See
    https://github.com/Pylons/waitress/security/advisories/GHSA-4f7p-27jc-3c36
  * Waitress now validates that the chunk length is only valid hex digits when
    parsing chunked encoding, and values such as 0x01 and +01 are no longer
    supported. This stops potential HTTP desync/HTTP request smuggling. Thanks
    to Zhang Zeyu for reporting this issue. See
    https://github.com/Pylons/waitress/security/advisories/GHSA-4f7p-27jc-3c36
  * Waitress now validates that the Content-Length sent by a remote contains only
    digits in accordance with RFC7230 and will return a 400 Bad Request when the
    Content-Length header contains invalid data, such as +10 which would
    previously get parsed as 10 and accepted. This stops potential HTTP
    desync/HTTP request smuggling Thanks to Zhang Zeyu for reporting this issue.
    See
    https://github.com/Pylons/waitress/security/advisories/GHSA-4f7p-27jc-3c36

• Files Changed
• Browse Source

• Files Changed
• Browse Source

• Files Changed
• Browse Source

• Files Changed
• Browse Source

• Files Changed
• Browse Source

• Files Changed
• Browse Source

• Files Changed
• Browse Source

- update to 1.4.0:
  - Waitress used to slam the door shut on HTTP pipelined requests without
  setting the ``Connection: close`` header as appropriate in the response. This
  is of course not very friendly. Waitress now explicitly sets the header when
  responding with an internally generated error such as 400 Bad Request or 500
  Internal Server Error to notify the remote client that it will be closing the
  connection after the response is sent.
  - Waitress no longer allows any spaces to exist between the header field-name
  and the colon. While waitress did not strip the space and thereby was not
  vulnerable to any potential header field-name confusion, it should have sent
  back a 400 Bad Request. See https://github.com/Pylons/waitress/issues/273
  - CRLR handling Security fixes

• Files Changed
• Browse Source

• Files Changed
• Browse Source

• Files Changed
• Browse Source

• Files Changed
• Browse Source