Describe the bug

When using gh secret set with the --env-file flag on a Windows machine, secrets are parsed and uploaded with a trailing carriage return character (\r or \r\n). This causes the secrets to have an unintended newline character when injected into GitHub Actions workflows, which can break authentication, API calls, or configuration strings that expect a clean, single-line value.

Affected version

gh version 2.92.0 (2026-04-28)
https://github.com/cli/cli/releases/tag/v2.92.0

Steps to reproduce the behavior

1. On a Windows machine, create a standard environment file named secrets.env using standard Windows line endings (CRLF):

MY_SECRET=my_secure_value
ANOTHER_SECRET=another_value

2. Run the command to set the secrets for a repository:

gh secret set --repo OWNER/REPO --env-file secrets.env

3. In a GitHub Actions workflow inside OWNER/REPO, print the length of the secret or pipe it to a file to inspect its hex/binary representation (e.g., echo -n "${{ secrets.MY_SECRET }}" | xxd).
4. See that the value contains a trailing \r (0x0d) character.

Expected vs actual behavior

Expected behavior:

The gh CLI should strip trailing \r or \n characters from secret values when parsing .env files on Windows, ensuring only the raw string value is uploaded.

Actual behavior:

The CLI splits lines by \n but fails to strip the \r from CRLF endings. As a result, the trailing carriage return is treated as part of the secret value itself.