To troubleshoot, I comment out the apt-get -y upgrade stuff and rebuild. That should yield the same result as prior to the change right? Well, no it didn't. At this point I'm lost so I begin removing all traces of previous images, re-pulling and re-building things. Still got 404s for my beloved guestbook which I think goes without saying, is completely unacceptable! Then I thought about this line in my Dockerfile:

RUN cpanm RJBS/Getopt-Long-Descriptive-0.105.tar.gz

Why run that instead of cpanm Getopt::Long::Descriptive? You see, this module isn't one that I'm using in my scripts but rather it's a dependency; a module I'm using is using this module. One day (prior to this) my Docker container refused to build and I narrowed the problem down to v0.106 of Getopt::Long::Descriptive building and, as it's not a module I'm much concerned with (I just need it so the module I do need will build) I enter the command as you see above to force installation of the prior version that I know will build just fine. So I start by checking out the changelogs for my modules that I'm using in my scripts. Thankfully it didn't take me long to see this in the changelog for Mojolicious (first module I checked 🙃):

9.11 2021-03-20 – This release contains fixes for security issues, everybody should upgrade! – Disabled format detection by default to fix vulnerabilities in many Mojolicious applications. That means some of your routes that previously matched “/foo” and “/foo.json”, will only match “/foo” after upgrading. From now on you will have to explicitly declare the formats your routes are allowed to handle. # /foo # /foo.html # /foo.json $r->get('/foo')–>to('bar#yada'); becomes $r->get('/foo' => [format => ['html', 'json']])–>to('bar#yada', format => undef); And if you are certain that your application is not vulnerable, you also have the option to re-enable format detection for a route and all its nested routes. Due to the high risk of vulnerabilities, this feature is going to be removed again in a future release however. my $active = $r->any([format => 1]); $active->get('/foo')–>to('Test#first'); $active->put('/bar')–>to('Test#second'); ...

Ahh that's right... I'm doing this:

plugin 'Config';

# CGI scripts
plugin CGI => ['/cgi-bin/guest'  => './cgi-bin/guest_mm.cgi'];
plugin CGI => ['/cgi-bin/whoami' => './cgi-bin/whoami.cgi'  ];

The .cgi file extension wasn't technically necessary but I want that to still work because:

1. I already have hyperlinks all over the place that use the extension
2. It's a CGI script and I want it to “look” like that... Petty I know

So here's my v9.11+ compliant way of using the extension:

plugin CGI => ['/cgi-bin/guest.cgi'  => './cgi-bin/guest_mm.cgi'];
plugin CGI => ['/cgi-bin/whoami.cgi' => './cgi-bin/whoami.cgi'  ];

Excellent, we're back in business! Fighting issues like this can sometimes feel like a “waste” of an afternoon because at the end of the day... My site hasn't really changed. I gained no new fun buttons or GIFs but I can sleep easy tonight knowing that my site is just a bit more “hardened” against script kiddies who never cease to make our lives just a little bit more complicated. Let's that tag this puppy, push it to my cloud provider and call it a day:

# After we've run: docker build -t www-swagg .
docker tag www-swagg gcr.io/www-swagg/www-swagg
docker push gcr.io/www-swagg/www-swagg
# Bunch of output follows...

And now we're safe. Until tomorrow when the next round of vulnerabilities gets discovered anyways 🤦‍♂️

Until next time bug,

Dan B

#docker #perl #mojolicious

• Homepage
• Code
• Mail
• Social
• Chat