We are very pleased to announce the availability of Foswiki 2.1.8. This release contains 61 fixes relative to 2.1.7, including 9 critical security related fixes.

Most notable are:

• CVE-2023-33756: SpreadSheetPlugin's EVAL feature exposes information about paths and files on the server
• CVE-2023-24698: Local file inclusion vulnerability in viewfile

But also:

• directories in working directory are created as world writable 777 permissions
• possible XSS attack in attachment comments
• restricted allowed protocols to http and https, i.e. forbid file protocol for local file inclusion
• prevent symlink attacks by defaulting to a secure location for temporary files
• update to jquery-ui 1.13.2
• backport patch to earlier jQuery versons to fix a potential XSS vulnerability
• possible XSS vulnerability in topic title field

Tags: security

Introduction

No, it was much simpler than that but the nature of Docker images means its a little different.

Persistent Volumes

In order for a docker instance to host something like Foswiki it needs persistent volumes. That is a place to hold the changing content. In timelegge/docker-foswiki the provided docker compose files esentially put the entire Foswiki website on a persistent volume. The way Foswiki automatically inter-mingles some of the data and code (or more properly automatically generates content sections under data) makes it difficult to do anything else.

So, simply pulling the latest Docker image for timlegge/docker-foswiki means you get all the updated alpine linux packages but Foswiki remains at the same version.

Upgrading

1. Download the upgrade package
2. Copy it to your Docker Image's persistent volume
3. Unzip/tar over the existing Foswiki Installation
4. Save the updated LocalSite.cfg
5. Restart your Docker Container

Example Steps assuming your Docker Container can access the Internet

docker exec -it docker-foswiki /bin/bash
cd /var/www/foswiki
wget https://github.com/foswiki/distro/releases/download/FoswikiRelease02x01x07/Foswiki-upgrade-2.1.7.tgz 
tar --strip-components=1 -zxf Foswiki-upgrade-2.1.7.tgz 
cd tools
./configure --save
rm Foswiki-upgrade-2.1.7.tgz
exit

Then you simply need to restart your docker image to cache the updated Perl Code

Example Steps assuming your Docker Container cannot access the Internet

wget https://github.com/foswiki/distro/releases/download/FoswikiRelease02x01x07/Foswiki-upgrade-2.1.7.tgz
cp Foswiki-upgrade-2.1.7.tgz /var/lib/docker/volumes/foswiki_foswiki_www/_data
docker exec -it docker-foswiki /bin/bash
cd /var/www/foswiki
tar --strip-components=1 -zxf Foswiki-upgrade-2.1.7.tgz 
cd tools
./configure --save
rm Foswiki-upgrade-2.1.7.tgz
exit

Tags: docker, installation, migration, update

This release addresses significant security issues we discovered in all previous Foswiki releases.

This release comes with a total of 110 fixes and enhancements as well as 7 security fixes.

Tags: security

In the first instance I measured page download times using a simple technique:

/usr/bin/time --quiet -f "%e" wget -pq --header="accept-encoding: gzip" --no-check-certificate --delete-after https://localhost/foswiki

Tsend and Treturn are defined by the network properties,I will assume that they are constant across elements for a single measurement. Tget is a server property and will be relatively constant across elements (ignoring disk transfer time, which will depend of element size). Tprocess will be zero for the static elements.

Environment - Tinkerbell Apache CGI

Environment - Katacoda Apache CGI

Environment - Katacoda Apache Fast CGI

• The result that surprised me most is the the wait times in the retrieval of the static elements. It should be noted that many of these elemnts are retrieved in parallel, but only after the the html has been evaluated in the browser. So it seems one should expect at least 200-400 ms delay in the retrieval of a page for the static elements. Caching these elements in the browser will help improve the overall performance. But the first encounter is sensitive to this wait time.
• Use FastCGI. It will reduce the wait time for html generation. In the Katacoda Apache FCGI environment it takes 500 ms to start, which are a consistent overhead on each transaction if you use regular CGI.
• If you want to improve performance beyond what Fast CGI gives you, use a server with more generous specifications. More cpu and more memory make a difference.
• Pre-zipped elements provided with Foswiki may make a difference on slow networks, but they will have no effect on the wait time. And for most elements, the wait time is 99% of the total time to receive the element.
• Apache mod_deflate is unlikely to make any improvement in the performance of your Foswiki site. The time taken to compress and decompress is added to the time it takes to retrieve the element from disk. It may help on a slow network, but you should check if it is worth it.
• PageOptimizerPlugin. This plugin collects all static css and js in one css and one js file and caches the result. From the server side perspective there are now two files to serve instead of say 10. But since the the retrieval is parallel, you are still stuck with whatever wait time is associated with the two files. At least 200 ms. Sites like Pingdom and many others recommend reducing the number of static elements per page to retrieve, because the browser needs the css and js before it can render the page. So combining the elements together may improve the user experience.

Tags: development, installation, performance

This was another long journey of debugging all sorts of involved components - Foswiki authentication modules, XSendFileContrib, different browsers and web servers.

As PDF.js is so widely spread being shipped with browsers, we cannot wait for it to be fixed and all people to upgrade their browsers. So we have to come up with a solution that mitigates the bad situation in some way.

We will do so on the server side by disabling partial downloads for PDF files only. Note that this bug in PDF.js will only affect you when PDF files are particularly large and require authentication to be accessed.

A full example of an NGINX config will look something like this:

# no auth required for system assets such as css and js
location ~ ^/pub/(System|Applications)/ {
  root /path/to/foswiki;
  expires 12h;
  gzip_static on;
}

# require auth for any other static file
location /pub {
  rewrite ^/pub/(.*)$ /bin/xsendfile/$1;
}

# default internal location 
location /protected_files {
   internal;
   alias /path/to/foswiki/pub/;
}

# internal location for pdf but
# disable Accept-Ranges header as it breaks cookie authentication with pdf.js
location /protected_files/pdf {
   internal;
   alias /path/to/foswiki/pub/;
   max_ranges 0;
}

Foswiki can then be configured to serve respective filetypes from their internal web server location:

$Foswiki::cfg{XSendFileContrib}{Location}= "/protected_files";
$Foswiki::cfg{XSendFileContrib}{Locations}{pdf}= "/protected_files/pdf";

I leave it to you to provide a matching config example for Apache.

Tags: bugs, http, nginx, partial-downloads, pdf, performance, range-requests, security, web-server