DRONE_NETRC_USERNAME documentation/usage

Hi everyone,

Just a question about the DRONE_NETRC_USERNAME variable: at least on private repos (and on Drone 0.8.5), Drone injects this environment variable with the repository clone credentials - for github this is an user access token. However, it’s not documented anywhere (and never has been, I believe), so sometimes I wonder if it’s something plugins can/should rely on.

So, these are my questions:

  1. Should this be documented somewhere? (I would gladly contribute with documentation, if required)

  2. Is it recommended to use it in plugins? I’ve never seem it used, but I’ve started using it in some internal plugins for my company’s private repos (for example, a plugin to create github tags or releases). This way I don’t have to manually set a github token secret in each repo and just use the clone credentials.

  3. Is it still present on Drone 1.0 and if so, can we expect it to remain in use on Drone 1 for backwards compatibility?

the netrc username/password is considered an internal implementation detail and could change in future releases, so I would not recommend using this. Here are some things that I envision changing in the future:

  1. drone creates and mounts netrc file instead of passing environment variables
  2. drone only provides the netrc to the clone step
  3. drone replaces netrc with git credential store
  4. drone adopts github applications, which restricts token scope significantly

Any of the above changes would impact a pipeline that depends on the netrc variable. I hope that helps you plan going forward :slightly_smiling_face:

1 Like

Hi @bradrydzewski

the file .netrc contains very sensitive info like the password.
so, developers can cat it in its own step. and the password is leaked.

so, the restrictions are very necessary I think.

Do you have any progress on this? or plan? or other solutions?
We are using the drone in the company, and we can contribute to this if it is needed.

thanks.

yes, you can now limit the netrc credentials to the clone step, which prevents them from being intercepted by user-defined pipeline steps.

thanks, this helped.