RubyGems 3.3.19 carries MFA warnings through sign-in
RubyGems now displays a server-supplied MFA warning during sign-in. A separate setup fix keeps staged Bundler metadata changes inside the requested destination directory.
A registry can decide that an account needs stronger authentication while an older client fails to display the recommendation. RubyGems 3.3.19 closes that communication gap during gem signin. The client already fetched account information for MFA handling. It now preserves the profile response long enough to display a warning supplied by the server.
The July 28 release announcement includes that change, Bundler 2.3.19 as a default gem and a setup correction involving --destdir. These changes concern different boundaries. One carries account-policy information into an interactive command. The other prevents a staged installation from modifying metadata in the host's ordinary RubyGems installation.
I find Ruby's direct style useful in command-line tooling. A command still needs to show the information that affects its user's next action. Authentication policy communicated only through a website can be missed by a maintainer whose normal interaction is the package client.
The profile response contains more than an MFA level
Pull request 5590 changes the sign-in flow to retrieve a user profile instead of extracting only the MFA level. The profile is used to determine the relevant MFA parameters, and a warning field is displayed when present.
This keeps the policy message on the server side. The client does not need to encode a particular download threshold or a permanent copy of the warning's prose. It displays the profile's supplied warning as part of sign-in. That division lets the registry decide what applies to the account while the client makes the decision visible.
The refactoring retains the existing question about enabling MFA for the new key when the profile's level is UI-only or UI-and-sign-in. Account authentication and protection of an individual key remain distinguishable in that interaction. Retrieving the full profile supports the warning without removing that credential-specific choice.
The patch retains special handling for the default host. Its profile retrieval returns an empty result for other hosts, preserving a path for compatible gem servers that do not supply the RubyGems.org profile endpoint. The added behaviour therefore does not assume that every server implementing gem publication also implements the same account-policy API.
The regression test supplies an MFA-disabled profile containing a warning, executes sign-in through a mocked interaction and asserts that the warning appears in output. That checks a concrete user-visible result. A test of profile parsing alone would not establish that the maintainer actually sees the message.
A warning is distinct from rejecting a request
The June MFA rollout announcement provides the policy context. It starts recommendations for owners above 165 million gem downloads and schedules a requirement above 180 million for August 15. July's client enhancement makes warning delivery part of an ordinary sign-in workflow before that scheduled enforcement date.
Displaying a warning does not itself enable MFA. It also does not establish that a request has failed. The patch adds output based on a field in the profile, while the account's authentication state and the server's policy remain separate facts.
That distinction matters when reading command output. A maintainer can receive a recommendation during a successful interaction. Treating every security-related message as an error would obscure the purpose of the warning phase, which is to communicate an upcoming requirement before it blocks work.
Staging must include metadata cleanup
Pull request 5737 repairs a different problem. Its explanation says that ruby setup.rb --destdir /foo could remove previous default Bundler specifications from the default installation outside the destination directory. The setup operation staged new files but allowed cleanup to act on host metadata.
The correction checks whether the effective destination matches the ordinary default gem directory before removing the existing default specification. Otherwise it creates the specification directory under the selected destination and writes the new specification there. Choosing a staging destination now affects the cleanup decision as well as the new output path.
The regression assertions cover both locations. They require the previous specification to remain in the host default directory, with no new specification added there. Under the staging destination, they require the new specification and the absence of the old one. That verifies the intended separation by checking what stays outside the destination as well as what appears inside it.
I consider that a useful packaging test pattern. Checking only that the expected staged files exist would miss an unwanted deletion elsewhere. The patch's assertions establish that the setup operation preserves host metadata while constructing the staged result.
The release therefore repairs two specific mismatches between intent and observable behaviour. Sign-in now exposes the registry warning already associated with an account. Staged setup now keeps default Bundler metadata changes in the selected destination, including the removal decisions that previously escaped it.