If pypirc has an invalid format, twine leaks its contents to stdout

[WhyNotHugo]

Is there an existing issue for this?

• I have searched the existing issues (open and closed), and could not find an existing issue

What keywords did you use to search existing issues?

pypirc
credential
leak
stdout
invalid config

(sorry, I didn't keep a record of all the other combinations that I tried)

What operating system are you using?

Linux

If you selected 'Other', describe your Operating System here

No response

What version of Python are you running?

Python 3.12.9

How did you install twine? Did you use your operating system's package manager or pip or something else?

apk add twine

What version of twine do you have installed (include the complete output)

twine version 6.0.1 (keyring: 24.3.1, pkginfo: 1.10.0, requests: 2.32.3, requests-toolbelt: 1.0.0, urllib3: 1.26.20)

Which package repository are you using?

pypi

Please describe the issue that you are experiencing

Due to a misconfiguration, my pipeline had an invalid .pypirc format.

When twine attempted to use it, it printed out the contents of this file (which holds the secret token to upload to PyPI) to stdout, which ended up in public logs:

+ twine upload --non-interactive dist/django_renderpdf-5.0.0-py3-none-any.whl dist/django_renderpdf-5.0.0.tar.gz
Traceback (most recent call last):
  File "/usr/bin/twine", line 8, in <module>
    sys.exit(main())
             ^^^^^^
  File "/usr/lib/python3.12/site-packages/twine/__main__.py", line 33, in main
    error = cli.dispatch(sys.argv[1:])
            ^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.12/site-packages/twine/cli.py", line 129, in dispatch
    return main(args.args)
           ^^^^^^^^^^^^^^^
  File "/usr/lib/python3.12/site-packages/twine/commands/upload.py", line 255, in main
    upload_settings = settings.Settings.from_argparse(parsed_args)
                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.12/site-packages/twine/settings.py", line 288, in from_argparse
    return cls(**settings)
           ^^^^^^^^^^^^^^^
  File "/usr/lib/python3.12/site-packages/twine/settings.py", line 116, in __init__
    self._handle_repository_options(
  File "/usr/lib/python3.12/site-packages/twine/settings.py", line 304, in _handle_repository_options
    self.repository_config = utils.get_repository_from_config(
                             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.12/site-packages/twine/utils.py", line 150, in get_repository_from_config
    config = get_config(config_file)[repository]
             ^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.12/site-packages/twine/utils.py", line 62, in get_config
    parser.read_file(f)
  File "/usr/lib/python3.12/configparser.py", line 705, in read_file
    self._read(f, source)
  File "/usr/lib/python3.12/configparser.py", line 1064, in _read
    raise MissingSectionHeaderError(fpname, lineno, line)
configparser.MissingSectionHeaderError: File contains no section headers.
file: '/home/build/.pypirc', line: 1
'pypi-AgEIcHlwaS5vcmcCJDEyNzg5MjUzLWNmYjQtNDc3Yy1hODYxLTJlNTcwM2NhNmQ3ZQACGFsxLFsiZGphbmdvLXJlbmRlcnBkZiJdXQACLFsyLFsiMTdmZTQzNjQtY2VhYS00MjYzLWFjYjItZmVlZTk3ZjdlMDRiIl1dAAAGIFMg3ntKRW4jPRWG7ETRUEZBam1khFyS8Cbtj0h98cwd\n'

(the above token was quickly revoked)

Please list the steps required to reproduce this behaviour

1. Create a typo in .pypirc
2. twine upload --non-interactive path/to/some/package

Anything else you'd like to mention?

A file containing sensitive credentials should never be printed to stdout; twine is frequently used in CI pipelines where logs are kept public.

[woodruffw]

Hi @WhyNotHugo, thanks for opening an issue. I agree this is not ideal behavior and should probably be fixed (either by masking the secret in the exception, or perhaps better by catching the exception and controlling its presentation more completely). I can look into a patch this week.

To take a step back: could you share a bit about your pipeline configuration? In particular, if you're using GitHub Actions or GitLab CI/CD, is there a reason why you're using a .pypirc instead of the CI-provided secret management system? The latter is designed to automatically mask these kinds of secrets.

[woodruffw]

@WhyNotHugo gentle ping on the question above!

[woodruffw]

I've opened #1240 for this, and confirmed that the fix in that PR masks as expected.

[WhyNotHugo]

Hi! Sorry, I apparently wrote a reply and never hit submit, here goes:

---

To take a step back: could you share a bit about your pipeline configuration?

I have the secret file .pypirc configured for the builds, but I accidentally wrote the file in the wrong format, so it's syntax was completely invalid.

In particular, if you're using GitHub Actions or GitLab CI/CD, is there a reason why you're using a .pypirc instead of the CI-provided secret management system?

I'm using the builds.sr.ht. .pypirc is configured and created via the secrets management system.

The latter is designed to automatically mask these kinds of secrets.

This particular setup doesn't use heuristics to try and detect/censor leaked secrets.

Note that the data in the exception details is escaped (i.e.: is has \n instead of an actual new-line), so such heuristics would likely not have matched anyway.

[woodruffw]

No problem at all, thanks for the additional details! Interesting to know srht does secret management that way.