Homebrew
brew audit causes Transmit downloads to fail
#6419
-
Output of
|
Beta Was this translation helpful? Give feedback.
Replies: 3 comments 8 replies
-
|
This is an issue even from the browser, I have had consistent timeouts when trying to download the application, even from browser. If it remains consistent we may have to disable the cask. |
Beta Was this translation helpful? Give feedback.
-
|
Both URLs work for me from the browser, so maybe it's a temporary issue. @jabenninghoff , try your |
Beta Was this translation helpful? Give feedback.
-
|
After downloading the file again, I can't even visit the upstream archive from https://download-cdn.panic.com/transmit/ - it just times out. |
Beta Was this translation helpful? Give feedback.
-
|
Huh, you're right, their CDN seems to be on the fritz. |
Beta Was this translation helpful? Give feedback.
-
|
Update: Panic is aware of the issue and working on fixing it. I've sent them details, including links to this discussion item, and the Transmit PR (Homebrew/homebrew-cask#228737). Hopefully they can figure it out soon! |
Beta Was this translation helpful? Give feedback.
-
|
Hey all, I'm a developer who works on Transmit, and I'd like to apologize for the problems, explain what caused them, and start a discussion on how we can prevent issues download issues with homebrew in the future. We host our own servers at a data center here in Portland, and in the past, we've had issues where the data center's ISP, Cogent, has had peering issues or with consumer ISPs all over the world. So we switched to a hybrid model where we host the downloads on our own servers but also have CDNs in many regions worldwide. Hosting on the CDNs is much more expensive than hosting in our data center, but we have pricing such that we pay a flat rate for a certain amount of bandwidth each month. However, if we exceed that limit, it gets expensive quickly. This has rarely been an issue in the past, but spoiler alert, that changed recently. A few months ago, a pirated version of Transmit started making the rounds that contained a modified version of Sparkle that re-downloads Transmit from our CDN over and over again. This isn't an intentional DDoS attack. Instead, it was an attempt to prevent Sparkle from updating the app to a non-pirated version. Outside of the Mac App Store, hacked versions of Sparkle are the most common way to pirate Mac apps. Because Sparkle is open source and nearly every application links it, Sparkle is an easy target for those who want to crack Mac apps. Make one modified version of Sparkle, and you can inject code into every app. System Integrity Protection prevents apps hacked this way from running properly, but disabling SIP has become commonplace among those who run pirated apps. Most of the time, these versions of Sparkle completely disable update checking so that the app won't update to a non-cracked version, but this one was instead modified to prevent the download from succeeding, causing Sparkle to repeatedly re-download the zip file from the CDN. This caused our bandwidth to explode to over 1 TB a day per region. Since the Transmit download is only 38 MB, that's over 25k downloads per region per day. Facing huge bills from our CDN provider, we limited requests to 1 an hour, under the assumption that no normal user would need to download the zip file more than once an hour. You can see the effect it had on our bandwidth in the chart below. The traffic we're seeing is still higher than normal, because the pirated versions of the software still get to download one copy an hour, but it's remained below our flat-rate caps. 
We quickly learned that this broke installs from homebrew users when they started sending us support mails. Looking at the homebrew source code, I saw that homebrew first sends a HEAD request before sending a GET request. Fair enough. We relaxed the rate limiting to allow for a few requests per hour, knowing that it would increase the bandwidth used by the cracked versions, but we watched it to make sure we were still staying under our caps. We thought things were working well until @jabenninghoff emailed us. Today, we spent some time looking deeply at the traffic patterns of the cracked versions of Transmit and deployed an advanced rule that we believe will completely block the cracked versions while leaving everyone else alone. The danger of this approach is that if the patterns from the cracked versions change, we could find ourselves with another high CDN bill. These bills are a large financial risk to our company, so if this happens, we may need to slam on rate limiting again, which could cause problems for homebrew users again. We'd like to avoid that if at all possible. To that end, @jabenninghoff informed us that this job runs every three hours and downloads the app multiple times. If that's true, is there any way I could convince you to change that behavior, or at least ask why homebrew needs to do this? We could allowlist the specific IPs running these jobs if it's absolutely necessary, but that could break if the IPs change, and I'm kind of curious as to why you'd need to download the app multiple times. Outside of homebrew, our users either download the app once from our site and update it from Sparkle, both of which only send one request our CDN. Although users sharing an IP address through NAT could also be affected by limits, we believe that it's unlikely that non-homebrew users would be seriously affected if we limited it to 6 requests an hour from our CDN. Again, we're no longer doing this, but might have to reinstate these limits if the cracked versions of Transmit start evading our block rules. If this job is checking for updates, rather than downloading the entire app, I could provide you with a URL to Sparkle feed to check instead. That would use less bandwidth on our end, and I'm sure it would be faster for your job than re-downloading the file every time. And somewhat related, is there a way to configure the Transmit cask to skip the HEAD request and just issue a GET request to download the app? The HEAD request isn't really an issue bandwidth-wise, but makes it more difficult to enforce the rate limits without causing issues for users. Thank you for your consideration, and for reading this very lengthy explanation. I hope we can come up with a solution that works better for homebrew and for us. |
Beta Was this translation helpful? Give feedback.
-
|
Hello @Michael-Panic and thanks for your detailed response! I think the Homebrew team can offer a more complete answer, but they are shifting to using Sparkle to check for updates, see: Homebrew/homebrew-cask#228737, and the app should only be downloaded when there is a new version; but when that does happen it does seem to be downloaded more than once (perhaps just twice?), I'm just not sure of the details. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the detailed reply @Michael-Panic - regarding the multiple downloads, every 3 hours we check for a new version, which we have done by checking the response headers from When a new version is found, we download the file in a CI workflow to test that it works as intended, and to calculate a checksum. This can happen more than once, as we test on both intel and Apple Silicon architectures. The download itself is only fetched once, but we do make some subsequent requests that only check for the presence of Here's an overview of what happens;
I believe that after the initial download, things are failing because the additional checks are blocked. I think we do set a specific |
Beta Was this translation helpful? Give feedback.
-
|
Allowlisting a specific user agent should solve the issue nicely. I doubt that the pirated versions would switch to your user agent. Do you happen to know what the user agent is? It's reassuring that the app is only downloaded if there's a new version. I'm not sure I completely understand why it would need to be downloaded on both architectures instead of downloading it once and just checking which slices the binary has, nor do I understand the HTTPS check since all our URLs are HTTPS, but I don't think it should really be causing significant bandwidth issues. |
Beta Was this translation helpful? Give feedback.
-
|
The user agent has some variation as it includes the current Homebrew version and the curl version. |
Beta Was this translation helpful? Give feedback.
-
We test on an Intel machine, and an Apple Silicon machine. So each of those VMs pulls down the file to install it and perform checks. |
Beta Was this translation helpful? Give feedback.
Hey all,
I'm a developer who works on Transmit, and I'd like to apologize for the problems, explain what caused them, and start a discussion on how we can prevent issues download issues with homebrew in the future.
We host our own servers at a data center here in Portland, and in the past, we've had issues where the data center's ISP, Cogent, has had peering issues or with consumer ISPs all over the world.
So we switched to a hybrid model where we host the downloads on our own servers but also have CDNs in many regions worldwide. Hosting on the CDNs is much more expensive than hosting in our data center, but we have pricing such that we pay a flat rate for a certain amount of bandwidth ea…