You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have verified this is the correct repository for opening this issue.
I have verified no other issues exist related to my request.
Is Your Feature Request Related To A Problem? Please describe.
Currently, on non-Windows platforms, Chocolatey CLI runs on Mono and uses Mono's ProtectedData implementation to obfuscate saved passwords and remembered arguments.
If Chocolatey moves to being build on dotnet, Mono will no longer be used, as dotnet will be the underlying runtime. So then any upgraded installations of Chocolatey CLI on non-Windows platforms will have two issues:
ProtectedData is not available on non-Windows platforms in dotnet, so an alternative would need to be determined.
Any obfuscated data on disk would no longer be able to be decrypted, as the Mono implementation would no longer be available.
Due to the second problem, migrating away from the Mono ProtectedData implementation soon would be ideal.
Describe The Solution. Why is it needed?
There are a number of potential solutions I can think of. All of these would be for non-Windows only, as Windows installs would be able to continue to use ProtectedData without interuption.
Don't do any obfuscation at all, just save things as plain text.
Do some obfuscation, e.g. OR-ing data with a known pattern, converting to base64, other simple obfuscation techniques.
Encrypt with a static key that is shipped/embedded into Chocolatey CLI
Use a generated encryption key, and save the key somewhere (maybe next to the chocolatey.config file?).
Use platform-specific key management systems (keychain on Mac, a bunch of different potential options on Linux
I don't think that using platform specific key management would be a good idea in terms of the complexity it would entail. I also don't think that having strings as plain text would be ideal either, as then things like a grep search could immediately show source passwords.
Doing some obfuscation, or using a static key embedded into Chocolatey would be better, but this would mean that if the file was copied to another machine, it could still be decrypted (e.g. if someone pastes their chocolatey.config into a gist, or backs it individually).
So using a generated encryption key seems like the best option, and it provides a very similar level of protection/obfuscation to the current implementation. Since the Mono machine level keys are generally globally readable from what I understand, anyone with access to the machine or the file system can decrypt ProtectedData blobs from that machine. The one disadvantage I can think of is that it means if the Chocolatey install folder is copied to another machine, the values would still be able to be decrypted. But otherwise, this seems like a good option.
And if people don't want source passwords saved in the config file, they can always pass it in at runtime with --password
Checklist
Is Your Feature Request Related To A Problem? Please describe.
Currently, on non-Windows platforms, Chocolatey CLI runs on Mono and uses Mono's
ProtectedData
implementation to obfuscate saved passwords and remembered arguments.If Chocolatey moves to being build on dotnet, Mono will no longer be used, as dotnet will be the underlying runtime. So then any upgraded installations of Chocolatey CLI on non-Windows platforms will have two issues:
ProtectedData
is not available on non-Windows platforms in dotnet, so an alternative would need to be determined.Due to the second problem, migrating away from the Mono
ProtectedData
implementation soon would be ideal.Describe The Solution. Why is it needed?
There are a number of potential solutions I can think of. All of these would be for non-Windows only, as Windows installs would be able to continue to use
ProtectedData
without interuption.chocolatey.config
file?).I don't think that using platform specific key management would be a good idea in terms of the complexity it would entail. I also don't think that having strings as plain text would be ideal either, as then things like a grep search could immediately show source passwords.
Doing some obfuscation, or using a static key embedded into Chocolatey would be better, but this would mean that if the file was copied to another machine, it could still be decrypted (e.g. if someone pastes their
chocolatey.config
into a gist, or backs it individually).So using a generated encryption key seems like the best option, and it provides a very similar level of protection/obfuscation to the current implementation. Since the Mono machine level keys are generally globally readable from what I understand, anyone with access to the machine or the file system can decrypt
ProtectedData
blobs from that machine. The one disadvantage I can think of is that it means if the Chocolatey install folder is copied to another machine, the values would still be able to be decrypted. But otherwise, this seems like a good option.And if people don't want source passwords saved in the config file, they can always pass it in at runtime with
--password
Additional Context
No response
Related Issues
The text was updated successfully, but these errors were encountered: