Time for a new GPG key

Yubikey NEOAfter an unfortunate death of my Yubikey NEO and a huge mistake on backups, I’ve come to realize that it’s time for a new GPG key. My new one is already up on Keybase and there’s a plain text copy on my resume site.

Action required

If you’re using a key for me with a fingerprint of 6DC99178, that one is no longer valid. My new one is C1011FB1.

For the impatient, here’s the easiest way to retrieve my new key:

gpg2 --keyserver pgp.mit.edu --recv-key C1011FB1

Lessons learned

Always ensure that you have complete backups of all of your keys. I made a mistake and forgot to back up my original signing subkey before I moved that key to my Yubikey. When the NEO died, so did the last copy of the most important subkey. It goes without saying but I don’t plan on making that mistake again.

Always make a full backup of all keys and make a revocation certificate that also gets backed up. There’s a good guide on this topic if you’re new to the process.

Wait. A Yubikey stopped working?

This is the first Yubikey failure that I’ve ever experienced. I’ve had two regular Yubikeys that are still working but this is my first NEO.

I emailed Yubico support earlier today about the problem and received an email back within 10-15 minutes. They offered me a replacement NEO with free shipping. It’s still a bummer about the failure but at least they worked quickly to get me a free replacement.

Chrome 43 stuck in HiDPI mode

Google Chrome iconI ran some package updates last night and ended up with a new version of Google Chrome from the stable branch. After restarting Chrome, everything in the interface was huge. The icons in the bookmark bar, the text, the padding — all of it looked enormous.

After a little searching, I found a helpful line in the ArchLinux HiDPI documentation:

Full HiDPI support in Chrome is now available in the main branch google-chromeAUR as of version 43.0.2357.2-1 and works out of the box as tested with Gnome and Cinnamon.

It looks like there was a flag available for quite some time to test the feature but it disappeared sometime in March. I scoured my list of flags as well as my Chrome configuration directories and couldn’t find any trace of it.

Temporary Workaround

While I search for a fix, my current workaround is to manually edit the .desktop file that comes with the Chrome RPM. On my Fedora system, that file is /usr/share/applications/google-chrome.desktop. If you open that file, look for a line that starts with Exec:

Exec=/usr/bin/google-chrome-stable %U

Change that line so that it includes --force-device-scale-factor=1 to disable HiDPI support:

Exec=/usr/bin/google-chrome-stable --force-device-scale-factor=1 %U

Depending on your display manager, you might need to do something to refresh the .desktop files. If you’re using GNOME 3, just press Alt-F2, type r, and press enter. Your screen will flicker a lot and GNOME will restart in place. Try starting Chrome once more and you should be back to normal.

Still having problems?

If you don’t see a change after doing all of that, ensure that you fully exited Chrome. Depending on your configuration, Chrome might still be running in your taskbar even if you close all of the browser windows. If that’s the case, completely exit Chrome using the taskbar menu or pkill -f google-chrome. Start Chrome again and you should be all set.

cups.service start operation timed out in Fedora 22

Applications on my Fedora 22 system kept stalling when I attempted to print. My system journal was full of these log messages:

systemd[1]: cups.service start operation timed out. Terminating.
systemd[1]: Failed to start CUPS Scheduler.
systemd[1]: Unit cups.service entered failed state.
systemd[1]: cups.service failed.
audit[1]: <audit-1130> pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=cups comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=failed'

If I tried to run systemctl start cups, the command would hang for quite a while and then fail. I broke out strace and tried to figure out what was going wrong.

The strace output showed that cups was talking to my local DNS servers and was asking constantly for the IP address of my laptop’s hostname.

facepalm - cups fails without an entry in /etc/hosts

Oh, I felt pretty stupid at this point.

I added my laptop’s hostname onto the line starting with in my /etc/hosts and tried to start cups once more. It started up in less than a second and is now working well.

PulseAudio popping with multiple sounds in Fedora 22

PulseAudio popping in Fedora 22 with multiple soundsMy transition from Fedora 21 to 22 on the ThinkPad X1 Carbon was fairly uneventful even with over 2,400 packages involved in the upgrade. The only problem I dealt with on reboot was that my icons on the GNOME 3 desktop were way too large. That’s a pretty easy problem to fix.

However, something else cropped up after a while. I started listening to music in Chrome and a Pidgin notification sound came through. There was a quiet pop before the Pidgin sound and a loud pop on the end. Thunderbird’s notifications sounded the same. The pops at the end of the sound were sometimes very loud and hurt my ears.

I started running PulseAudio in debug mode within a terminal:

pulseaudio -k
pulseaudio --start

There were some messages about buffer underruns and latency issues but they were all very minimal. I loaded up pavucontrol and couldn’t find anything unusual when multiple sounds played. I gave pavumeter a try and found something very interesting.

When Chrome was playing audio, the meters in pavumeter were at 80-90%. That seems to make sense because I keep Chrome as one of the loudest applications on my laptop. My logic there is that I don’t want to get blasted by a notification tone that is drastically louder than my music.

However, if I received a Pidgin or Thunderbird notification while Chrome was playing music, the pavumeter showed the volume levels dropping to 30% or less. As soon as the sound was over, the meters snapped back to 80-90% and there was a big popping sound. I lowered Chrome’s volume so that it showed up at the 30% level in pavumeter and forced a new Pidgin notification sound — the pops were still there.

I started searching in Google and stumbled upon ArchLinux’s PulseAudio documentation. (Their documentation is really awesome.) There’s a mention of the flat-volumes PulseAudio configuration option. If it’s set to no, you get the older ALSA functionality where volumes can be set independently per application. The default is yes and that default comes with a warning in the documentation:

Warning: The default behavior can sometimes be confusing and some applications, unaware of this feature, can set their volume to 100% at startup, potentially blowing your speakers or your ears. To restore the classic (ALSA) behavior set this to no.

As a test, I switched flat-volumes to no in /etc/pulse/daemon.conf. I restarted PulseAudio with the new setting:

pulseaudio -k
pulseaudio --start

I started music in Chrome and sent myself an IM in Pidgin. No pops! An email came through and Thunderbird and a notification sound played. No pops there, either!

GNOME 3 was a bit unhappy at my PulseAudio tinkering and the volume control disappeared from the menu at the top right. I logged out of my GNOME session and logged back in to find the volume control working again.

Photo Credit: Our Thrift Apt. via Compfight cc

Upatre and icanhazip

This is why we can't have nice thingsI recently updated the icanhazip FAQ about the resurgence of the Upatre malware and how it’s abusing icanhazip.com. The abuse reports keep coming into the ISP’s where I host the site and it’s becoming a challenge to defend each one.

From what I’ve read, Upatre is a piece of malware that has been around in one form or another since 2013. Somewhere along the way, it began making calls to icanhazip.com to determine the public-facing IP address of the machines that it infects. I’m sure this was done by the malware authors to figure out which kinds of targets they hit. If they know the external IP address, they can easily figure out how valuable the target may be.

The information security community has been really helpful and I’ve received emails from several people with ways to identify the malicious requests and deny them. The malware changes over time and the most recent updates mimic the requests made by very recent versions of Firefox on Windows. Separating those requests out from the legitimate ones is extremely difficult.

I’d like to explore some ways to provide sanitized log data from icanhazip to certain security organizations so they can find trends and help more people stomp out this highly annoying piece of malware (among others).

If you have any feedback on how this might be done, let me know. Also, if you think it’s a horrible idea, let me know as well.