Werkzeug 0.15.5 Released

written by David Lord on 2019-07-17 in Releases , Security

Werkzeug 0.15.5 has been released, containing bug and security fixes. The changelog lists the changes in detail, which include:

  • SharedDataMiddleware safely handles drive names in paths on Windows.
  • The reloader no longer causes an Exec format error in many common situations.
  • The reloader works around an issue when using the pydev debugger.

Security fix for SharedDataMiddleware on Windows

Prior to 0.15.5, it was possible for a third party to potentially access arbitrary files when the application used SharedDataMiddleware on Windows.

Due to the way Python's os.path.join() function works on Windows, a path segment with a drive name will change the drive of the final path. This was previously addressed in the safe_join() function in Werkzeug 0.12.2, but SharedDataMiddleware used a separate implementation and so was not secured by the previous fix.

SharedDataMiddlware now uses safe_join() when fetching requested files. Projects using SharedDataMiddleware on Windows should update as soon as possible to receive the fix.

Thank you to Emre Övünç and Olivier Dony for responsibly reporting the issue. If you think you have discovered a security issue in Werkzeug or another of the Pallets projects, please email security@palletsprojects.com with details.

Install or Upgrade

Install from PyPI with pip:

pip install -U Werkzeug

Flask 1.1 Released

written by David Lord on 2019-07-04 in Releases

The Pallets team is pleased to release Flask 1.1. The latest version is 1.1.1. Version 1.0.4 was also released.

  • Drop support for Python 3.4.
  • Bump minimum Werkzeug version to 0.15.
  • The way error handlers for InternalServerError and 500 work has been made more consistent. See below for more information.
  • app.logger once again takes the same name as app.name, reverting 1.0.x's behavior of hard-coding "flask.app". See below for more information.
  • jsonify supports Python's dataclasses.
  • Returning a dict from a view function will produce a JSON response. This makes it even easier to get started building an API.
  • A clearer error message is shown when a view returns an unsupported type.
  • URL routing is performed after the request context is pushed. This allows custom URL converters to access current_app and request. This makes it possible to implement converters such as one that queries the database for a model based on the ID in the URL.
  • CLI commands can be registered with blueprints using the new bp.cli attribute. These will be available as nested commands, for example flask user create.

Read the changelog for the full list of changes. Be sure to check the notes for the 1.0.x versions as well.

Change to Error Handling

Prior to 1.0, unhandled errors caused a generic InternalServerError to be returned, but only the handler for 500 was looked up for that, and the original error was passed to it. 1.0 made 500 an alias for InternalServerError, but these inconsistencies caused confusion over what errors were passed to what handlers.

As of 1.1, an error handler registered for InternalServerError or 500 means the same thing in all cases. It will always be passed an instance of InternalServerError, even if it was caused by an unhandled error of another type. The original error is available as e.original_exception.

If your project uses a 500 error handler that expects any exception to be passed to it, it should use e.original_exception instead of e.

Change to Logging

In 1.0, Flask's logging setup was greatly simplified. Part of that was hard-coding the name "flask.app" for the logger. However, that made it less clear whether Flask or the app was doing the logging, and made it impossible to distinguish between multiple apps in logs.

As of 1.1, app.logger again takes the same name as app.name. Flask will warn you if it detects logging configuration for "flask" or "flask.app" so you can rename that configuration appropriately.

For example, if your project is named example.py and you initialize your Flask app as Flask(__name__), then the logger will be named "example".

Install or Upgrade

Install from PyPI with pip:

pip install -U Flask

Pallets now accepts donations through the PSF in order to support our efforts to maintain the projects and grow the community. We greatly appreciate any support you can provide. Click here to donate.

Werkzeug 0.15.3 Released

written by David Lord on 2019-05-14 in Releases , Security

Werkzeug 0.15.3 has been released, followed closely by 0.15.4. Both fix bugs and compatibility issues. The changelog lists the changes in detail, which include:

  • The debugger pin is unique per Docker container.
  • Fix issues with the arguments to the Unauthorized HTTP exception.
  • Fix ProfilerMiddleware filenames, and get LintMiddleware working on Python 3.
  • Bytes passed to URLs will be correctly decoded rather than having a b prefix.

Debugger Pin Security

A minor security issue was addressed in this release. The debugger generates a unique pin per host to prevent unauthorized code execution. However, in Docker this pin would be identical across all containers. This release ensures each container uses a unique pin.

Thank you to Nikita Tikhomirov for responsibly reporting the issue. If you think you have discovered a security issue in Werkzeug or another of the Pallets projects, please email security@palletsprojects.com with details.

Install or Upgrade

Install from PyPI with pip:

pip install -U Werkzeug

Flask-SQLAlchemy 2.4.0 Released

written by Randy Syring on 2019-04-24 in Releases

Flask-SQLAlchemy 2.4.0. has been released. The changelog lists the changes in detail, which include:

  • Make SQLAlchemy engine configuration more flexible
  • Address SQLAlchemy 1.3 deprecations

Deprecation Warnings

New deprecation warnings have been added for configuration and __init__ params that are no longer needed due to the engine configuration now being more customizable. Those options will be removed in release 3.0.

Install or Upgrade

Install from PyPI with pip:

pip install -U Flask-SQLAlchemy

Jinja 2.10.1 Security Release

written by David Lord on 2019-04-06 in Releases , Security

Jinja 2.10.1 has been released and includes a security-related fix. If you are using the Jinja sandboxed environment you are encouraged to upgrade.

MITRE has assigned CVE-2019-10906 to this issue.

Thank you to Brian Welch for responsibly reporting the issue, and to Armin Ronacher for writing the fix.

The sandbox is used to restrict what code can be evaluated when rendering untrusted, user-provided templates. Due to the way string formatting works in Python, the str.format_map method could be used to escape the sandbox.

This issue was previously addressed for the str.format method in Jinja 2.8.1, which discusses the issue in detail. However, the less-common str.format_map method was overlooked. This release applies the same sandboxing to both methods.

If you cannot upgrade Jinja, you can override the is_safe_attribute method on the sandbox and explicitly disallow the format_map method on string objects.

Reporting Security Issues

If you think you have discovered a security issue in Jinja or another of the Pallets projects, please email security@palletsprojects.com with details.

Werkzeug 0.15.2 Released

written by David Lord on 2019-04-02 in Releases

Werkzeug 0.15.2 has been released. The changelog lists the changes in detail, which include:

  • Fix an issue where code generation would cause coverage to fail.
  • Fixed some issues with the new test client redirect code. If no cookies are stored, the cookie header is removed. Changes to the environ by the app don't affect the client.
  • The "werkzeug" logger doesn't log messages twice if user code has already configured logging.

Install or Upgrade

Install from PyPI with pip:

pip install -U Werkzeug

Werkzeug 0.15.1 Released

written by David Lord on 2019-03-21 in Releases

Werkzeug 0.15.1 has been released. It fixes a bug in the argument order for the Unauthorzed HTTP exception. description is now the first argument again.

Install or Upgrade

Install from PyPI with pip:

pip install -U Werkzeug

Werkzeug 0.15.0 Released

written by David Lord on 2019-03-19 in Releases

The Pallets team is pleased to release Werkzeug 0.15.0. This represents over a year of work from the community and maintainers, and as such there is an unusually long list of changes. Some of the notable ones are listed below, but there are many more throughout the framework. Read the full changelog to understand what changes may affect your code when upgrading.

  • Building URLs is ~7x faster.
  • Redirects now use HTTP code 308 by default. This preserves the method and form data.
  • int and float URL converters can handle negative numbers.
  • The debugger saw a number of improvements. Python 3's chained exceptions are correctly displayed and logged. Frames of user code are highlighted to make it easier to read tracebacks.
  • The reloader is much better at detecting how to re-run itself. It handles python -m as well as non-Python executable scripts.
  • The test client takes a json parameter, and the response class has a get_json method. This makes testing JSON APIs much more straightforward.
  • URLs with Unicode or percent-escapes are handled better. Quoting when converting between URIs and IRIs is more consistent, and the unquoted URL is logged by the dev server rather than showing percent escapes.
  • Deprecation warnings have been added throughout the code in preparation for version 1.0.
  • Werkzeug now uses pre-commit, black, reorder-python-imports, and flake8 to provide consistent code formatting. The code also moved to a src directory layout.
  • And much more!

werkzeug.contrib has been deprecated

The code under the werkzeug.contrib package has been deprecated. In version 1.0, code will either be moved into werkzeug core, or will be removed completely. Contrib started as a place to put code that wasn't clear where it belonged. In the 12 years since Werkzeug started, the packaging ecosystem and Werkzeug's codebase have evolved. The contrib code has not been widely maintained, often having better implementations elsewhere or no longer being required.

  • ProxyFix, LintMiddleware, and ProfilerMiddleware have moved into werkzeug.middleware.
  • securecookie and sessions have been extracted to the pallets/secure-cookie repository.
  • cache has been extracted to the pallets/cachelib repository.
  • Everything else is deprecated.

Deprecation Warnings

Besides contrib, many other parts of Werkzeug have been marked, either explicitly or implicitly, as deprecated, for many years. This release ensures that every occurrence issues a clear deprecation warning that mentions when the code will be removed. Currently, everything marked deprecated is slated to be removed in version 1.0.

  • Unused compatibility imports for code that was moved to another module within Werkzeug. This code is still available, but should be imported from the correct location.
  • Middleware in werkzeug.wsgi has moved to werkzeug.middleware.
  • The werkzeug.wrappers module was converted to a package of more specific modules. Imports for classes that were publicly documented in the previous version will work without change.

Install or Upgrade

Install from PyPI with pip:

pip install -U Werkzeug

The Pallets organization has joined the Python Software Foundation. We now accept donations through the PSF in order to support our efforts to maintain the projects and grow the community. Click here to donate.

MarkupSafe 1.1.1 Released

written by David Lord on 2019-02-23 in Releases

This is a bugfix release. Changelog

  • If an __html__ method raised an exception, Python would segfault when using MarkupSafe's C speedups. Now the exception will propagate correctly rather than crashing.

Install or Upgrade

Install from PyPI with pip:

pip install -U MarkupSafe

Take the Pallets / Flask Community Survey

written by David Lord on 2019-01-29 in Meta

One of my goals as a Pallets maintainer is to build the community around our projects. The Pallets projects (Flask, Jinja, Click, etc.) are downloaded millions of times each month, but it's hard to get a clear picture of what our users do and want with downloads stats only. We'd like to learn about you and your projects. Knowing more about our community will help us decide what to focus on to grow the Pallets projects.

Click here to take our Community Survey.

Please share the link with friends, coworkers, and the internet! We're looking forward to seeing everyone's responses! You can follow https://twitter.com/PalletsTeam or this blog to get updates about Pallets, including the survey results.