On Windows's are not trimmed from authentication tokens during publish.

[Eh2406]

Problem

On Windows authentication tokens that end and a new line do not properly get stripped when running publish or yank commands (others not yet tested). The new line do get stripped on other OS's. Even more oddly, if the registry requires authentication the new line is stripped when retrieving index or crate files.

Steps

1. On windows, Configure authentication either with:

[registry]
global-credential-providers = ["cargo:token-from-stdout cmd /C echo test"]

This slightly convoluted setup is because the documentation for cargo:token-from-stdout explicitly documents that new-lines's are trimmed. https://doc.rust-lang.org/beta/cargo/reference/registry-authentication.html#cargotoken-from-stdout-command-args
but the problem can be more easily reproduced with the simple:

[registry]
token = "test\n"

2. Attempt a cargo publish:

>cargo publish --allow-dirty
    Updating crates.io index
warning: manifest has no description, license, license-file, documentation, homepage or repository.
See https://doc.rust-lang.org/cargo/reference/manifest.html#package-metadata for more info.
   Packaging example v404.0.0 (...)
   Verifying example v404.0.0 (...)
   Compiling example v404.0.0 (...)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.64s
    Packaged 4 files, 825.0B (655.0B compressed)
   Uploading example v404.0.0 (...)
error: failed to publish to registry at https://crates.io

Caused by:
  token contains invalid characters.
  Only printable ISO-8859-1 characters are allowed as it is sent in a HTTPS header.

or yank:

>cargo yank --version 4.0.4
    Updating crates.io index
        Yank example@4.0.4
error: failed to yank from the registry at https://crates.io

Caused by:
  token contains invalid characters.
  Only printable ISO-8859-1 characters are allowed as it is sent in a HTTPS header.

Observe the error (from curl) about the invalid character, instead of the expected 401 about the invalid token (from crates.io).

Possible Solution(s)

No response

Notes

No response

Version

Cargo 1.79.0

[arlosi]

This is a general problem affecting credential providers other than cargo:token. I can repro a similar issue on Linux with cargo:libsecret as the provider when running echo token | cargo login, then attempting to

I had intended to fix this at the same time as #13615. I'll prioritize getting this in soon.

@rustbot claim