Dancer2 2.2.0 released; security updates PLEASE READ

We have just released Dancer2 2.2.0. It is a maintenance release containing a number of bug fixes, several important security updates, and one breaking change (see below).

First and foremost, please read the following security announcements; if you are running affected versions of Dancer2, you should plan to update immediately:

A recap of all changes follows.

Security fixes

  • Path traversal in static file serving. Dancer2::Handler::File could serve files from outside public_dir. (GHSA-6xw8-v24c-m783)
  • Hook exception handling. If an on_hook_exception handler halted, the route that the hook refused could still run. (GHSA-v527-r4px-7vx7)
  • Header injection. CR and LF are now stripped from response header names, as they already were from header values.
  • AutoPage no longer serves a layout as a page on case-insensitive filesystems.
  • Session IDs are now always generated with Crypt::URandom, and validate_id rejects invalid session IDs more strictly.

Breaking changes

  • The Data::Dumper serializer has been removed from core, along with the from_dumper and to_dumper keywords. If your app uses them, make sure to download Dancer2::Serializer::Dumper from CPAN.

Bug fixes

  • send_file now sends the correct error codes.
  • The path() and dirname() DSL keywords no longer drop their first argument.
  • Serializer::JSON handles UTF-8 correctly for readonly values and no longer recurses endlessly into blessed objects.
  • Serializer::Mutable ignores content type parameters such as charset when choosing a format.
  • Each response content assignment is now encoded, not just the first.
  • uri_for_route accepts a route parameter of 0 and gives a clearer error for an empty one.
  • Hooks are compiled only once, however many times to_app is called.
  • A NUL byte in a static file request no longer produces a warning on every request.
  • App root directory detection has been fixed.
  • Several dancer2 gen fixes:
    • -g and -r no longer die after writing the app.
    • The app directory is named after the dashed distribution name.
    • The pattern added to MANIFEST.SKIP is relative and matches correctly.

Documentation

  • The header precedence documented for Serializer::Mutable now matches what it actually does.
  • %D has been removed from the documented log_format characters, since it was never implemented.

Thanks

Thanks to everyone who contributed to this release, especially:

  • Anton Lundin, for fixing the error codes in send_file
  • Mike Weisenborn, for the path()/dirname() fix
  • Curtis "Ovid" Poe, for surfacing many of these issues with PAAD
  • David Precious (bigpresh) and Russell Jenkins (veryrusty) for running with these items and seeing them through to completion

Cheers,

Jason/CromeDome

3 Comments

Hey Jason,

thanks for posting this release note.

I hope it's ok to shamelessly use the opportunity for a question: Being the maintainer of a small Dancer2::Plugin module, would you recommend to pin the latest Dancer2 core version as a requirement? Or is there no need to do this?

Kind regards,
Stefan

Stefan, doing that as a rigid rule is actively unfriendly.

It’s quite possible for a given Dancer application to run an older version of Dancer without being affected by any of these security issues. If your module starts requiring a newer version of Dancer than strictly necessary, then such an application cannot be upgraded to a newer version of your module without at least checking whether Dancer can safely also be upgraded – which of course it usually will be, it just cannot be assumed blindly.

And if that does turn out not to be safe, then upgrading your module will require additional work making code changes that have nothing to do with your module and would not otherwise be necessary. So in practice the question will then be whether it’s worth upgrading your module – and if so, whether that work can be done immediately or will have to wait. For no benefit whatsoever.

So the version of Dancer you require should be based only on the requirements of your own code. If your code interacts with any of the parts of Dancer that were previously insecure, especially if it is therefore also insecure, then by all means require a newer Dancer version. But don’t require a newer version just because a newer version exists.

Thank you for the explanations - I assumed that to be not so much of a good idea, but got a bit insecure. It was not my intention to be unfriendly.

Leave a comment

About Jason A. Crome

user-pic Perl/Dancer hacker, pilot, hockey wannabe.