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:
- GHSA-6xw8-v24c-m783 (Severity: High; Versions affected: <= 2.1.0)
- GHSA-v527-r4px-7vx7 (Severity: Moderate; Versions affected: >= 2.0.0, <= 2.1.0)
A recap of all changes follows.
Security fixes
- Path traversal in static file serving.
Dancer2::Handler::Filecould serve files from outsidepublic_dir. (GHSA-6xw8-v24c-m783) - Hook exception handling. If an
on_hook_exceptionhandler 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, andvalidate_idrejects invalid session IDs more strictly.
Breaking changes
- The
Data::Dumperserializer has been removed from core, along with thefrom_dumperandto_dumperkeywords. If your app uses them, make sure to download Dancer2::Serializer::Dumper from CPAN.
Bug fixes
send_filenow sends the correct error codes.- The
path()anddirname()DSL keywords no longer drop their first argument. Serializer::JSONhandles UTF-8 correctly for readonly values and no longer recurses endlessly into blessed objects.Serializer::Mutableignores content type parameters such ascharsetwhen choosing a format.- Each response content assignment is now encoded, not just the first.
uri_for_routeaccepts a route parameter of0and gives a clearer error for an empty one.- Hooks are compiled only once, however many times
to_appis 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 genfixes:-gand-rno longer die after writing the app.- The app directory is named after the dashed distribution name.
- The pattern added to
MANIFEST.SKIPis relative and matches correctly.
Documentation
- The header precedence documented for
Serializer::Mutablenow matches what it actually does. %Dhas been removed from the documentedlog_formatcharacters, 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
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.