# Feature Request: New option for file transfer to obtain credentials
**URL:** https://discourse.cmake.org/t/feature-request-new-option-for-file-transfer-to-obtain-credentials/908
**Category:** Development
**Created:** [April 1, 2020, 3:42pm UTC](https://discourse.cmake.org/t/feature-request-new-option-for-file-transfer-to-obtain-credentials/908 "2020-04-01T15:42:07Z")
**Posts on this page:** 5
**Page:** 1
### Author:  [@oryandunn](https://discourse.cmake.org/u/oryandunn)
#### Post date: [April 1, 2020, 3:42pm UTC](https://discourse.cmake.org/t/feature-request-new-option-for-file-transfer-to-obtain-credentials/908/1 "2020-04-01T15:42:07Z")
I’m currently using the file command to download dependencies from a server that does not allow anonymous access. On Jenkins, I was able to add credentials and access via environment variables to set them in the command. However, this is not desirable for end users to put credentials in plain text on their system, either in environment variables or a netrc file.
Desired behavior would be a new option for file [https://cmake.org/cmake/help/v3.17/command/file.html#transfer](https://cmake.org/cmake/help/v3.17/command/file.html#transfer) to prompt. On the command line, it would just prompt; via the gui, it would pop up a dialog requesting credentials.
---
### Author:  [@brad.king](https://discourse.cmake.org/u/brad.king)
#### Post date: [April 1, 2020, 5:23pm UTC](https://discourse.cmake.org/t/feature-request-new-option-for-file-transfer-to-obtain-credentials/908/2 "2020-04-01T17:23:44Z")
There are many contexts in which CMake can be running for which interaction is not available. For example, IDEs and scripts can run `cmake` with pipes not attached to a tty. CMake may also be re-run internally by the generated build system when `CMakeLists.txt` files change. There may not even be a terminal available in such cases. This is not something we can make well-defined.
---
### Author:  [@oryandunn](https://discourse.cmake.org/u/oryandunn)
#### Post date: [May 11, 2020, 7:42pm UTC](https://discourse.cmake.org/t/feature-request-new-option-for-file-transfer-to-obtain-credentials/908/3 "2020-05-11T19:42:50Z")
Ok, thanks for the reply.
How about adding support for the OS credential store? Each OS should have a keystore, and as an example, this Pyhon module has support for the native store on each OS. (I know this isn’t directly applicable, but just an example of what I was thinking could be done)
> **[keyring](https://pypi.org/project/keyring/)**
>
> Store and access your passwords safely.
Ideally, I’d like to store the credentials in the OS store, and just provide the name of the site or system, and have cmake pull the credentials from the store. This way, you can pull credentials from the system without having to have them saved in plain text on the system. This would bypass the need for a prompt.
---
### Author:  [@brad.king](https://discourse.cmake.org/u/brad.king)
#### Post date: [May 12, 2020, 11:40am UTC](https://discourse.cmake.org/t/feature-request-new-option-for-file-transfer-to-obtain-credentials/908/4 "2020-05-12T11:40:14Z")
Yes, I think using the OS credential store would be reasonable.
One problem is knowing _when_ credentials will be needed so we can look them up and hand them to curl. An explicit option may be needed for this.
Alternatively, I think curl does support the Windows credential store for some authentication schemes. One could ask upstream curl about the possibility of supporting OS credential stores in general.
---
### Author:  [@oryandunn](https://discourse.cmake.org/u/oryandunn)
#### Post date: [May 13, 2020, 3:53am UTC](https://discourse.cmake.org/t/feature-request-new-option-for-file-transfer-to-obtain-credentials/908/5 "2020-05-13T03:53:40Z")
I think it would be nice to have an option to specify to pull credentials from the OS store as part of a download request, instead of USERPWD or NETRC. However, it would also be nice if it were it’s own command, such that credentials pulled from the store could be used with any function or external command that requires credentials.