Author Archive

The Case of the Stolen Source Code

Wednesday, May 17th, 2017

Last week, for about three days, the macOS video transcoding app HandBrake was compromised. One of the two download servers for HandBrake was serving up a special malware-infested version of the app, that, when launched, would essentially give hackers remote control of your computer.

In a case of extraordinarily bad luck, even for a guy that has a lot of bad computer luck, I happened to download HandBrake in that three day window, and my work Mac got pwned.

Long story short, somebody, somewhere, now has quite a bit of source code to several of our apps.

Before I continue, three important points:

  • There’s no indication any customer information was obtained by the attacker.
  • Furthermore, there’s no indication Panic Sync data was accessed.
  • Finally, our web server was not compromised.

(As a reminder, we never store credit card numbers since we process them with Stripe, and all Panic Sync data is encrypted in such a way that even we can’t see it. Read more.)

The other important fact is that I feel like a monumental idiot for having fallen for this.

How did this happen?


HandBrake had been nagging me for some time to install an update. I finally decided, for whatever reason, to do the update. There was a note in HandBrake’s update dialog that the incremental update was not available, and that I’d have to download an entirely fresh copy from their server. I didn’t think too much of this, as we’ve been in a similar situation with a broken Sparkle update channel once before (the worst).

So, I managed to download within the three day window during which the infection was unknown, managed to hit the one download mirror that was compromised, managed to run it and breeze right through an in-retrospect-sketchy authentication dialog, without stopping to wonder why HandBrake would need admin privileges, or why it would suddenly need them when it hadn’t before. I also likely bypassed the Gatekeeper warning without even thinking about it, because I run a handful of apps that are still not signed by their developers. And that was that, my Mac was completely, entirely compromised in 3 seconds or less.

By the time news broke of the HandBrake infection, git credentials had already been stolen from my Mac and used to clone several of our source code repositories, according to our logs.

As soon as I discovered the infection on my Mac, I disabled it, took the Mac out of commission, and we began the incredibly lengthy process of changing all of my passwords, rotating the relevant secret keys throughout our infrastructure, and so on, to re-lock our doors and hopefully prevent anything else from being stolen. The vast majority of these things were changed or rolled simply out of an abundance of caution — again, there’s no indication our web servers were compromised — but in this kind of a situation, you change all the locks.

Then, the forensics: we began combing through our logs to try to determine the extent of what was accessed which, to reiterate, we believe is limited to source code and personal data on my Mac. Thanks to good logging (thank you, James) we got a very complete picture. The method the attacker used prevented them from cloning all of our source code — they were making educated guesses at our repo names, one-by-one, which did not expose everything.

The source code theft was confirmed when we received an email from the attacker (with a few source code files attached as proof of the theft) demanding a large bitcoin ransom to prevent the release of the source code, which would “suffocate” our company, in their words. We’re working on the assumption that there’s no point in paying — the attacker has no reason to keep their end of the bargain.

And that brings us to today.


When the dust settled, we sat down for a company all-hands meeting, and the conclusion was a little different than I originally expected.

Someone has a bunch of our source code. But does it really matter?

There are essentially three “worst case” scenarios we considered with our source being out there in somebody’s hands:

  • They build free, cracked version of our apps.
    Guess what — those already exist. You can already pirate our software if you want to pirate our software — but please don’t — so this doesn’t really change anything in that regard. Also, whatever “free” version of our apps that would come from this person are virtually guaranteed to be infected with malware.
  • They create malware-infected builds of our apps.
    This seems likely. Given the person’s entire MO was to infect a well-used Mac app with malware, it seems inevitable. But we will find them, and working directly with Apple, shut them down. To minimize your risk, never download a copy of one our apps from a source that is not us or the Mac App Store. We are going to be hyper-vigilant about the authenticity of downloads on our servers.
  • A competitor obtains this source to attempt to use it to their advantage in some way.
    The many Mac developers we’ve met over the years are fine, upstanding people. I can’t imagine any of them being this unethical, or even being willing to take the risk of us finding fingerprints of our code in theirs. And let’s not forget that — you guessed it — there’s a good chance any stolen source could have malware slipped into it.

Also, one important thought gave us some comfort:

With every day that passes, that stolen source code is more and more out-of-date.

This hack hasn’t slowed us down. That source is already missing a ton of fixes and improvements we committed over the last week alone, and six months from now it will be missing major critical new features. In short: it’s old and getting older.

At this point in our discussion, we even half-seriously considered releasing the source code ourselves — and when that idea was floated, and we realized there wouldn’t be any fallout (other than a lot of code questions!), that’s when we truly felt free.


Within 24 hours of the hack, we were on the phone with two important teams: Apple and the FBI.

Apple rallied the right security people quickly to learn all they could about our situation. (They had, of course, already blocked the HandBrake-attached malware for the broader Mac population once it was discovered widely.) They walked us through the best way to roll our Developer ID and invalidate the old one, which we don’t think was leaked, but we’re being overly cautious. And more importantly, the right people at Apple are now standing by to quickly shut down any stolen/malware-infested versions of our apps that we may discover.

The FBI is actively investigating, so I can’t say anything more about that.


We’ll be working overtime for the foreseeable future to keep an eye on this situation.

But we could also use your help.

If you see any cracked or otherwise unofficial versions of our apps in the wild, it’s safest to assume they are infected, and we ask that you please let us know. If you see our source show up somewhere, also let us know. And if you have information that could help with the investigation into this incident, definitely let us know.

The more we know, the more we can use every method available to us — legal, technical, you name it — to fix it.

Feel free to e-mail us or DM us on Twitter anytime — even if you just have questions. We’re here.

And as a reminder, never download one of our apps from a source that is not our website or the Mac App Store.

This has been a hard post to write. I hate that this happened. I kick myself every day for not paying attention to what I was doing; the tells were obvious in hindsight. It’s a good reminder though — no matter how experienced you might be with computers, you’re human, and mistakes are easily made. And even though this doesn’t affect our customers directly, we want to apologize that we’re even having to have this discussion with you.

We’ve been doing this 20 years because you keep us going every day — by buying our software, by giving us your good ideas, by telling your friends about us. You are the good in the world. So we’re going to do everything we can to rise above this and keep going even further — together.

Introducing Transmit iOS

Wednesday, September 17th, 2014




Some ideas don’t make sense until suddenly they do.

Ever since it became possible to write third-party iOS apps, we’ve received the occasional request to bring Transmit to iOS and, to be honest, it never made much sense to us. That is, until this year’s WWDC.

Up until that point, iOS apps had very limited reach in terms of access to other apps’ documents, so we struggled to find an answer to our time-honored litmus test of “what would we use this for?” Was an app that simply allowed you to transfer files in and out of itself particularly useful?

Especially with many highly-regarded file storage and document reader apps already on the App Store, it seemed like our chances of carving a worthwhile niche were tiny at best. We experimented with the idea a little and ultimately shelved it.

Then came the introduction of iOS 8. It’s an exciting update for users, and a really exciting release for developers, not least because of a little something called App Extensions. By utilizing App Extensions, Transmit could effectively provide standard file transfer protocols for any iOS 8 app. Overnight, this idea that made very little sense suddenly made all the sense in the world.

And so, after a bit of a mad dash to get it ready in time for iOS 8’s debut, we’re proud to introduce Transmit iOS. It’s the world’s best file transfer client, now seamlessly integrated right into your iPhone or iPad.


02 - File Listing

Browsing a directory listing

Not just a pretty face, Transmit iOS shares the same rock-solid engine as the Mac version, so you’ll find all of our currently supported protocols: FTP, SFTP, WebDAV, Amazon S3, and S3-compatible services such as DreamObjects.

Every compatibility and performance tweak that has made its way into the Transmit engine over the last 16 years (!) is present and accounted for. Future improvements and fixes will make their way to both the Mac and iOS versions.

01 - Servers

Browsing available servers and connection options

03 - Clouds

Previewing a remote image

On iOS, Transmit gets a fresh new look — in perfect harmony with iOS 8’s style but with a bit of our own flair. In the Transmit app, you can store, download, and upload files as with any pre-iOS 8 file manager, but it’s the way Transmit extends your whole iOS experience that’s the best part.

Let’s start with sharing.

You’re probably already familiar with the Share button in iOS. If you’re, say, looking at a photo, you can tap the Share button and send the photo by email, iMessage, AirDrop, and so on. With Transmit iOS installed, you can also now send that photo (or other document) to any FTP, SFTP, WebDAV or Amazon S3 server, right from Photos.

In other words, any iOS app that supports the Share sheet magically gains support for these protocols when you install Transmit iOS.

05 - Share Sheet

Sharing photos with Transmit iOS

Without leaving the app you’re in, you can bring up a full Transmit interface within that app, navigate to a particular folder, and send your file. Then Transmit goes away and you’re right back where you were, without any cumbersome app switching. That’s a big deal, and a first for iOS.

But wait, there’s more!

New in iOS 8 is the Document Picker. The Document Picker is an extensible way for iOS apps to open a document from an outside source.

Transmit iOS hooks in here too, which means — you guessed it — any iOS 8 app that supports the Document Picker can now open files remotely from your FTP, SFTP, WebDAV or Amazon S3 server, without leaving that app.

(You can even re-save the document, and the changes will go back to the server it came from!)

Concerned about security? If you’d like, Transmit iOS can restrict access to your servers by requiring Touch ID authentication. That means you don’t have to remember or re-enter your server password each time.

We think Transmit iOS is a fantastic new way for advanced users to manage files on their iPhone, iPad, and beyond. Since it’s a brand new 1.0 product, we’ll be looking forward to your feedback to help us steer it in the right direction.

Please give Transmit iOS a try and let us know what you think!

Also worth noting: Transmit iOS is currently only $9.99 for a limited time. If you want to get in on this incredible new tool, we suggest doing it quickly!

(One last note: many people here were involved in making Transmit iOS, including years of FTPKit care and feeding from Wade and Will, and Neven’s immaculate design work, but I wanted to specifically send a big thank you to all-around Panic good guy Logan, who worked tirelessly to make Transmit iOS happen. Thanks so much, Logan!)


Update on Coda 2.0.1, Mac App Store version

Friday, June 15th, 2012

Update: Coda 2.0.1 is now available in the Mac App Store.

Many of you are waiting very patiently for the Coda 2.0.1 update to become available on the Mac App Store. We wanted to give you a quick update on where it stands.

We submitted Coda 2.0.1 to the Mac App Store on June 4; the same time we released it to our direct customers. Yesterday, after 10 days of waiting in queue, we received notification that it has entered review. It has been in that state for approximately 24 hours. We have heard rumors that many of the review staff are at WWDC this week, making an already slow approval process even slower. But hopefully, it will get approved within the next few days, and we won’t have any rejection setbacks.

I wish there was more we could do to speed things along, but this is simply the App Store process. It is almost as maddening for us as it is for those of you suffering crashes and waiting for an update.

Because this is such a bad situation, we are researching some ways we might be able to allow App Store customers to temporarily use direct versions while waiting for an update in the future. There are a few technical hurdles to get over first, not the least of which is the Apple-mandated feature disparity between the direct and App Store versions (in particular, iCloud-related functionality).

Please bear with us as we try to make the best of a disappointing situation.

Thanks again for your patience, and we hope 2.0.1 will be available for Mac App Store customers shortly.

About Gatekeeper

Thursday, February 16th, 2012

Today’s Mountain Lion announcement introduces an important new security feature, called Gatekeeper, in addition to the “sandboxing” feature that premiered in Lion. I’d like to talk a little bit about it, and why it’s important to all Mac users.

Malware is out of control. Almost every day I read a new article about a major security breach in a well-known organization. There is big money to be made from stolen credit card numbers and identities. End-user applications on individual computers are a prime attack vector because, even with the best tools and the best programmers, vulnerabilities sneak their way in. Trying to make applications free of vulnerabilities (while still an important goal) is to lose the overall cat-and-mouse race.

As Mac users, we’ve mostly enjoyed a life free of the worry that has followed Windows users for years. Mac OS X is pretty damn secure. But it could be more secure. As Macs enjoy increased popularity, they become a more attractive target to identity thieves and other criminals. Sooner or later, bad people ruin every nice thing. It’s an immutable law of humanity.

So, what to do about this? Code-signing, although it can’t single-handedly fix the problem forever, is a vital weapon in the fight against malware. But many folks are unclear on how it works, or how it helps. Let me try to explain in as close to plain English as I can.

An explanation of code-signing for humans

What is code-signing? Let’s start with a slightly higher-level question: what is signing? Signing is based on technology similar to encryption, so let’s discuss them both broadly.

One of the most prevalent and secure methods of encrypting or signing data is to use what’s called a “key-pair”. As the word “pair” suggests, this means there are two keys which can “unlock” the encrypted data in certain ways.

A “key” is literally just a number. But it’s a very big number, and this is important. If I asked you to guess a number between 1 and 100, you’d have a 1% chance of guessing it on your first try, and you’d be guaranteed to guess it correctly if I gave you 100 tries. But what if I asked you to guess a number between 1 and 3 trillion? That’s a bit more of a challenge.

You’ve probably heard at least in passing about encryption keys and that they have different sizes or lengths (such as 40-bit, 128-bit, or 256-bit). Just like in my number guessing example above, longer keys are harder to guess. Each additional bit that is added to a key makes it exponentially harder to guess or figure out by brute-force attempting to decrypt the data with every possible numerical key. (Is 1 the key? No. Is 2 the key? No. Is 3 the key? Is 3,426,989,662 the key? No.)

We want encryption keys to be very long so that brute-force guessing attempts would take literally thousands of years. They become an unreasonable attack vector given the current average human lifespan.

So, why two keys? In key-pair encryption, one key is called the “private key” and the other is called the “public key”.

The keeper of the private key is able to “sign” data; a process which both identifies its origin and provides reasonable proof that it has not been altered. Private keys must be guarded very carefully, so that signatures cannot be forged.

The public key, as its name suggests, may be distributed freely. In encryption, the public key can be used to encrypt data which can only be read by the owner of the corresponding private key. In other words, with my public key, you could send me a secret message that only I could read.

In signing, the public key can be used for another purpose: to verify (with an extremely high degree of mathematical probability) that a “signed” piece of data came from me. Or, to be more specific, could only have come from someone with access to my private key. Which, hopefully, is just me.

In a nutshell, that’s what signing is. Even without actually encrypting it, I can take a chunk of data, run it through a very complex mathematical process to “sign” it with my unique private key, thus generating a second chunk of data called a “signature” that could (statistically speaking) only have come from that specific combination of data chunk and my private key.

Anyone with that signature and my public key can then be almost 100% sure that data came from me, and that it was not modified by any third-party along the way. The data could’t have any virus or vulnerability injected into it, because then the signature would no longer match the data.

So, signing allows us to, with very high confidence, ensure that we are who we say we are, and that the data we produce really came from us. Code-signing, then, is simply applying that signing process to executable code like a Mac app. If I try to start up an app, the operating system can validate that the app’s signature is valid, and perhaps also that it is the signature of a known, trusted developer. If it doesn’t pass muster, the OS can refuse to run the application.

Which brings me to Gatekeeper.

The role of Gatekeeper

The iOS devices (iPhone and iPad) effectively have had a Gatekeeper built into them since their very first release. When we write an iOS app, we sign it, then send it to Apple to review. Apple can validate the signature to ensure that it hasn’t been tampered with — that it really came from us — and then it goes into the app review process.

If the app passes review, it is then signed again by Apple, and posted to the App Store. Since Apple is the only entity able to sign App Store applications, iOS will simply refuse to run any app that doesn’t have Apple’s signature — it obviously didn’t come from the App Store. (If you “jailbreak” an iOS device, this is the security check you are bypassing. You are lobotomizing iOS so that it will merrily run “unsigned” code from any source. As you can hopefully tell by now, this has both benefits in terms of flexibility and very significant risks in terms of security.)

But how to bring this level of security to Mac OS, which has always allowed unsigned code from any source to run more-or-less without restriction?

The simplest thing Apple could have done would have been to make the Mac App Store the sole source for Mac apps, in the same way the App Store is the sole source for iOS apps, shutting off every other app distribution venue in the process. While this would have immediately solved the problem, you would have seen developers’ heads bursting into flame and flying across the room in rage. Why?

Although security is a vital feature for Apple, developers, and users alike, being unable to run unsigned code cuts a lot of really great things off at the knees. You wouldn’t, for example, be able to just download and run an open source project unless it had been submitted to and reviewed by the App Store. Highly disruptive software (think Napster or BitTorrent) may have not been able to exist on the Mac platform since it would have been likely to run afoul of Apple’s App Store guidelines. Major vendors such as Adobe and Microsoft might have withdrawn their support for the platform, being unwilling to cede 30% of their revenue to App Store distribution.

So, for a while, there was a great deal of consternation among Mac developers, including this author, that this might be the route Apple would take. In recent years, Apple has shown a trend of following the most hardline possible stance that will benefit users and Apple, often at the expense of developer freedom, and gradually backing in certain affordances (push notifications, for example) as user-impacting problems became evident. So it seemed feasible that we’d wake up one day and Apple would decree that all Mac apps must be sold through the App Store.

But instead, Apple went to considerable effort and expense to find a middle ground.

Controlling Gatekeeper in Mountain Lion

In Mountain Lion, you, the user, have three options:

1. You can let anything run on your system, whether or not it is signed. This is the Mac OS of today. It’s like having a jailbroken iPhone.

2. You can allow only Mac App Store apps to run on your system. This is the most secure option, but you lose the ability to run non-App Store software, which currently includes such products as Microsoft Office and Adobe CS.

3. You can allow only Mac App Store apps or apps signed by a developer. This is the new default.

It’s this third option that is critical. As a developer, I can register for a unique ID which allows me to sign my app but does not require it be sold through the App Store. Users get the benefit of knowing the app came from a trusted source. But I retain the ability to sell my app directly to end users.

If my app were to do something nefarious, my developer ID would get revoked and that would be the end of that. My app would no longer be allowed to run (unless you specifically allowed unsigned apps). As a matter of fact, if you try to launch an unsigned or unvalidatable app on a Mac with Gatekeeper enabled, the default button is “Move To Trash”. Pretty hardcore. Kind of awesome.

It is really quite a nice compromise.

I have a personal flaw in the form of a small conspiracy theorist who lives in my head. He worried that this may have been created as just a temporary stepping stone — like Rosetta for the Intel transition, or Carbon for the OS 9 to OS X transition — and that one day, the Mac App Store-only option might still be enforced.

But I can’t find it in me to disparage this goodwill effort that Apple has undertaken to not turn every third-party developer upside-down with regard to app distribution. To me it’s a great sign that they’re aware and at some level sympathetic to our concerns, while remaining committed to a high-security experience for users.

Further cementing this feeling is the fact that we were invited to a private briefing at Apple about Gatekeeper a week before today’s announcement. Cabel was told point-blank that Apple has great respect for the third-party app community, and wants to see it continue to grow — they do not want to poison the well. I think their actions here speak even louder than their words, though.

One worrisome rift

There remains one thing that is of concern to me. Despite these great strides forward, Apple is walking a dangerous line with regard to features that are only available to App Store distributed apps. The two most prominent examples are iCloud and Notification Center. Cabel asked Apple if, thanks to Gatekeeper and Developer ID, App Store-only features would be eventually be available to signed apps that were not distributed through the App Store. There was some shuffling of feet and a “we have nothing to announce at this time”. It didn’t sound particularly optimistic.

It would be a shame if this trend continues, as it creates an artificial gulf between App Store and non-App Store apps. For example, as things stand today, we won’t be able to offer iCloud syncing in, say, Coda 2, when you purchase it directly from us. Only App Store purchasers would get that feature. Making matters worse is Apple offers us no real facility to “cross-grade” you from a direct purchase to an App Store purchase, should you change your mind.

There’s no real engineering reason that I can think of for this. It seems marketing or money-driven, and I think it’s un-Apple-like to chase the money at the expense of user experience in that manner. We hope they change their minds about that particular facet.

Moving forward

Other than that though, we think Gatekeeper is a bold new feature that should do wonders for the security of your Mac for years to come. Even though their rapid pace of development is at times difficult for us to keep up with, we are excited that Apple continues to aggressively push the envelope when it comes to keeping Mac OS X safe and secure.

Newton Never Dies

Friday, September 17th, 2010

This is extra-curricular, but we thought you might find it interesting.

Einstein is an open-source project to run (via emulation) the Newton OS on modern hardware. It was written and released by Paul Guyot several years ago. It’s quite an amazing piece of work.

The project got a shot in the arm earlier this month when Matthias Melcher got it up and running on iOS and posted a video of himself running it on his iPhone. Being a Newton fan since my original MessagePad in 1993, it was quite a sight to see.

Matthias mentioned he didn’t have an iPad yet, so I grabbed the source and built it for my iPad so I could take a little movie and share:

Since then, I’ve been graciously granted the ability to contribute changes to the Einstein code base. My work has so far been limited to just helping out with the iOS port. I don’t yet know much about the guts of the emulator.

The last couple of evenings and very early mornings (not during Panic hours!) I’ve helped get the existing CoreAudio sound driver working on the iOS build, and made some tweaks to allow the virtualized Newton to run at any screen resolution. In this video, it’s running at the iPad’s native resolution of 768×1024, but you can also run at the original 320×480 scaled-to-fit.

To answer the most common questions:

  1. At this time, they can’t release a binary of the emulator, because it currently requires the Newton ROM image to be compiled in. Obviously, nobody has the right to distribute the ROM image except for Apple. The plan is to change things around so you can dump the ROM from your own Newton, and side-load it into the app via iTunes’ file exchange feature.
  2. The emulator is a bit slow and occasionally glitchy. It runs at maybe half the speed of a real Newton. But I hear there are a lot of optimizations yet to be made, which should vastly improve the situation.
  3. It’s not completely tied into the iOS hardware yet — for example, a physical iPad keyboard won’t work, and it doesn’t yet read the time and date from the iPad, and so on. The to-do list is long, but the progress is exciting.
  4. There is probably not even a remote chance that they will let this on the App Store.

Regardless, I hope you enjoy this blast from the past — proof that, no matter how “obsolete”, it’s very hard to kill a technology that people are passionate about.