When Michael put together the first cut of the Scratch Org tooling, this included the credentials for the package and community orgs, in encrypted files, for use in the scripts.
This is an issue for multiple reasons:
# Plaintext credentials do not belong in repositories
# While they are encrypted, the means for decrypting are in plain text in the repo, making it trivial to decrypt the credentials once access is gained to the repo
# -~When credentials expire, updating them involves publishing a new update to the tooling repo, which is extremely inconvenient, requiring not only the work of updating, but also any devs will need to update their copy of the repo~-
A proper solution that still has the flaw of having creds easily retrievable from a users system (but uses a relatively common .env file pattern) would involve:
# Create a .env file in the user’s directory (and also ensure the .env is gitignored in the main repo)
# When running commands, if creds are needed, retrieve them from .env. If they are not present, prompt the user for them, and store them in .env
## This could involve stripping out the system entirely, or potentially just having the decryption key as a .env var
A highly paranoid solution would require the user to input credentials every time they’re required.
Some of the inconvenience this introduces could be mitigated in a few ways:
# Currently the scripts use creds supplied by themselves. Instead, the script could prompt the user to supply the appropriate creds, store them in standard {{sfdx}} using a known alias, and then simply refer to that alias
# Any time we need to prompt - have the tooling tell the user exactly what to look for in 1password
# If we catch any errors, suggest to the user they may need to check if their creds are up-to-date (though see (1) above - sfdx may itself take care of giving the user a useful error message here)
Note that this is mostly a collection of thoughts at this stage, this needs to be considered further before making any changes.
In particular, it’s worth noting that any changes made along the above lines might affect the ability to set up CI using this procedure - [http://www.crmscience.com/single-post/2018/01/22/Salesforce-Logins-for-Continuous-Integration-and-Delivery|http://www.crmscience.com/single-post/2018/01/22/Salesforce-Logins-for-Continuous-Integration-and-Delivery].