Mykola Grymalyuk (PDF, via Mr. Macintosh):
The talk was a look into Apple’s Rapid Security Response system unveiled back at WWDC2022, discussing the design and challenges of the system.
But Apple seemingly abandoned the system a year after its introduction.
Filipe Esposito (Aaron):
With iOS 26.1 beta 1, which was released to beta testers on Monday, the company is rebuilding how Rapid Security Responses work. According to code discovered in the beta by Macworld, the system will soon be called Background Security Improvements. The feature doesn’t seem to be available to users running the beta, but its existence in the code suggests it’s coming soon.
Essentially, the new system serves the same purpose: to deliver quick and urgent security patches that do not require a new version of iOS, which takes longer to develop. But there’s a key difference between Rapid Security Responses and the new Background Security Improvements: The new Background Security Improvements will be installed silently on the device without needing to manually update. Previously, users had to download Rapid Security Responses through the Settings app just like any other iOS update.
Previously:
Update (2025-09-24): Buccia:
Rapid Security Response was used only once and it broke many websites due to parenthesis in the OS version included in the User-Agent header.
Background Security Improvements iOS iOS 26 Mac macOS Tahoe 26 Rapid Security Response Security
André Arko (via Reddit):
As chronicled by my teammate Ellen, the RubyGems team is no more. I wish the best of luck to everyone taking on the herculean task of keeping package management functional and working for the entire Ruby community.
Ellen Dash (PDF, Lobsters):
On September 9th, with no warning or communication, a RubyGems maintainer unilaterally:
- renamed the “RubyGems” GitHub enterprise to “Ruby Central”,
- added non-maintainer Marty Haught of Ruby Central, and
- removed every other maintainer of the RubyGems project.
[…]
On September 18th, with no explanation, Marty Haught revoked GitHub organization
membership for all admins on the RubyGems, Bundler, and RubyGems.org maintainer teams.
By doing this, he took control for himself and other full-time employees of Ruby Central.
She calls it a “hostile takeover.”
Ruby Central (Reddit):
As the nonprofit steward of this infrastructure, Ruby Central has a fiduciary duty to safeguard the supply chain and protect the long-term stability of the ecosystem. In consultation with legal counsel and following a recent security audit, we are strengthening our governance processes, formalizing operator agreements, and tightening access to production systems. Moving forward, only engineers employed or contracted by Ruby Central will hold administrative permissions to the RubyGems.org service.
In addition, with the recent increase of software supply chain attacks, we are taking proactive steps to safeguard the Ruby gem ecosystem end-to-end. To strengthen supply chain security, we are taking important steps to ensure that administrative access to the RubyGems.org, RubyGems, and Bundler is securely managed. This includes both our production systems and GitHub repositories. In the near term we will temporarily hold administrative access to these projects while we finalize new policies that limit commit and organization access rights.
[…]
Looking forward, our goal is to move these projects into a healthier, more transparent and community-centered governance model that is more in line with OSS development.
It seems natural be skeptical since they started out with the opposite of transparency.
Freedom Dumlao:
People are asking for some kind of statement from the Ruby Central board, but this is a small group of volunteers spread out all over the globe. We are software developers and makers and builders first. We don’t have some big PR machine or communications team. It’s just us. And we’re suddenly overwhelmed by feedback from our community that we aren’t equipped to quickly respond to.
[…]
So what really happened? From my perspective it’s far more boring (or should have been) than anyone is making it out to be. Ruby Central has been responsible for RubyGems and Bundler for a long time. This isn’t a new development, and I’m honestly very confused about the confusion.
What isn’t confusing is that supply chains are under attack. We can see this in recent attacks on RubyGems and also in major attacks on other ecosystems that have made global news. Companies that depend on Ruby count on Ruby Central to ensure they are not at risk. Some of those companies are sponsors of Ruby Central and some are not, but all have a legitimate need to know that they can tell their users that the software they are using is safe.
[…]
If Ruby Central made a critical mistake, it’s here. Could these conversations have been happening in public? Could the concerns we were hearing from companies, users and sponsors could have been made more apparent? Probably. But I remind you we don’t have a “communications team”, no real PR mechanism, we are all just engineers who (like many of you I’m sure) go heads down on a problem until it’s solved.
Martin Emde:
You say “What isn’t confusing is that supply chains are under attack.”
Then you remove the people most prepared to respond. The attack surface are was increased by changing the ownership from people who have owned and maintained these repositories independently for decades.
You said “Ruby Central has been responsible for RubyGems and Bundler for a long time.”
But this is incorrect. Ruby Central has been a gracious sponsor of PEOPLE who work on an OSS library.
[…]
Again, sorry to be a broken record, but how did you propose to control the repositories to which you had no access until Sep 9? You needed someone to add you first by breaking our existing OSS governance model.
Joel Drapper (Hacker News):
- Ruby Central was struggling for money.
- Sidekiq withdrew its $250,000/year sponsorship for Ruby Central because they platformed DHH at RailsConf 2025.
- Shopify demanded that Ruby Central take full control of the RubyGems GitHub repositories and the
bundler and rubygems-update gems, threatening to withdraw funding if Ruby Central did not comply.
- HSBT jumped the gun and implemented the takeover plan adding Marty Haught as an owner and reducing maintainers permissions before Marty had discussed this with the maintainers.
[…]
The RubyGems source code and GitHub organisation was not owned by Ruby Central, even though Ruby Central operated a service with the same name.
[…]
Bluesky threads reveal that Rafael França (Shopify / Rails Core) saw this [rv] tool as a threat[…]
Previously:
GitHub Open-source Software Programming Ruby Ruby on Rails Shopify Web
Aaron Patterson (via Hacker News):
I’m pretty sure I’d been getting corrupted images for a while, but it would only be 1 or 2 images out of thousands, so I thought nothing of it (it was probably my fault anyway, right?)
But the problem really got me upset when last year I went to a family member’s wedding and took tons of photos.
Apple Photos combines RAW + jpg photos so you don’t have a bunch of duplicates, and when you view the images in the photos app, it just shows you the jpg version by default.
After I imported all of the wedding photos I noticed some of them were corrupted.
Upon closer inspection, I found that it sometimes had corrupted the jpg, sometimes corrupted the RAW file, and sometimes both.
Since I had been checking the “delete after import” box, I didn’t know if the images on the SD card were corrupted before importing or not.
After all, the files had been deleted so there was no way to check.
I estimate I completely lost about 30% of the images I took that day.
[…]
I was worried this was somehow a hardware problem. Copying files seems so basic, I didn’t think there was any way a massively deployed app like Photos could fuck it up (especially since its main job is managing photo files). So, to narrow down the issue I changed out all of the hardware.
[…]
However, after I got home from RailsConf and imported my photos, I found one corrupt image (the one above).
I was able to verify that the image was not corrupt on the SD card, so the camera was working fine (meaning I probably didn’t need to buy a new camera body at all).
It sounds like some sort of concurrency bug. It’s unclear to me whether the camera itself—which he seems to be using instead of a separate SD Card reader—is a factor, but the same setup worked when importing to Darktable instead of Photos.
Bug Concurrency Darktable Data Integrity Datacide Mac macOS 15 Sequoia macOS Tahoe 26 MicroSD Photos.app Raw Image Format
Juli Clover:
Back in August, Australia’s federal court ruled that the Apple App Store had violated competition laws by prohibiting sideloading and alternative payment methods.
At the time, the court had not shared a written judgment, but now the 900-page document has been published and additional information on the court’s decision is available. In a statement to MacRumors, Apple said that it does not agree with the court’s decision and will continue to argue its position in court.
[…]
The court adopted a narrow definition of the markets in play, viewing iOS as its own ecosystem and concluding that Apple has a monopoly over iOS app distribution and in-app payment processing.
[…]
The Australian court used Europe’s Digital Markets Act as evidence that alternative app distribution is possible, but Apple says that the viewpoint ignores the risks associated with skirting the App Store’s security and privacy protections.
Ben Lovejoy:
Regulators tend to take the view that the relevant market is “iOS apps,” and here Apple has a 100% monopoly on their sale and distribution. Edge cases aside, there is no way for a developer to bring an iOS app to market without selling it through the App Store.
[…]
The court did agree that Apple has a right to charge for its intellectual property, and that the company’s prohibition of third-party app stores is justified.
Previously:
Antitrust App Store Apple Australia Digital Markets Act (DMA) Epic Games External iOS Payments iOS iOS 18 Legal Sideloading
