Back in the days when spam was not a thing, and the internet was simpler, if you wanted to give users an email address under your domain, you’d just add a forward to your mail server configuration. That took care of the receiving side, and sending could usually be done with whatever mail server people already had. Nobody bothered checking the envelope sender or From header anyway, and mail servers would happily accept mail from everyone and everywhere as long as it seemed that it had ended up in the right place. And it was good. And then along came spam.

SPF and DKIM? You need to run your own SMTP.

Now, of course, this is not a theoretical example. MacPorts has always provided its project members with an email alias under @macports.org. However, to fight spam, smart people came up with a multitude of ways to figure out whether mail received by a mail server was actually sent by who the envelope claimed to have sent it. There are currently two major mechanisms for this purpose: Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM).

SPF allows administrators to publish a list of servers that are permitted to send mail on behalf of a specific domain. Of course, since MacPorts did not actually provide an SMTP server and expected our developers to use their own ones, we had no way of gathering such a list and would thus allow the entire internet to send mail on behalf of @macports.org, something more and more mail providers are nowadays treating as an indicator for spam.

DKIM, on the other hand, adds a cryptographic signature to certain selected fields of an email when it passes through the outgoing server, to be verified against a public key published in DNS on the receiving end. But again, since there was no single central SMTP serving @macports.org, we could not ensure that all mails had such a signature, and thus could not enable DKIM – which providers are also using as an indication for spam.

We did know for a while that we would eventually have to setup email submission, but have been delaying the actual setup, since we needed a way to configure the passwords that should be used for SMTP. Since MacPorts’ migration to GitHub in October 2016, we only use GitHub’s OAuth2 for authentication. And while mail clients are slowly implementing support for that in SMTP and IMAP, it is not yet widespread enough to be usable in our case.

So, my todo list came down to

• Write a web application that uses GitHub OAuth2 to authenticate users
• Allow setting the SMTP password in a database from that web application. I figured a database would be a good idea, since it’s the most convenient resource to access from different unix users, unlike files and/or sockets where I would have had to configure groups.
• Configure SMTP authentication against the passwords in the database into Postfix.

Sounds simple enough. Boy, was I wrong…

From Friday, October 13th to Sunday, October 15th 2017 I had the opportunity to attend the Google Summer of Code Mentor Summit in Sunnyvale, CA. This is a summary of my experiences.

If you are not familiar with Google Summer of Code, it is a program where university students spend the summer working for an open source project. Google pays the students as a way to give back to open source, which is heavily used in their products. Students are mentored by experienced developers from the projects and Google invites two mentors per project into the US in autumn each year for an unconference-style summit.

Together with Mojca Miklavec I mentored Zero King, who did a great job at implementing better usability for GitHub pull requests for MacPorts by setting up Travis CI and a PR helper bot. Our original plan was to attend the Mentor Summit with 2015 student and this year organization administrator Jackson Isaac, but unfortunately his visa to the US was denied and Mojca stepped in instead.

Since MacPorts’ move off Apple’s MacOSForge in October, we have been running MacPorts’ Trac installation on our own infrastructure. We used to rely on server and admin time generously donated by Apple. Now that we no longer enjoy this luxury, we are on our own when it comes to keeping our infrastructure running.

For a few months, we were bedeviled by high server load apparently caused by our Trac installation and had a hard time figuring out the cause. Our monitoring showed a large number of HTTP requests and Trac’s response time would regularly take a nose-dive as soon as the backup started.

After a few attempts of tuning various knobs without too much success, I finally decided to grab the Apache access logs and run awstats on them. Since we rotate our access logs biweekly I only had 10 days of February for analysis, but even those 10 days revealed some pretty interesting data.

Back in March 2015, I reported a security issue in Yubiserver, a small specialized HTTP server to verify HOTP/OATH tokens generated by Yubico’s Yubikeys. I’m publishing the details for reference.

I was looking for a new Yubikey validation server and, given its small size, decided to code review any candidates due to their small size. While looking at yubiserve, I found security issues in the code.

With the update to OS X El Capitan, Apple has rewritten Disk Utility. The pre-10.11 Disk Utility used to have an option to securely erase a disk – a feature I needed because I plan to throw a faulty disk away.

Why would you wipe an encrypted disk?

For an encrypted volume, wiping the header that contains the master encryption key should be enough to ensure that no data can be recovered. Conveniently, Apple does not provide an option to wipe the volume’s encryption header and documentation on Apple’s CoreStorage format it scarce, which means I don’t know where the header actually is. So a full wipe it is.

Luckily just because the GUI does not support the feature anymore does not mean that it cannot be done. The diskutil command line tool still has a secureErase option that supports overwriting entire volumes. Because I was doing this with CoreStorage volumes, I first had to delete that volume before secureErase would unmount the physical disk below:

:) clemens@cBookPro:~$ diskutil cs deleteVolume CD3D75E0-F317-42B6-B44F-FDCB1A9448CD
The Core Storage Logical Volume UUID is CD3D75E0-F317-42B6-B44F-FDCB1A9448CD
Started CoreStorage operation on disk7 cTM
Unmounting disk7
Removing Logical Volume from Logical Volume Group
Finished CoreStorage operation on disk7 cTM

Once the logical volume was gone, I was able to start the wipe with diskutil secureErase:

:) clemens@cBookPro:~$ diskutil secureErase
Usage:  diskutil secureErase [freespace] level MountPoint|DiskIdentifier|DeviceNode
Securely erases either a whole disk or a volume's freespace.
Level should be one of the following:
        0 - Single-pass zeros.
        1 - Single-pass random numbers.
        2 - US DoD 7-pass secure erase.
        3 - Gutmann algorithm 35-pass secure erase.
        4 - US DoE 3-pass secure erase.
Ownership of the affected disk is required.
Note: Level 2, 3, or 4 secure erases can take an extremely long time.
:( clemens@cBookPro:~$ diskutil secureErase 2 disk4
Started erase on disk4
Pass: 1
Pass: 2
Pass: 3
Pass: 4
[ - 0%..10%..20%..30%..40%..50%.......................... ] 52% 25:03:07

I did a little research that suggests that a single wipe is sufficient to prevent data recovery on modern disks, so the DoD 7-pass I used might seem like overdoing it, but since I’m throwing the disk out because it was causing write errors I am also using this as a last benchmark to see if it would trash the disk completely.