choco
choco copied to clipboard
Show remembered arguments for packages
Like @ivanatpr posted here (#797), there should be a way to see wich arguments are remembered by choco.
Thanks for filing - we just need some way of having folks opt into this, some arguments could contain sensitive data and we need to ensure that is not exposed.
I understand. Nobody wants their "-P mySecretPassword" to be exposed via a simple command. 😄
I am not sure how you can solve this.
Maybe a second "remember-function".
Like:
choco install app1 -x86 -rememberPlain
choco install app1 -P mySecretPassword -rememberEncrypt
And an option to define with function should be default.
An option to encrypt or not encrypt seems a reasonable solution to me.
choco feature enable -n useRememberedArgumentsForUpgrades (Default=not encrypted) choco feature enable -n useRememberedArgumentsForUpgradesEncrypted
(That's already long to type!)
This would be necessary to do something like this, to exactly replicate a chocolatey setup from one profile/computer to another.
@jacktose - you could copy and paste that or save a lot of time and effort by using my package for that purpose :) https://chocolatey.org/packages/choco-package-list-backup
(Which is why I have interest in this issue.)
Has this issue been solved? I have useRememberedArgumentsForUpgrades
turned on with no effect on export.
some arguments could contain sensitive data
@ferventcoder I don't see no direct security concerns for hindering the export of remembered arguments. Either these arguments are stored in a cryptographically secure way (thus preventing any unauthorized user from properly upgrading packages) or this information is already exposed to all users.
I also would appreciate the ability to show the arguments throug choco
.
the security concerns raised in this issues are kind of moot when NugetEncryptionUtility uses the machine key for encrypting the arguments. anyone on the local computer who can read C:\ProgramData\chocolatey\.chocolatey\foo\.arguments
(in a default installation this is everyone in the Users
group) can also fully decrypt it.
using System;
using System.IO;
using System.Security.Cryptography;
using System.Text;
namespace ChocoDecrypt
{
public class Program
{
private static readonly byte[] _entropyBytes = Encoding.UTF8.GetBytes("Chocolatey");
public static void Main(string[] args)
{
var encryptedByteArray = Convert.FromBase64String(File.ReadAllText(args[0]));
var decryptedByteArray = ProtectedData.Unprotect(encryptedByteArray, _entropyBytes, DataProtectionScope.LocalMachine);
Console.WriteLine(Encoding.UTF8.GetString(decryptedByteArray));
}
}
}
D:\>C:\windows\Microsoft.NET\Framework\v4.0.30319\csc.exe /nologo ChocoDecrypt.cs
D:\>ChocoDecrypt.exe C:\ProgramData\chocolatey\.chocolatey\git.2.19.0\.arguments
--package-parameters="'/GitOnlyOnPath /NoAutoCrLf /NoShellIntegration /NoGitLfs'" --cache-location="'C:\Users\Heldchen\AppData\Local\Temp\chocolatey'" --use-system-powershell
@heldchen Thank you for the valuable input. Me too, would appreciate the ability to show the arguments through choco
. Here, I confirm your method works.
@ferventcoder the way to opt in with useRememberedArgumentsForUpgrades
looks nice to me. Its default is False
, so everything OK.
Conclusion (edited): administrators should be aware that in the current open source version the encryption does not protect their remembered installation secrets therefore they should set up access control to prevents users from reading them.
See bcurran3/ChocolateyPackages#7 too.
@stippingerm @heldchen That ability to unencrypt knowing a few bits is exactly why we're adding double encryption in C4B so that someone would not be able to decrypt the data at rest. ~~It's less of a concern to do so when it's a person's personal computer.~~ It's a security concern on a personal computer, but someone having access is going to typically have more avenues for doing bad things. It's typically much more of a concern to do so when we are talking about organizational use. So maybe only a moot point of obfuscation at best with open source Chocolatey, not with C4B.
Updated that last statement for clarification.
so in other words, Chocolatey in the open source version could easily add a parameter to show the arguments, without any of the aforementioned concerns raised.
personally, I doubt that this feature is relevant in a organizational use case anyway, as one expects things as "parameters used" to be documented in such a setting anyway.
@heldchen fair statement
I don't think there was argument that this feature was not valuable. There are loads of valuable feature adds in our backlog here (lots of tickets), being a year or more old doesn't mean we don't plan to address. Typically if we have a milestone on something, it's considered in our backlog.
Maybe there doesn't need further motivation on why this is useful, but here's mine:
Backing up installed packages, which are then exported and installed on a fresh computer with the same optional parameters.
Another motivation: in trying to make upgrade
actually upgrade – not re-install packages – one would have to pass arguments to packages to not create a desktop shortcut again.
And in order not to break the ability to upgrade with choco upgrade -y somepackage
that NoDesktopIcon install argument could be saved using useRememberedArgumentsForUpgrades
Here's a PowerShell one-liner based on @heldchen's solution
Add-Type -AssemblyName System.Security
Get-ChildItem -Filter ".arguments" -Path "C:\ProgramData\chocolatey\.chocolatey" -Recurse | ForEach-Object { Write-Output ("{0}: {1}" -f $_.Directory.BaseName, [System.Text.Encoding]::UTF8.GetString([System.Security.Cryptography.ProtectedData]::Unprotect([System.Convert]::FromBase64String(($_ | Get-Content -Encoding UTF8)), [System.Text.Encoding]::UTF8.GetBytes("Chocolatey"), [System.Security.Cryptography.DataProtectionScope]::LocalMachine))) }
This is especially important when one wants to find out, which packages were installed with --prerelease
, and remove that parameter.