Requiring MFA on popular gem maintainers
blog.rubygems.org
blog.rubygems.org
One interesting (IMO) aspect of this: there are secondary package ecosystems that piggyback on RubyGems that don't qualify for the 2FA mandate at the moment (since, as user-installed packages, they don't have quite the same volume as an extremely popular library package).
The biggest one I can thing of is CocoaPods[1] -- huge swaths of the iOS and macOS ecosystems rely on it, but it has "only" 57 million RubyGems downloads[2] and therefore doesn't qualify as a top-100 package. This demonstrates (again, IMO) the need for manual curation on top of a uniform policy for the top N packages.
Perhaps accelerated by the vulnerability 3 months ago: https://news.ycombinator.com/item?id=31298435
--
Implemented for npm 2.5 months ago: https://news.ycombinator.com/item?id=31573578
--
PyPI's transition was summarized a month ago on LWN: https://news.ycombinator.com/item?id=32111738
which linked the discussion I was originally looking for, where a project owner considered potential downsides: https://news.ycombinator.com/item?id=32037562 and a response: https://news.ycombinator.com/item?id=32061428
FWIW this has been in the works since January: https://github.com/rubygems/rfcs/pull/36
You can also get database dumps here to dig further: https://rubygems.org/pages/data
The original plan was to target based on download rankings, but these fluctuate, so in theory gems could be added and then removed from the list. A count of downloads can only go up.
This seems to be like it would mitigate the on/off problem of using a variable metric while also being biased to the currently relevant gems/users.
So, you really want every possible assurance that that code does what it says. And MFA is a good start for that.
As it happens I gave a talk[0] about how to rank projects according to their risk. A surprisingly difficult topic.
I do hope that, eventually, it will be mandatory for all publishing.
I am forever worried that if I sign myself for 2FA in 50 different services and then I lose my phone I may permanently lose access to my accounts.
Backup code (very long, one-time-use password.)
Well RubyGems itself, subject of this post, has 12 for a start.
GitHub's codes are 8 alphanumerics,
Dropbox 8 alphanumerics,
Live.com offers a 25 alphanumerics
Google 8 numeric
Facebook 8 numeric
Nintendo 8 numeric
Login.gov 12 alphanumerics
Gitlab 16 hexadecimal
I'm sure some fool somewhere used a six digit numeric "recovery code" but the usual, while it isn't 40 is certainly more than 6.
Entertaining related story... a few months ago, I tried signing up for Celsius, the crypto exchange that went bankrupt. Their sign up process required MFA, and for some reason the only app they supported was Authy. Unlike most any other site, instead of giving you a QR Code to scan, Celsius would do something weird where they have some sort of push message mechanism that's supposed to initiate the MFA setup process from within the Authy app. I never did get it to work. I have a personal rule that if the signup/signin process for a service is too arduous, I simply won't use that service if I have viable alternatives. So I didn't lose any crypto in the Celsius bankruptcy because their MFA signup processes sucked.
Also you can use biometrics in Authy, fwiw. Then write down the password and put it in a safe. Then there's only 1 to remember but you can use biometrics in 1password too, so unless your threat model includes someone using your freshly chopped thumb then it should be ok.
If you have 50 two-factor authentication tokens you can use apps like Authy that allows you to do a local or remote back up of the tokens. TOTP is an RFC standard and you will find lots of apps for advanced users.
I've only gotten a new phone once. Was android to android. I was able to transfer everything from the old phone to the new phone as part of setup process
Granted, yesterday I had some trouble: my phone service failed to process a payment, so they disabled my service. Meanwhile I couldn't go in & review my bank info because I needed 2FA in order to login.. To make matters worse, the bank told me I needed to call a number for Loss Prevention Services to reenable sending money out of my account, & made me run around a bit looking for pay phones (surprise, they were out of order) before they let me use their phone
In my experience, ”rarely“ is more accurate than ”usually“.
The services themselves (rubygems etc.) also provide a short list of one-time account recovery codes. You’re supposed to essentially print them and put them in a safe. I wonder how many people both keep those codes and keep them somewhere secure…
1Password offers MFA and would still be available on your other devices if you lost your phone. As to if storing passwords with MFA codes is fine or a problem, I’ll let smarter people than me decided what’s best practice.
Most 2FA apps have a convenient "move all of my codes to another device" function, offer online sync, whatever.
And even if they didn't, every service provides recovery codes that you could use in case of an emergency, should you need access to some service and all else fails.
Any cross-platform recommendations for TOTP program that works on Windows, Linux, Mac?
When presented with a TOTP secret, every website I've seen has presented the option to show the TOTP secret as text, which can be copied across.
A password database like KeepassXC can store the TOTPs.
FIDO / U2F hardware like Yubikeys (or various alternatives) are also a convenient second factor.
This is the usual security versus convenience problem. The site is forcing you to use an additional factor, but there is flexibility in how that is serviced. Choosing convenience may open paths for attackers, but the impact depends on your threat model.
One solution with Google at least is that they basically hardly ever require you to reauthenticate on a given device but that obviously doesn't help if the device in question breaks or is lost and is also your soft token.
As you say, not an easy problem. The happy medium depends on the threat model and is somewhere between being able to easily social engineer new access and having to show up in Mountain View with a sheaf of notarized proof of identity documents.
I tried to do this during the pandemic and the local bank branch didn't have anyone who could give me the right authentication so I had to spend a couple hours going to my local brokerage office to complete a transaction.
You are able to give away your password to bad guys, it's really easy because it's exactly like just using the password normally except whoops this was my-bank-login.example and not my-bank.example/login or login.my-bank.example or whatever the URL usually was.
WebAuthn fixes that, everybody should implement and use WebAuthn. To their partial credit RubyGems apparently noticed they ought to do this, and so this message says they're working to implement it.
It's also "very easy" to be traveling, lose your passport or ID and not have a backup with you. Or to accidentally leave your house and forget your keys inside. Or any other number of comparable scenarios.
When that happens to you, it sucks, and you will have to jump through hoops. But still that doesn't mean that passports and keys aren't valuable in terms of security.
Of course, the difference is that people understand the value of passports and physical keys, but by and large they fail to grasp the importance of IT security or how to protect themselves. This is, ultimately, an education problem. But we don't have the same internet anymore as 20 years ago, and the problems associated with identity theft, unauthorised access, etc. are much bigger than they were, so we can't afford to be too cavalier about it anymore.
Maybe, if people get locked out of their google account because they lost their recovery keys, they will in fact learn that, yes, they should have printed out their recovery keys (something which you are prompted to do), or stored them in an otherwise safe location (e.g. password manager).
Except there may not be any hoops to jump through with MFA if it is "too secure". See "I've locked myself out of my digital life" (a thought experiment):
* https://shkspr.mobi/blog/2022/06/ive-locked-myself-out-of-my...
* https://news.ycombinator.com/item?id=31652650
> Maybe, if people get locked out of their google account because they lost their recovery keys, they will in fact learn that, yes, they should have printed out their recovery keys (something which you are prompted to do), or stored them in an otherwise safe location (e.g. password manager).
Except at that point it could be too late and they've lost all access to their digital life/assets.
The difference is I can physically show myself at the embassy or consulate. I can ask a locksmith to come to my place.
I can't do either when I lock myself out of my Gmail account.
Apple is going to start rolling this out in iOS 16 and I expect many sites and platforms to implement support relatively quickly. It’ll take time for this to work its way through the ecosystem and there will still be some trade-offs that will lake someone complain, but this is one of the more promising initiatives in the “passwordless” world that many security professionals have been striving for for quite some time.
I do think that when it comes to software/package maintainers, the heavy lift of having to have an MFA solution is much smaller than for a regular user. Yes, you need to store your one-off keys somewhere safe (I use a password manager and store it in an encrypted file there whether that counts as a second factor or not is debatable, but I think the fact that my 1Password account requires an account key as well as my password when accessed from a new device helps protect against unauthorized access at least), but I do think this is an acceptable trade-off (for now) if you’re maintaining a popular OSS package.
Maintainers have to do a lot of janitorial work, it’s true. And it does often fee unfair. But I don’t think asking people who maintain popular projects to use MFA for their package system is too much.
> Many services seem to offer one-time codes for storage offline in case this happens.
Adding on: even password managers like 1Password [1] and Bitwarden [2] offer support for TOTP 2FA now.
But a good single factor is probably fine.
If only everyone would use Oauth rather than hiding it behind 'enterprise' plans...
I'm having a prepaid plan with att, and I did not pay it for a while. Recently I needed to get a text message so I went on the att prepaid website to reactivate the plan for the month so that I could get the text message.
Guess what. The att website wants to send me a text message to ensure that I am the owner of the account... to my phone... that has no plan... fun times!
The same applies to prepaid cards - if the balance hits zero, you can only do incoming calls and texts.
Obviously, the provider will still send debt collectors if you were on some fixed price per month plan, and those debt collectors will still try to collect moneys for the months the service didn't allow outgoing calls... I always thought it odd that a company was allowed by law to collect money for a service they didn't provide.
There's also the model where you pay a monthly subscription and receive a new device every few years or have some other benefits.
In which case, I wonder if I actually just lost my phone number altogether(?)
1. Buy a sim card from ALDI for 10€ 2. Activate 3. Use the phone until the balance is down to 0€
At this point you've got an empty balance, are unable to make calls or send texts, but you can receive calls or texts still just fine. You can also visit zero-rated websites (in the past e.g. 0.facebook.com).
When I was a child my parents would give me a phone with a SIM card in this state, they could still call me if they needed to tell me to come home, and I could still call the emergency services, and given WiFi I could surf the open web as well, but I couldn't waste money on paid services or calls.
Incoming texts will also be rejected and not delivered. In other countries (I know about Ireland, anyway) this isn't generally true.
That's why I originally said it was weird to me as somebody outside the US.
This is bizarre to me. I wouldn’t expect an inactive gmail account to receive email. Why texts?
Well, we can't just trust your phone that its plan is valid, so there is also a service frame where the tower says "Sorry 12345/ABCDE, your plan is inactive!" that uses the same frame... and it has a 160-character frame for SMS too.
SMS is literally free for providers to implement, it is just an inherent part of the phone's ping/pong process of talking to towers. So there is certainly no requirement for an active plan of any kind. As long as your phone is on the network it is notionally capable of sending or receiving an SMS, the provider just won't let it... but usually service messages ("your plan is inactive, go to this website to top up!") will be allowed.
This is on top of emergency service - 911 calls (or local equivalents) will work regardless of plan status. Actually I'm not even sure you need a SIM card at all, or if that can be done simply by IMEI...
Basically: just because a sim doesn't have an active plan, doesn't mean the SIM or the phone isn't active itself. There is still information interchange happening, and that carries SMS frames.
The account is still active (say, for six months since your last payment) and there will be even more time before the phone number is recycled.
It's like the OSI model, there are multiple layers here representing different things. An IMEI is a representation of piece of equipment. A SIM is a representation of a subscriber (or, to be more precise, it's a cryptographic 2fa token that a subscriber carries), so a piece of equipment may have multiple SIMs and a subscriber may have multiple SIMs each associated with at most 1 piece of equipment (at a time). A SIM may be associated with a phone number, and may be associated with a plan which may be active or inactive.
The data model is really:
user <-one to many-> SIM token <-many to one-> IMEI
And a phone number is an at-most-one feature of a particular SIM token.
The fact that you didn't pay your bill this month doesn't mean your phone number is inactive - someone who dials that will get a "call cannot be connected" message because the phone network still knows it's you. The carrier just chooses not to connect your call, the phone number is still actually mapped underneath.
And even if your number eventually gets reallocated, the fact that your SIM doesn't have a number associated with it is irrelevant - the network still knows you by your SIM and knows your phone by its IMEI.
The phone number is really like a domain - it's a human-readable abstraction for the physical reality of the routing layer (SIM/IMEI). And the SIM is a representation of what user-token (a user may have many tokens, but a token has at most 1 user) is using a particular IMEI.
At the network level, they don't care about your phone number - that's just used for a "DNS lookup" of what equipment needs to ring. And they can send a message to that equipment even if there's no actual phone number associated with it. You can also have a IOT SIM where there is no actual 9-digit phone number to ring it (although that's a US-specific routing scheme, other countries do it different) and the network just talks to it via its SIM.
And even if you don't have a SIM (subscriber-token) the phone still talks to the network, and can still make e-911 calls and similar, you can initiate outbound traffic too, because your phone is still connected to the network even if there's not only no phone number, no plan, but even without a SIM. It's still an IMEI in a cell talking to some particular tower even if there's not a SIM in it, and can both send/receive metadata traffic or even real traffic (e-911 calls).
I'm probably getting the finer details wrong here too... it's a very complex model with a lot of entities and relationships.
For some fun tangential stuff on the topic, especially surrounding the SIM card, check out this DEFCON video. It goes into the 2fa nature of the SIM - actually the SIM is a full security processor (javacard) that can execute arbitrary javacard applets sent by the network, and push/poke stuff into the SOC or baseband directly, it is like an "Intel management engine for phones" and it has a huge amount of power over what the SOC can do and see on the network.
1. You get given recovery codes when you enable MFA. Each is a single-use code that stands in for an OTP code. If you kept them, you can use these to login and then change your device.
2. If you lost those too, there's a manual reset process. As you can imagine it's slow and requires careful scrutiny to guard against social engineering attacks on the rubygems.org maintainers.
In future it will be possible to use WebAuthn[0] for rubygems.org and, ideally, you will be able to bind multiple hardware tokens or biometric devices to your account, so that you have backup options.
I use this approach with Yubico Authenticator, which stores its data on Yubikeys, so I have all 2FAs on at least two keys even with TOTP-only services that seemingly allow only one authenticator per account, e.g., AWS.
Of course it's the user's responsibility to actually keep backup codes somewhere where they can definitely be accessed in case the phone is lost and also can't be stolen easily. Ditto for a app backup. Sounds straightforward, but easier said than done.
I have a _separate_ KeePassXC database where I store the original OTP secret (if you click "add manually" or "can't scan", etc when the QR code pops up... it will give you the secret that's in the QR code) and recovery codes.
If I ever lose my phone/yubikey/etc, I can go unlock my "break glass in case of emergency" database and access accounts directly or recover from there.
I keep this in a separate database versus, say, just putting the password + OTP secret + recovery codes all in the same Bitwarden vault because I want to maintain the full security of the second factor. If my e-mail and password for Bitwarden is enough to get you the username/password/otp then I figure it's really only protecting against credential stuffing.
Other 2FA apps have backup options like Google Authenticator or Microsoft Authenticator. Bitwarden, if you pay for premium, gives 2FA as a feature and they just handle those codes. Just don't register Bitwarden 2FA under itself :D
Also realize you can use more than one 2fa device. At the step where it asks you to scan a QR code, you can scan it on multiple devices.
Also, you don't need to use a phone to store your codes. 1password can do this for you, and then your codes are available anywhere you are logged into 1pw.
The google authenticator app allows you to transfer your codes to another phone, but you need to remember to do that before wiping your old phone.
When I transfer phones, all that stuff comes with me.
For worst case scenarios, I have a few spare YubiKeys setup that I can use in the event that something goes haywire. And in a safe deposit box, I have a YubiKey and a printed out copy of my 1Password emergency kit. So that if someone drives into my house and it burns down, I do have an option.
But I agree that this is a lot of stuff to keep track of. That’s why I’m glad that Passkeys are being adopted by the big players (Apple, Microsoft, Google) and that we’ll see consumer rollout of this sort of thing, which should make this a lot better.
There’s no such thing as a system without a threat model — and biometrics can be imperfect, but I’m much more comfortable with that or even relying on my current MFA setup than I would be using SMS 2FA or no 2FA!
I had a similar question and wrote up how I'm doing it here:
https://earthly.dev/blog/multi-factor-auth
Oathtool:
TOTP has some limitations which make it not as secure as the better hardware-based approaches. For example if you get fooled into trying to login to a phishing site and the real site uses TOPT, all the phishing site has to do as ask you for the TOTP code. TOTP in this case only protects you from getting phished if the phishing site is just logging credentials for use later use. If they are going to use your credential right away it is no protection.
If a site allows both TOTP and a hardware-based system though you can use the hardware-based system normally, and only resort to TOTP if the hardware is lost or broken, and stop using TOTP as soon as you can get replacement hardware enrolled.
For TOTP when you are setting up and the site gives you the QR code, scan that in TOTP apps on your phone and if you have one on your tablet. Also save a copy of the QR code somewhere safe. I save an encrypted copy on my desktop computer. If you ever change phones or tablets, you can scan the QR code again.
Some sites will also give you the TOTP key in text form. Save that somewhere safe and you can use it with command line TOTP tools such as oathtool [1].
This is exactly what we did for PyPI: we allow the user to enroll as many 2FA factors as they'd like, of both supported types (TOTP and WebAuthn).
The post is dated 2019, but the summary of practices we wrote here[1] is still relevant (and IMO, correct).
[1]: https://blog.trailofbits.com/2019/06/20/getting-2fa-right-in...
You can backup it to other phone or even print it and lock it somewhere if you want.
I got worried when I started thinking about this scenario, and realized Google Authenticator offers no way to back up the tokens. The only way out is to transfer to a new device using a QR code. They pretty much lock you in to using Google Authenticator.
And, crucially, backing up the phone DOESN'T SAVE THE TOKENS.
I almost learned this the hard way when I got a new phone, restored from backup, and right before I wiped my old phone I decided on a lark to check that Google Authenticator was working on the new one. The app was there, but the tokens were not.
I know you're very gung ho on the idea of curation, but let me be blunt. Nobody is going to do it. Debian has on the order of 97k packages with 990 volunteer members curating them. RubyGems has 180k packages with 3 volunteers. Really it's 2 volunteers.
So unless you know of 987 volunteers champing at the bit to review 180k packages from scratch, it's just not going to happen. And let's not even start on PyPI (340k packages) or npm (2 million packages).
I just don't think there are enough people available and willing to what you want.
I would be happy to be proved wrong.
I don't think you understand what I want. I don't want to see all of the packages in these repositories added to Linux distributions. I want to see the packages that you need added to these distros.
So if I need a package, and it's not in the curated repo, what do I do?
And no, I don't want to maintain the curated version myself. The whole point of using someone else's software was to save time and effort.
But please prove me wrong by finding thousands of people aching to curate tens of thousands of packages that are already widely available through well-known central repositories.
If we add a lot of curation, you will end up with a lot of gems being forced out of rubygems. This will make people become used to sourcing gems from alternative locations, and you will lose even the most basic of protection you get from what rubygems is doing.
You, or anyone else, is welcome to create their own, curated and vetted, gem repository. It is not technically difficult to source gems from places other than rubygems, so if there was a demand, developers could use your curated service.
In any case, people who need a package should add it to their distributions. This is what we should normalize. Especially for users like developers who depend on software libraries, who already have the necessary skillset and motivation.
You can see it's version 1.1p1, which was a very old version. Here's 1.6 on PyPI - https://pypi.org/project/chemfp/ .
When new releases came out - free software under the MIT license, available at no cost - I sent an email to the maintainers to let them know.
I never got a response. It was never updated.
Is my code useful? I think it's useful .. for the small niche I'm in. People do pay me for it.
And there are a lot of niche packages.
FWIW, I later switched to a commercial free software business model, where customers paid me for access to the source under the MIT license. More specifically, "we encourage people who redistribute free software to charge as much as they wish or can ... you might as well charge a substantial fee and make some money." https://www.gnu.org/philosophy/selling.en.html
I realize that I could maintain Debian packages myself. But while it's "not particularly difficult", it's still more than I want to do. FWIW, based on my download logs for July-to-date, I should start with Ubuntu:
2 Amazon Linux
2 CentOS Linux
3 Pop!_OS
5 Linux Mint
6 Raspbian GNU/Linux
12 Gentoo
19 Debian GNU/Linux
114 Ubuntu
https://drewdevault.com/2021/09/27/Let-distros-do-their-job....
I think you omitted the important qualifier "as long as there's someone willing to maintain the package."
As I tried to demonstrate, there weren't enough people using my package on Debian to maintain it. I believe it's useful, so 1) why not, and 2) what should happen next?
In that case, I expect most people will download and install the wheel/tarball from me. I distribute the most recent versions of chemfp from my own web site, not via PyPI. I have a URL structure following the Python Simple Repository API, which lets people 'pip install' it directly. This certain seems easier for any of my users than going through the extra steps of packaging it for Debian first, such that I don't see why they would do the extra work.
(Or, with the source distribution, avoid pip and untar/cd/python setup.py install.)
To be clear, it's not like you're wrong. Indeed, many people in my space use conda, a software distribution system which supports Linux, macOS and MS Windows, and allows multiple environments each with different sets of versions and dependencies. And conda supports channels, which allow oversight and review, eg, see Bioconda, at https://bioconda.github.io/contributor/index.html .
I've been trying to understand what "Linux-style distribution" means.
I think you mean third-party vetted package distribution, yes? Because otherwise "Linux-style" seems to cover a lot of variations, from Debian-style ones requiring a long-time vetting process to become a Debian Developer, to Bioconda (and nixpkgs?) where the vetting process seems easier - perhaps because Microsoft/GitHub help with the vetting?
If so, wouldn't that "vetted software distribution" be a more clear phrase?
(FWIW, my first package manager was 'inst' on IRIX, which could be used to install non-SGI contributed packages, so I think that's also a "Linux-style distribution", yes? Even though Linux didn't exist at that point.)
But even then, these don't solve the problem of what to do if there isn't someone willing to maintain the package or worse, decides that package X shouldn't be supported/updated even though others find it useful.
While unvetted systems don't have that gatekeeper problem.
What's important is not if you think it's useful, but if Debian users think that it's useful. I can empathize with wanting to feel like your software is important, but it's important to set aside my ego when I consider this. It's the user's place to decide, not mine.
Balancing this, I think that we should have more users working to package the software they need in their distributions of choice. It's not particularly difficult. This is a cultural idea that we should foster and encourage.
You should encourage this behavior from your users as well, as it's in your best interests, too. The small efforts of distribution maintainers scales up to benefits for many users of that distribution. Rather than encouraging people to download your tarball or PyPI release, encourage them to install it from their distribution, or to step up and maintain a package if it's not already present.
To clear up the terminology a bit, I am referring to any system where the distribution of the software is maintained independently of the maintenance of the software itself. This applies to Linux distros, BSDs, pkgsrc, nixpkgs, etc. I collectively refer to these systems as "software distributions", but I agree that there's not a better established term for this approach.
Wrote about it some here:
https://drewdevault.com/2021/09/27/Let-distros-do-their-job....
Which is why I pointed out earlier that I had 19 "Debian GNU/Linux" downloads in the last 6 weeks.
I assume they downloaded it because they thought it was useful.
On average, how many Debian users need to find a package interesting before it's added to a Debian distribution? I'm pretty sure it isn't usually "one".
> Rather than encouraging people to download your tarball or PyPI release, encourage them to install it from their distribution, or to step up and maintain a package if it's not already present.
My primary users - whose companies pay me money to develop this software - are computational chemists working in biotech and pharmaceutical companies. As a general rule, pharmas do not distribute software outside of their own company. Doing so, beyond the level of simple patches, may require legal review.
Furthermore, my users often have little say over their employer's choice of Linux distribution, nor little desire to become involved with distro maintenance. It's not their job, it does not help their career, and they are mostly not interested in distro or software packaging issues.
While it is my job - they are literally paying me - to make it easy for them to do their job.
(Also, their desktop distribution might be different than the compute cluster distribution, so they may need to support several distributions.)
I did say this is a niche field.
Furthermore, at least some of my customers have PyPI mirrors in-house, eg, using jFrog. Which they need because they have in-house packages which are not public, but need to be deployable on other in-house machines.
They add my package to jFrog and it's available everywhere.
Effectively, they have their own software distribution already, and find no clear advantage to also uploading to another software distribution. They certainly don't need to convince a (volunteer) Debian Developer to do it when they can simply upload it locally themselves.
Plus, having their own software distribution also solves the problem of how to support macOS and MS Windows.
And there is no risk of confusion where an in-house package is uploaded to a public server by accident.
Lastly, these people love having a single requirements file which installs their Python dependencies no matter which OS they are on (macOS, a Linux flavor, etc.) They seem to be moving to poetry for that, as it handles version isolation better than virtualenv + pip.
OS-specific packaging system like Debian won't work, nor do traditional Linux-style distributions, which are mostly concerned with having a system-wide valid/consistent installation, rather than the mix-and-match of different versions that Nix and Conda allow.
Nor does Python's requirements file let you say "if on a Debian machine, install ABC, if on RHEL install DEF, if on nix/macOS install GHI, if on ..."
> any system where the distribution of the software is maintained independently of the maintenance of the software itself. ... Wrote about it some here:
Yes, you pointed me to that URL earlier. I read it closely and have been using your terminology in my response. My "vetted software distribution" was meant as suggested refinement of your term, because in it you mentioned it needed to be curated by the third-party in question. (That would seem to include the Apple App Store, but exclude using yum on RHEL to install packages created by RedHat.)
Note that it does not mention "encourage [your users] to install it from their distribution", only "Ship your software as a simple tarball".
Earlier I pointed out how Stallman encourages free software developers to "sell free software", something which I tried doing.
In your model, how am I supposed to do that? They send me a PO, I send them the tarball, then tell them "oh, no, don't install it. Instead, convince your OS vendor(s) to include it, and only then install it."? "Oh, and you might not get a reply?"
So, (among other things) no updates to the gem on Rubygems unless or until they do.
Probably obvious to the majority of you, but it threw me for a loop.
Not singling out Ruby here; I'm sure many other package registries are similarly lax.