This is fantastic work by the RubyGems maintainers!
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.
If anyone is looking to do some open source contributions on a mature, production Ruby on Rails site, I highly recommend contributing to the rubygems.org project. The code is extremely clean and the project is very, very well run.
Good news for the Ruby ecosystem, but I'd also like to get a handle on exactly how many of the most popular gems have "over 180 million total downloads".
Approximately 100 gems, representing about a third of downloads.
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.
Were download rankings combined with one-way "membership" considered? (One-way "membership": once a gem/user qualifies based on recent downloads, they're permanently required in perpetuity.)
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.
Remember that 'downloads' is only half the metric that matters... Really 'users' is what matters, but a single download could lead to the code being used by a large platform provider and that code handling the private data of 1 Billion users.
So, you really want every possible assurance that that code does what it says. And MFA is a good start for that.
Hell ya, I hope this becomes the new standard! Thank you so much to whoever pushed this, steps like this are going to pay dividends down the line as we bolster supply chain security in other ways.
I do hope that, eventually, it will be mandatory for all publishing.
Help me understand one thing. More and more services are moving towards 2FA/MFA. The 2nd factor is in a phone app. What happens if I lose my phone? Without my old phone I cannot log into the services. How do I get access to my accounts again? How do I move the 2FA setup to new phone again? Do I have to do this one by one for all 50 2FAed services I use?
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.
Many services seem to offer one-time codes for storage offline in case this happens. Authy can working across multiple devices, but that probably has some security ramifications. Based on https://apple.stackexchange.com/questions/305372/will-my-goo..., you are able to restore Google Authenticator from iCloud.
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.
I agree but how many people who have 2FA from Google for example have a printed out list of numbers? You can have multiple authentication devices but, again, how many people have this? And it's certainly very easy to be traveling and not have backups with you.
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.
> And it's certainly very easy to be traveling and not have backups with you.
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).
> 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.
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):
> 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.
> 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.
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.
Passkeys (the new thing from the FIDO Alliance that Apple, Google, and Microsoft all support) will help with this a lot.
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.
I would like to have the option of only needing the password and no password reset unless you visit an office somewhere in person. For like Google, banks, brokerages, etc. But maybe that is less secure than two-factor online systems? Seems like it wouldn't be.
It is, in fact, less secure than what we should have been doing for at least 5 years.
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.
Having to present physical, hard/expensive to reliably forge, government-issued ID at a reputable institution is a pretty good filter against most fraud. It's also a headache even if you live somewhere with a local branch of your bank.
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.
>> More and more services are moving towards 2FA/MFA. The 2nd factor is in a phone app. What happens if I lose my phone? Without my old phone I cannot log into the services. How do I get access to my accounts again? How do I move the 2FA setup to new phone again? Do I have to do this one by one for all 50 2FAed services I use?
> 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.
It's only a single factor if your password manager login is compromised. If you're instead the victim of a phishing attack or you somehow spill the password + an MFA token for a single service, then you still get some of the protections you would expect from MFA (e.g., the leaked login will be time-boxed and non-renewable).
To be honest, the most likely surface of attack for a user are database leaks. So long as your password manager is uncompromised, even if someone does manage to get ahold of your username/password for a specific site they won't get anywhere.
Note that TOTP is not limited to a single authenticator. You can, for example, scan the same TOTP setup QR code once with an app on your phone and again with a different app on your laptop (or scan in one and paste the code in the other).
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.
Other people have given a lot of options, but I'll throw my solution in the ring.
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.
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!
In most countries outside North America, if you don't pay the phone bill you can still receive texts and calls. You just can't make calls, send texts or use internet.
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.
In Germany at least you (can) buy a prepaid sim card and activate it. That gives you a phone number and you usually get the price you paid for the sim card added to your account balance. From then on you don't have to pay anything to keep using that phone number to receive calls/SMS. Calling/sending SMS costs are coming of your balance. You can buy packages (usually good for 4 weeks) with e.g. 300MB data volume or unlimited calls.
There's also the model where you pay a monthly subscription and receive a new device every few years or have some other benefits.
Yes, if I'm on a prepaid plan? If I didn't top up, my phone would still have an active SIM and phone number. I would still be able to receive calls and texts.
They're talking about being able to receive texts without having a phone plan. Also, the (now) norm of texts being free in the US with most phone plans is 1.) relatively recent and 2.) not the case everywhere else. (Hence, the popularity of Whatsapp etc. outside of the US--where it's uncommon for those who don't text internationally.
SMS is part of the service frame - every time your phone talks to the cell tower to go "here I am, I am IMEI 12345 and I have sim ABCDE!" there is a 160-character frame for it to send a SMS message, and every time the tower goes "hello IMEI 12345/SIM ABCDE, I see that you are in cell ZXCV!" to track your equipment's location, there is a 160-character frame for it to send a SMS message to your phone.
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.
But you don’t have a phone number. Who does the sender send the text to? How exactly this work in other countries where an inactive account can receive a text?
This is all very confusing because you're mixing up your definitions of what precisely is "inactive" here.
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.
The phone has a SIM card, and a phone number, as evidenced by the fact that he "did not pay it for a while" rather than never having had a plan. So the phone is active and can connect to the network and authenticate with a base station and attempt to make outgoing calls. Those attempts will be rejected by his phone provider.
Incoming texts will also be rejected and not delivered. In other countries (I know about Ireland, anyway) this isn't generally true.
Receiving messages is free, so as long as you have a prepaid card that hasn’t been deactivated (not using it for a year is usual with my provider) you can receive text messages without paying.
If I were on a prepaid plane, and I didn't top up, my phone would still have an active SIM and phone number. I would still be able to receive calls and texts.
It dated to mobile calls being expensive especially outside of a very bounded home area and being either a business expense or a relatively luxury thing. In that context, it didn't really make sense to hit a landline with a big charge for calling a mobile number--perhaps unwittingly. And that general thinking carried over to SMS.
As somebody else outside the US - where is this different? Without a connection you can only make emergency calls, receiving anything is impossible when your phone doesn't have a number without an active sim card.
Except they did have an active SIM on a prepaid plan, that hadn't been topped up. In a situation like that I would still be able to receive calls and texts, just not make them.
What country do you live in, and what's the process for being assigned a phone number that can receive text messages without paying anyone for a phone plan? Does the government have an office where you can show your ID and get a SIM card for free?
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.
Every service that I've seen that uses TOTP 2FA will also give you a list of fixed backup codes and strongly encourage you to keep them somewhere safe. There are also TOTP apps that will let you make a backup of your codes, to also be kept somewhere safe.
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.
Check out the Authy app. It lets you have an encrypted backup with which you can restore the MFA codes on another device. Another option is using a password manager with MFA capabilities, like 1Password.
I've used Google Authenticator, Authy, and 1Password. 1Password has been far superior in my experience, the only downside being that it is a paid subscription, which won't work for everyone. My 2nd choice would be Authy.
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.
I have 1password too but that seemed a little incestuous to have the password and the TOTP in the same app, it's not exactly MFA. I use Authy, personally, with backups and encryption.
I have the same 1Password / Authy setup, for the same reason. But I have my Authy password in 1Password, so it is kind of an illusion of extra security. I’m strongly considering moving it all into 1Password at this point.
Thankfully I can just about remember 2 passwords :)
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.
I use the OTP Auth iOS app. I store encrypted backups of my 2FA code secrets in iCloud, and also in Dropbox. I save recovery / backup codes in LastPass (whenever a service provides them.) When possible, I will set up two or more 2FA options. I always have a small Yubikey plugged in to my laptop, and some services allow me to set up a Yubikey as well as OTP codes. I also have a backup Yubikey that I set up for all the services that support it, and keep this off-site in a safe deposit box. I also store some printed copies of critical 2FA code recovery codes, mainly for my Google and Apple accounts.
What I'd like to see is for sites to allow setting up two different kinds of 2FA, one of which is TOTP and the other is something hardware-based.
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].
You got lots of answers about proactive approaches to the issue. In cases where you didn't do those, you'd contact support. If it's a bank account, they ask you security questions and then reset/remove MFA. I've done that over the phone while out of the country once. If they don't have support, or their support doesn't have an alternate authN approach, you could be locked out.
Your second factor could be whatever you want it to be. Phone app, keyfob, TOTP program running on your machine. Many services allow for multiple options.
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.
You type the seed in. Services almost unilaterally give you the option to get a seed code instead. Even if they don't, you can scan the QR code and get the seed out of it.
I use a password manager to store my credentials, TOTP codes and stored secondary codes. Yes, that does make my password manager more of a risk, but for that reason, I use a strong and unique password for the password manager, have a password manager that has its own security key that is required for access from new devices, etc.
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!
Services usually offer a tokens which should be saved somewhere in order to reset 2FA. I agree, requiring users to keep tokens for every service is painful (see how many people had trouble not losing their btc keys when btc wasn't particularly valuable)
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
I've tried putting an extra 2 months of payments on my phone plan so that if a payment doesn't go through service won't expire. Hopefully the automatic payments continue so I don't have to think about it
I recently migrated all of my 2FA logins to Raivo [0]. It's iOS-only but open source and very nicely built. The key feature that made me switch is that it can export the 2FA tokens as a backup.
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.
Apps like the Microsoft authenticator and freeotp+ allow you to backup your codes. With freeotp+, you can export the codes as a json file and import them in another phone in case something happens. With the Microsoft one, you save the codes in the cloud (your Microsoft account).
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 recently (few days ago) had to do 2. None of my gems are super popular but I have enough that there are some serious production workloads behind. It felt scrutinized enough. I can imagine if I had more popular libraries that it would have been much more so.
Most services should have a fallback. Often it is just emailing you a code, or texting a code to a phone number. This is because true, strict MFA would become a customer support nightmare - half your users would be locked out from day one.
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.
It’s a good question. A lot of 2FA apps have manual backup/restore functionality. Some have cloud sync (e.g. iCloud sync so your new iPhone has the same app and codes, or 1Password/Bitwarden which has you log back into the app on the new phone with their service login.) These 2FA syncs can be a point of weakness so not everyone uses them.
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.
As others are saying, you can store your TOTP code in a password manager, and if you lose you phone re-add it. You can also use something like oathtool do generate these one time passes at the command line.
I had a similar question and wrote up how I'm doing it here:
You probably get recovery codes you have to store somewhere.
Major 2fa code apps support migration between phones, and backing up the encrypted database to the cloud.
I use andOTP on Android and it has a backup feature that exports all your registered 2FAs into a file which you can import to another andOTP install. You can also export with a password on that file so it's encrypted.
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
Two-factor reset is usually a slow manual process where the service provider checks that you are who you really claim to be. It is not automated so that it cannot be abused.
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.
This is the only mitigation that distributions like RubyGems can use to curtail abuse without a major redesign, but it's far from enough. This is the wrong model for software distribution. We would be wise to look to Linux-style distributions as an alternative, where malware is essentially unheard of rather than a weekly occurrence.
There are many, many Linux distributions that are already maintained in this fashion. Most of them provide Ruby packages! And they already have strong cryptographic signatures for all packages -- which is much better than MFA.
Rubygems already has signatures. To a first approximation, nobody bothers.
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'll match your bluntness, then: suggesting that anything on the order of 2 million packages are actually useful is plainly ridiculous. Debian et al act as quality filters by only actually packaging the stuff anyone cares about or needs. A stronger argument along these lines lists the packages that you actually need which are missing. And once you have such a list -- add them to Debian! It's not particularly difficult.
I had code that was in Debian. https://tracker.debian.org/pkg/chemfp . Someone else added it, so I guess they thought it was useful. I know someone who used it too.
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
By comparison, it's even simpler to support all of these system via a pip-installable package.
This is a common error. In actuality, it's not your job to maintain your own software in Linux distributions. It's the job of users of each distribution to step up and maintain the software they need.
You earlier wrote "Debian et al act as quality filters by only actually packaging the stuff anyone cares about or needs."
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.
>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?
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.
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?"
And because Debian has such strict curation, a lot of software ends up being distributed via other channels, either from alternative deb package repos or not using a deb package at all.
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.
Debian's curation is not so strict as you suggest, and what's more: there are more distributions than just Debian. Add the packages you need and you'll be fine. I can speak from personal experience in this respect.
That’s my point. If you make it so people are required to go to other sources of packages for normal operations, then it normalizes untrusted distributors of packages.
I don't understand how your response follows from the points I made.
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.
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.
You add it. You are responsible for your dependencies. You should already be getting notified of new releases, reading changelogs, etc, and bumping the pkgver in some repository is not arduous on top of that. The labor, split among everyone who does this, is very managable.
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.
2nd paragraph, 2nd sentence: "Users in this category who do not have MFA enabled on the UI and API or UI and gem signin level will not be able to edit their profile on the web, perform privileged actions (i.e. push and yank gems, or add and remove gem owners), or sign in on the command line until they configure MFA."
So, (among other things) no updates to the gem on Rubygems unless or until they do.
Sure, but what happens after that when the gem developer asks for the gem to be removed from Rubygems? Or decides to leave an old, insecure version on Rubygems?
Then I expect it will be forked. It's open source, after all, and a lot of disputes about project direction and policy are settled by forking and each disputant going their own way.
You use an API token. We spent time making them more secure before rolling out the new MFA policy. We'd like to get to a point where OTP codes or OIDC tokens can be used automatically, but it will take a fair amount of work to do that.
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.
[1]: https://cocoapods.org/
[2]: https://rubygems.org/gems/cocoapods