Retiring Bugdar

Bugdar 1.0 was released more than 20 years ago, and today I am officially announcing its retirement.

At its peak in the mid-2010s, Bugdar had a few thousand installs. But today I think the sole remaining instance is here on Blue Static. It has been well over a decade since any major change to the product has occurred. As I’ve written about previously, my available free time has shrunk and my interests have shifted. The prospect of improving Bugdar, a PHP4/5-era codebase clocking in at roughly 28,000 lines without a single unit test, is both daunting and unexciting.

What held back this retirement is a palatable alternative issue tracker for the projects I continue to maintain. With the arrival of Codeberg, a nonprofit committed to open source, there is now a platform on which I want to host Blue Static open source projects. Canonical git repositories will always exist on src.bluestatic.org, but issue tracking and collaboration will move to Codeberg.

As of today, Bugdar on Blue Static no longer accepts registrations. (The number of spam registrations that even get past reCAPTCHA was a strong motivating factor for this change.) I will be archiving the bug database as static HTML and moving any relevant open issues to the new tracker.

So, cheers to Bugdar! First commit in CVS 2003, migrated to SVN in 2004, and finally to git in 2008.

Mailpopbox v3 Released

Mailpopbox has been serving me well for nearly six years, providing me with disposable but traceable email addresses to give to businesses and mailing lists. The core workflow is that mailpopbox accepts email over SMTP and makes the resulting messages available via POP3.

For years, Gmail has had the ability to fetch from remote POP3 accounts. However, in October 2025, Google announced the deprecation of this feature. Removing this feature effectively breaks the workflow described above, and so a solution was needed before the January 2026 removal.

One option I considered was to add forwarding to mailpopbox, where the SMTP server would simply send the message on to the actual destination mailbox. But forwarding introduces other complexity, particularly around ARC and DMARC signing.

Instead, I opted to reimplement the Gmail POP3 fetch feature. This new standalone program, called mailpopbox-router connects to a POP3 server and moves the messages into Gmail using the Gmail API. One major advantage of this new program is the POP3 poll interval is directly controllable, whereas the built-in Gmail feature used an indeterminate (and, in my experience, long) polling interval.

The mailpopbox-router is part of the mailpopbox distribution as of v3, which is released today. Check out the installation guide for details.

Currently only POP3→Gmail is supported. But in the future, support for other source and destination types could be added (e.g. IMAP→IMAP). For now, this solves the acute problem of Google sunsetting another useful thing.

PHP File Uploads, FPM, Systemd, and SELinux

Last year I migrated this (and other sites) off a DreamHost VPS, which is a managed VPS product that does not offer much control over server configuration, to an unmanaged VPS at Vultr running Rocky Linux.

The server runs nginx and PHP using the FastCGI Process Manager. Rocky Linux, being a RedHat/CentOS-based distribution, also runs with SELinux enabled. SELinux greatly improves the security architecture of the system, but it does sometimes create obscure problems that take some time to debug. This post will discuss one such problems.

The issue was that PHP file uploads, such as in the bug tracker, were failing to upload, but there were no obvious error messages in the PHP error log.

When an <input type="file"> is used to submit a HTTP POST request, PHP reads the uploaded stream into a temporary file, and it stores the name of the temporary file in $_FILES['userfile']['tmp_name']. Unless the upload_tmp_dir php.ini variable is specified, the files will be put into the default temporary directory, which in this case was /tmp.

In addition, the systemd unit file for the php-fpm service specifies PrivateTmp=true. This option “sets up a new file system namespace for the executed processes and mounts private /tmp/ and /var/tmp/ directories inside it that are not shared by processes outside of the namespace”. In practice, that means that php-fpm runs with /tmp mounted from something like /tmp/systemd-private-026f628ae5ca469eb0213f719ca482-php-fpm.service-blDUvc outside of the namespace.

The issue is that php-fpm does not have permission to write this location because of SELinux. To fix this, I needed to adjust the system SELinux policy to permit php-fpm to write to that location. To do this, I issued the following command:

sudo semanage fcontext -a '(/var)?/tmp/systemd-private-(.+)-php-fpm\.service-(.*)/tmp(/.*)?' -t httpd_tmp_t

… which specifies a regular expression to the PrivateTmp path to be treated as the httpd_tmp_t SELinux label. That grants php-fpm the authority to write files to that directory, which is mounted at /tmp for the process.

After adjusting the policy, PHP file uploads worked like normal. The main confusing bit was that there were no error messages printed to SELinux log nor the PHP log.

MacGDBp 2.1.2 Released

MacGDBp 2.1.2 is now released containing one bug fix.

You can download MacGDBp 2.1.2 from the product page.

MacGDBp 2.1.1 Released

MacGDBp 2.1.1 is now released. The significant change is that the release is now code-signed and notarized by Apple.

You can download MacGDBp 2.1.1 from the product page.