"401 - Bad credentials" for a deploy entry generated by `travis setup releases`

Hope you can help solve it
When I use travis setup releases to generate the deploy api_key like this

   deploy:   
   provider: releases
  api_key:    
      secure: aSaEvrpwgeH9AObclfv....

It’s OK and deploy successfully. When I copy the secure value into Travis-CI environment variables like this:

and use the api_key like this:

    deploy:
  provider: releases
  api_key:
    secure: $TOKEN
  file: "./GCanvas/core/test/linux/build/result.txt"
  on:
    repo: luckzhiwei/GCanvas
    branch: master
    tags: true

When I change the setting below, the deploy stage throw error "GET https://api.github.com/user: 401 - Bad credentials ". I’m confused about it. Is it that I can’t use environment variables to set api_key of deploy

The value you set in the settings page should not be encrypted.

1 Like

thank you. I will try to solve it as you say

Thus, I understand that:

  • either, you put an awful long encrypted key in your .travis.yml
  • or, you put an unencrypted key in a travis environment variable, so that if any developer of the GitHub project can add in .travis.yml something like:
    echo "${API_TOKEN:0:1}%POISON%${API_TOKEN:1}"
    he can get your private API_TOKEN secret by reading travis logs (even if your variable is not set as “DISPLAY VALUE IN BUILD LOG” since this hack disrupts the usual [secure] replacement in logs)

Reminder: since GitHub API_TOKEN are not restricted by repository, that “bad guy” can do anything with all your repositories (write access and read access to your private repo).

Your explanations are really clear. Sorry to intervene in this discussion but I have tried the two proposed approches (encrypted token and environment variable with unencrypted token) on a repository of mine and none worked, I still have the “401 - Bad credentials” error (the other parts of the build went good). The log is here. I even tried to give more permissions than just public_repo that was automatically set for the GitHub token created by running travis setup releases. Any idea of what I could have done wrongly?

To use an envvar for api_key:, write smth like this:

#<set up a secret envvar GITHUB_TOKEN in any of supported ways>
<...>
deploy:
  - <...>
    api_key: $GITHUB_TOKEN

This way is not shown in https://docs.travis-ci.com/user/deployment/releases/ but is shown at e.g. https://docs.travis-ci.com/user/deployment/pages/. They are interchangeable.

Introducing an envvar for a one-time-used value like an API key is typically unnecessary compilcation.

Thanks for the advice. I also tried (unsuccessfully) to use:

  api_key:
    secure: $GITHUB_TOKEN

but with the secure: keyword (and perhaps this was wrong and I may try without this keyword) and environment variable GITHUB_TOKEN set in my Travis-CI settings. I also tried, as suggested in the doc. you have pointed, to just use:

  github_token: $GITHUB_TOKEN

which also failed.

The current deploy: section is:

deploy:
  provider: releases
  api_key:
    secure: idp6GpXN1rHR4xl8Alh/3XCbshSoDtbWXoIahyOW0zUTMukSakAAebGnaxFk8yq4UWTs/8VB4JXt01KGIluITwMOCMm+3huIpHFGicqGB7V0MwHJiRiebHj0tUriNb0hQxG2Qa7hFwToQQeoG15297FD3WiIm1Vvm8wDRagAJ1yqOQc3LM8vez0MvyaTac8YxBryuhQXILUgp39+2MBYAoK+uL1qmsaCe4Ey/j8RKOnR/vdwMdmklLvhZ4xPx2mIdvdst1do5mZBT1ZlIS+i0q6JsBQAVOORGgPwlAFcjbEfa6GtYs75HRTRz7wGIH59TrmUe8JFb0oMe03Oo1DELmbpA6o96aMLm0SQ33CMfyishBmgAhtUjZTQnChgHVTrzaJR5wQ8+eLCiihTqRANz3HiUKNyiLITLNnd3EOPeQ3CgYzy0kjVExN3eIsWVh+41tugz3cslZDbJ5aVAsMquJt/CSkFUX0zIHc4y+hBPW6Oi0/gvX/n4JawEaD9EviYHatDWl4o2Y+41mOeQgm6n1/fdUAA+koSvKwrL19coHHgNJRYDgmdVMXRZcSiKVswMUaJcQci2ByH1BGExH+a7vUe0Now7PVQpElbtjgl1+LkcnydVHlTOsj0A8slio1UXAc+uJO5LKZvekKYa74SmM+R3Pv053OqwJtZGnWbvKc=
  file: products/*
  on:
    repo: emmt/OptimPackBuilder
  skip_cleanup: true

and was generated by travis setup releases.

The need to use the --pro option also applies to all other CLI commands that talk to your Travis project entry (which includes all commands that deal with encryption), including travis setup releases.

It worked with the --pro tag. Many thanks for your explanations!