Currently there are 30 entries in this BLOG.
The Hotfix release 2026-07-14c "Mort" is now available.
To find out what's new, see the Changelog. But in summary a security issue was fixed.
Note: Some plugins may need updates, as there is a side effect to this fix. (E.g. Bureaucracy Plugin #359, PR #360.) This also discussed in several threads in the DokuWiki User Forum,
See also:
The Hotfix release 2026-07-14b "Mort" is now available.
To find out what's new, see the Changelog. But in summary a security issue was fixed along with some other minor fixes.
See also:
The Hotfix release 2026-07-14a "Mort" is now available.
To find out what's new, see the Changelog. But in summary a few (long standing) security issues were fixed along with other fixes.
It's been a while but this is a welcome update (Changelog, Download). There are only some minor glitches so far.
conf/userstyle.css:/* Fixes for the charpicker Plugin */ /* See: https://github.com/turnermm/charpicker/issues/16 */ .tpl_sprintdoc #dokuwiki__content { overflow-y: visible; overflow-x: clip; } .page div.toolbar div.picker { z-index: 1; } /* End fixes. */
Two things I recommend after updating:
rm -rf data/cache/[0-9a-f]. A stale cache can cause very weird rendering issues.php bin/indexer.php -c as the same user the webserver is using. Add -d max_execution_time=1200 or similar if the time limit is too short.A new release of DokuWiki is making progress. Its release name will be Mort (which follows Librarian, released 2025.05.14).
The major new features are:
The minimum PHP version is now PHP 8.2, which corresponds to the oldest version still under some sort of support at this time.
On one of my wikis I have a complex page of about 575 KB source text size. After any modifications it runs into the default maximum execution time for PHP of 30s and only an error message is displayed.
As we can't make DokuWiki any faster, and the hardware needs to stay the same as well, the only alternative is to increase the time limit.
The PHP maximum execution time is set via the max_execution_time INI setting. It can also be adjusted at runtime using the set_time_limit() function.
Altering the value of max_execution_time works, but it affects more than just the DokuWiki instance. So this is not ideal.
The best solution is to use set_time_limit() during DokuWiki startup to set a higher time limit. This is actually fairly easy to accomplish: Code added in the file DOKU_BASE/conf/local.protected.php is executed early during DokuWiki startup. So creating this file if necessary and adding e.g.
set_time_limit(90);
will solve the problem.
The complete file would look like this (if no other code is needed at startup):
<?php set_time_limit(90); ?>
An additional advantage of using set_time_limit() instead of adjusting max_execution_time is that the file …/conf/local.protected.php would be copied along with the rest of the DokuWiki instance to backup sites, thus ensuring that the adjusted timeout is applied there as well without needing to fiddle with global PHP settings on those sites.
Note: The new time limit should be chosen large enough that it works for the DokuWiki instance as well as any backup/mirror sites. The backup/mirror sites might use different hardware, thus exhibiting different performance compared to the main site. The requirements of the slowest site should be used to determine an appropriate value.
Greylisting is an effective way to reduce the amount of SPAM sent by non-standard sources, such as scripts. I relies on the fact that a real SMTP sender will respond to a temporary rejection with a later retry.
Postgrey is service that implements greylisting. It is easily integrated into Postfix confgurations.
To this end Postgrey will build triples of
| CLIENT | The source IP of the sending server |
| SENDER | The sender's email address |
| RECIPIENT | The recipient's email address |
If a triple was not previously seen, the mail is temporarily rejected. When the sending server retries a delivery after a configurable minimum delay (default 300s) the mail is accepted and the triple is marked as a valid combination, so that the next email with the same triple will be accepted without any delays. After a certain time (default 35 days) unused triples will expire.
Postgrey allows for exceptions by specifying allowed sending servers and allowed recipients.
It does not allow exceptions for the sender's email address though. Some services use multiple sending servers, so the retry might come from a different server. This then does not match the previous triple and results in another temporary rejection. These cases can only be handled by defining exceptions for the sender's email address, which Postgrey does not implement. See Enhancement Request: Sender Whitelist (#56) which is unlikely to be implemented.
One solution would be to filter by sender address before passing the email to Postgrey.
A typical Postfix configuration using Postgrey will contain something like the following in master.cf:
smtp inet n - y - - smtpd
-o { smtpd_recipient_restrictions = permit_mynetworks permit_sasl_authenticated reject_unauth_destination check_policy_service inet:127.0.0.1:10023 }
...
Here the check_policy_service directive passes the message to the Postgrey service listening on 127.0.0.1:10023, which then decides on temporary rejection or immediate acceptance.
Since the smtpd_recipient_restrictions options are evaluated in order until the first match is found, inserting a filter right before the check_policy_service directive will do the trick. This filter could look like this: check_sender_access hash:/etc/postfix/nogreylist-senders, which requires an access table similar to:
# The following sender email address patterns will be used to exclude # emails from these senders from being subjected to greylisting by # postgrey. # # Beware that email sender addresses are easily forged. So use this # judiciously. # # NOTE 1: This affects all recipient addresses on this server, so # don't be too permissive. # NOTE 2: Please only use the ACCEPT ACTION OK because any other action # is not appropriate semantically in this file. # https://www.postfix.org/access.5.html#accept_actions # REJECT actions are technically possible but their use should # be separated from the goal of bypassing greylisting, thus # inappropriate here. # # For syntax see: # https://www.postfix.org/access.5.html # # Always run `postmap /etc/postfix/nogreylist-senders` after making changes. # Allow emails from senders in the domain example.com to bypass greylisting example.com OK # # EOF. #
Thus the entry in master.cf will now look like this:
smtp inet n - y - - smtpd
-o { smtpd_recipient_restrictions = permit_mynetworks permit_sasl_authenticated reject_unauth_destination check_sender_access hash:/etc/postfix/nogreylist-senders check_policy_service inet:127.0.0.1:10023 }
...
This method has been successfully tested on OpenBSD 7.9 running Postfix 3.11.3 and Postgrey 1.37.
Not surprising for those who follow the OpenBSD mailing lists, and somewhat late but still within the normal release schedule, on 2026.05.19 OpenBSD 7.9 was released. This is the 60th release of OpenBSD.
As usual the Upgrade instructions work fine and the first impression is good.
Apple has released an urgent security update for iOS 26.3.1 and other OSes. See About the security content of Background Security Improvements for iOS 26.3.1, iPadOS 26.3.1, macOS 26.3.1, and macOS 26.3.2.
Unfortunately it does not show up in Settings → General → Software Update! And I saw no notification about it either.
Users apparently need to find the Settings → Privacy & Security → Background Security Improvements setting and manually install the update (requiring a reboot in this case). And note that the Automatically Install setting is turned ON on my device. Apparently that doesn't do anything though. (The update was released on March 17, 2026 and I checked on March 20. So for 3 days the automatic update did not happen.)
So I predict that only a few users will actually find and install the important security fix.
Nice going Apple!
Update: On one Apple iPad running iPadOS 26.3.1 the security update appears to have installed automatically. So that seems to sometimes work? Still, from a user interface perspective it makes no sense to split of the UI for installing background security updates from the normal Software Update UI.
Update #2: On March 24, 2026, only a week later, iOS/iPadOS/macOS 26.4 where released. Thus for this specific case the issue is effectively moot. However the point of the security update was to get a fix for an issue out to the devices as soon as possible. And hiding the mechanism for installing such fixes is counterproductive.
On small systems, or on VMs with small virtual boot disks, the automatic partitioning will sometimes lead to a /usr partition that is too limited in size. During normal operations this will probably not hurt anything but sysupgrade(8) may complain that there is not enough free space on /usr.