Bump waitress from 1.3.0 to 1.4.1 in /src/app
Created by: dependabot[bot]
Bumps waitress from 1.3.0 to 1.4.1.
Changelog
Sourced from waitress's changelog.
1.4.1 (2019-12-24)
Security Fixes
- 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 request smuggling/splitting. Please see the security advisory for more information: https://github.com/Pylons/waitress/security/advisories/GHSA-m5ff-3wj3-8ph4 1.4.0 (2019-12-20) ------------------ Bugfixes ~~~~~~~~ - 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 [Pylons/waitress#273](https://github-redirect.dependabot.com/Pylons/waitress/issues/273) Security Fixes
... (truncated)
Waitress implemented a "MAY" part of the RFC7230 (https://tools.ietf.org/html/rfc7230#section-3.5) which states:
Although the line terminator for the start-line and header fields is the sequence CRLF, a recipient MAY recognize a single LF as a line terminator and ignore any preceding CR.
Unfortunately if a front-end server does not parse header fields with an LF the same way as it does those with a CRLF it can lead to the front-end and the back-end server parsing the same HTTP message in two different ways. This can lead to a potential for HTTP request smuggling/splitting whereby Waitress may see two requests while the front-end server only sees a single HTTP message.
For more information I can highly recommend the blog post by ZeddYu Lu
Commits
-
cd83598
Prep v1.4.1 -
11d9e13
Merge pull request from GHSA-m5ff-3wj3-8ph4 -
a046a76
Add links to advisories for previous security issues -
3c58e39
Bump version number -
de3324d
Add documentation for security issue -
3bcd690
Define VCHAR/OBS_TEXT once -
2e46f24
Validate HTTP header-field more completely -
2a11d68
Add file with RFC7230 definitions/ABNF -> regex -
f11093a
Merge pull request from GHSA-g2xc-35jw-c63p -
e586be8
Version 1.4.0 - Additional commits viewable in 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 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 ignore this [patch|minor|major] version
will close this PR and stop Dependabot creating any more for this minor/major 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) -
@dependabot use these labels
will set the current labels as the default for future PRs for this repo and language -
@dependabot use these reviewers
will set the current reviewers as the default for future PRs for this repo and language -
@dependabot use these assignees
will set the current assignees as the default for future PRs for this repo and language -
@dependabot use this milestone
will set the current milestone as the default for future PRs for this repo and language
You can disable automated security fix PRs for this repo from the Security Alerts page.