Ensure .arguments files that cannot be decrypted do not prevent running Chocolatey CLI commands #3503

Git-North · 2024-08-20T06:53:52Z

Checklist

I confirm there are no unresolved issues reported on the Chocolatey Status page.
I have verified this is the correct repository for opening this issue.
I have verified no other issues exist related to my problem.
I have verified this is not an issue for a specific package.
I have verified this issue is not security related.
I confirm I am using official, and not unofficial, or modified, Chocolatey products.

What You Are Seeing?

most commands give the following error:
Key not valid for use in specified state.

What is Expected?

For the command to run like normal
For example when run choco list: I get the following output:

Chocolatey v2.3.0
Key not valid for use in specified state.

Instead of it listing the program list.

How Did You Get This To Happen?

I Cannot recall any action I have made recently that would cause this.

System Details

Operating System: Win 11
Windows PowerShell version: 7.4.5
Chocolatey CLI Version: Chocolatey v2.3.0
Chocolatey Licensed Extension version:
Chocolatey License type: Open Source
Terminal/Emulator: Microsoft-Windows-Terminal / Conhost.exe

Installed Packages

Unable to run command. the output is:

Chocolatey v2.3.0
Key not valid for use in specified state.

Output Log

https://gist.github.com/Git-North/a2726d51475f267e15bab8d716781169

Additional Context

I have refreshed my crypto folder under %appdata% as google recommended however no luck with that too

@gep13 added...

See the comment here on a decision that was reached on how to proceed with this problem.

The text was updated successfully, but these errors were encountered:

Git-North · 2024-08-20T06:55:54Z

#2354 an deferred issue related to this issue

gep13 · 2024-08-20T08:27:54Z

@Git-North are you using, or have you used, any authenticated Chocolatey repository, where you were required to enter username/password, or certificate/password information? Or are you just using the default Chocolatey Community Repository? Or perhaps, you have had to set proxy information, in order to use Chocolatey CLI?

The reason that I ask is that this error seems to be related to an attempt to decrypt a value that is stored in the chocolatey.config file, so I am curious as to what might have happened to get this file into a state where it can't be read correctly.

Git-North · 2024-08-20T10:28:23Z

I've never used anything other then the default repository and was never asked to authenticate to anything, and never did.

Regarding the proxy, I never used any chocolatey specific proxy. Only system wide and it is currently disabled

Git-North · 2024-08-20T10:31:09Z

Regarding the proxy, I never used any chocolatey specific proxy. Only system wide and it is currently disabled

I don't know if any package could have done this though. If it can I'm unaware

gep13 · 2024-08-20T12:41:01Z

Okay, thank you for the information. Part of the reason that I wanted to ask that, is due to the fact that it would be good to see the contents/format of the chocolatey.config file. However, this file can contain sensitive information, and not something that should be routinely shared with anyone.

If you were willing, if would be good to get a copy of the chocolatey.config file, and also the backup file, if it exists, from the C:\ProgramData\Chocolatey\config folder.

Seeing this file, and attempting to use it locally might help understand what is going on.

Git-North · 2024-08-20T14:10:26Z

https://gist.github.com/Git-North/fa8866821bca0f763866ac2bc3e5d777

gep13 · 2024-08-21T08:24:01Z

@Git-North please accept my apologies, I misread the stacktrace for the problem that you are having here.

The problem is not with the chocolatey.config file, but rather with one of the .arguments files that was created when Chocolatey CLI installed one of the packages that you have on your machine.

Can I get you to try something? Can you navigate into the C:\ProgramData\chocolatey\lib folder, and then take the name of the first folder that you can see, and then run the following command:

choco info <folder name> --local-only

Assuming that this command runs as expected, you should hopefully see something like this, listed at the bottom of the output:

If that works, it means that the .arguments file associated with the package that you selected isn't causing a problem. It could be that you don't see this output, and that is fine, it just means that there isn't a .arguments file associated with that package. If that happens, can you keep going through the list of folders until you do see something in the output?

How many packages do you have installed with Chocolatey? In other words, how many folders do you have in the C:\ProgramData\chocolatey\lib folder? Again, assuming that the above command worked, you could try running the same command for each package, and eventually, I would expect that there should be an exception, with the same error message as before, thrown. This would help narrow down which .arguments file is causing a problem, and from there, we might be able to figure out what is going on. The fix, at least in the interim, could be as simple as to delete the .arguments file associated with the package.

gep13 · 2024-08-21T12:14:49Z

@Git-North said...
most commands give the following error:

Can you also please confirm which commands you are seeing being impacted by this?

gep13 · 2024-08-21T12:21:42Z

After some internal discussion, the decision has been made that any attempt to decrypt an .arguments file, shouldn't result in an exception being thrown, unless it is critical to the execution of the command being ran.

For example, if/when running choco list or choco info, an exception should not be thrown if the .arguments file can't be decrypted. Instead, a warning should be shown (indicating the location of the file that can't be decrypted), and the remainder of the command execution should continue.

However, if running the choco upgrade command, when the UseRememberedArgumentsForUpgrades feature is enabled, an exception should be thrown if the .arguments file can't be decrypted. The reason being that the content of that file is a _requirement` for executing the command, and since it can't be decrypted, the command can't be completed in its entirety. Again, in the output, the location of the specific file that can't be decrypted should be shown.

The commands that are affected by this problem are pin, install, upgrade, list, export, outdated, and uninstall. In addition, there can be problems when attempting to use alternative sources when in this state as well.

Git-North · 2024-08-21T17:45:01Z

pin, install, upgrade, list, export cause the same error. tried all of the commands listed when user types help except uninstall.

Git-North · 2024-08-21T17:57:52Z

after running choco info adb --local-only it says:

Processing directory: adb

a few times and then starts saying

Processing directory: adb
Maximum setlocal recursion level reached.

again and again and then at the very bottom it says

Processing directory: anaconda3
Processing directory: adb
Processing directory: adb

after that the terminal closes
anaconda3 is the folder after adb

gep13 · 2024-08-21T18:28:33Z

@Git-North that seems very strange to me! (I will need to look into that specific issue, as I don't know if that is related).

Can you try the command I gave you with some other packages that you have installed? Do they have the same results?

gep13 · 2024-08-22T12:40:04Z

@Git-North said...
after running choco info adb --local-only it says:

Would it be possible for you to show a screenshot of this happening? So far, I am not able to replicate this happening.

Can you also confirm what terminal you are using? Are you using Command Prompt? PowerShell? Something else?

Also, in a PowerShell session, can you run the following, and provide the output here?

&where.exe choco

Git-North · 2024-08-22T16:42:36Z

Can you also confirm what terminal you are using? Are you using Command Prompt? PowerShell? Something else?

I use pwsh 7 and when I don't I use cmd with clink

My main terminal is "microsoft-windows-terminal --pre" but I also get these outputs when I use the default conhost and some automated VBS scripts.

I'll provide the other information later today.

Git-North · 2024-08-24T08:34:17Z

where.exe choco
C:\ProgramData\chocolatey\bin\choco.exe

Git-North · 2024-08-24T08:36:37Z

Interesting update: trying the info command results in:

Key not valid for use in specified state.

error which used to run fine. cant thing of anything that would change this behaviour

gep13 · 2024-08-24T13:35:42Z

@Git-North said...
where.exe choco
C:\ProgramData\chocolatey\bin\choco.exe

Thank you for confirming. This rules out another problem that I thought could be at play.

@Git-North said...
I use pwsh 7 and when I don't I use cmd with clink

Thank you again for confirming.

@Git-North said...
Interesting update: trying the info command results in:

I think I am getting lost in exactly what is, and what isn't working for you. Initially, you said you were seeing the:

Key not valid for use in specified state.

when running choco list, and then when I asked you to try running choco info <packageName> --local-only you mentioned that you were seeing a different error message (which I was hoping to see a screenshot of).

Can you confirm if you are now seeing the same:

Key not valid for use in specified state.

error when running a single choco info <packageName> command? If so, this would suggest, based on the code paths that are involved, that there is something corrupt in the .arguments file for that package.

If you can confirm the above is the case, we can move forward with trying to figure out what could be wrong with the .arguments file.

Git-North · 2024-08-27T16:29:24Z

Yes I was infact seeing a different error message. However when I later tried the same command above I got the Key not valid for use in specified state. error again

Git-North · 2024-08-27T16:38:18Z

I've run the following batch file I wrote for this occasion

@echo off
setlocal enabledelayedexpansion

REM Set the path to the Chocolatey library folder
set "libPath=C:\ProgramData\chocolatey\lib"

REM Set the path to the output log file
set "logPath=%cd%\logs.txt"

REM Clear the log file if it exists
echo. > "%logPath%"

REM Loop through each folder in the library path
for /d %%F in ("%libPath%\*") do (
    set "folderName=%%~nxF"
    echo Processing !folderName!...
    echo. >> "%logPath%"
    echo Folder: !folderName! >> "%logPath%"
    choco info !folderName! --local-only >> "%logPath%"
)

echo Done. All information has been logged to %logPath%.

and got the following output
(https://gist.github.com/Git-North/61b1bce429d137eeeab12bf61c2b085c)

Git-North · 2024-08-29T20:05:38Z

For the record, this batch file runs choco info <folderName> --local-only for every folder.

tfonias74 · 2024-09-02T09:59:51Z

Hi, did you find a solution? I have the same problem.
List does not work. Re-install asks me to delete the whole folder and retry, upgrade gives the "Key not valid for use in specified state" error again.

pauby · 2024-09-02T11:42:59Z

@tfonias74 follow the instructions above to findout which package is causing the issue.

tfonias74 · 2024-09-02T12:06:03Z

Thanks.
I can see error in various folders and especially some like chocolatey-compatibility.extension. Can this be fixed or does it require clean install?

pauby · 2024-09-02T15:22:21Z

You may be able to run choco install <PACKAGE> --force to install it again. Remember to add any additional arguments you may have used when installing the package originally.

If that does not work you will need to uninstall and install the package again.

jbuedel · 2024-09-04T19:26:55Z

I am running into this same error. Key not valid for use in specified state. I am running choco v2.3.0.

It happens when I try to install, upgrade, or remove any package, including when I use the --force parameter.

Per the above instructions, I have tried running choco info <name> --local-only against the name of each folder in C:\ProgramData\chocolatey\lib. Some, but not all, give the Key not valid... error. Others give expected output. Regardless of the outcome of this test for a given package, I still get Key not valid.. when installing, upgrading, or deleting that package.

I am unclear how to proceed. Should I be manually removing my entire c:\ProgramData\chocolatey\lib directory and then reinstalling choco and all those packages? Or only manually remove the ones that failed the choco info ... test?

If it helps, here is a list of my folders in chocolatey\lib. They have an asterisk if they failed the choco info ... test.

ams-eclipse-agent
ams-eclipse-server
chocolatey
*chocolatey-core.extension
*chocolatey-dotnetfx.extension
*chocolatey-windowsupdate.extension
dotnet
dotnet-6.0-aspnetruntime
dotnet-6.0-runtime
dotnet-6.0-sdk
dotnet-6.0-sdk-3xx
dotnet-aspnetruntime
dotnet-runtime
*dotnetfx
*KB2919355
*KB2919442
*KB2999226
*KB3033929
*KB3035131
*KB3063858
ravendb
tailblazer
vcredist140
*vcredist2017
vfpoledb

Lastly, I believe choco itself was upgraded on this machine today. Unfortunately I can't tell you what version it was at originally, but likely was 2-3 years old.

jbuedel · 2024-09-04T20:37:56Z

We ended up solving it. We deleted the .arguments file for every package that failed the choco info ... test (described above).

Git-North · 2024-09-05T17:21:31Z

I made this batch script for finding faulty .argument files and deleting them

@echo off
setlocal enabledelayedexpansion

REM Set the directory of the script
set "scriptDir=%~dp0"

REM Set the path to the Chocolatey library folder
set "libPath=C:\ProgramData\chocolatey\lib"

REM Set the path to the Chocolatey .chocolatey folder
set "chocoRoot=C:\ProgramData\chocolatey\.chocolatey"

REM Set the path to the output log file in the script's directory
set "logPath=%scriptDir%logs.txt"

REM Set the path to the error log file in the script's directory
set "errorLogPath=%scriptDir%error_logs.txt"

REM Clear the log files if they exist
echo. > "%logPath%"
echo. > "%errorLogPath%"

REM Loop through each folder in the library path
for /d %%F in ("%libPath%\*") do (
    set "folderName=%%~nxF"
    echo Processing !folderName!...
    echo. >> "%logPath%"
    echo Folder: !folderName! >> "%logPath%"
    
    REM Get the output of the choco info command
    choco info !folderName! --local-only > "%scriptDir%temp_output.txt" 2>&1

    REM Log the entire output
    type "%scriptDir%temp_output.txt" >> "%logPath%"

    REM Check for the specific error message in the output file
    findstr /c:"Key not valid for use in specified state." "%scriptDir%temp_output.txt" >nul
    if !errorlevel! equ 0 (
        echo !folderName! >> "%errorLogPath%"
        echo Error: "Key not valid for use in specified state." found for !folderName!

        REM Delete the .arguments file for the package
        if exist "%chocoRoot%\!folderName!\.arguments" (
            del "%chocoRoot%\!folderName!\.arguments"
            echo Deleted .arguments file for !folderName! >> "%logPath%"
        ) else (
            echo .arguments file not found for !folderName! >> "%logPath%"
        )
    )

    REM Delete the temporary output file
    del "%scriptDir%temp_output.txt"
)

echo Done. All information has been logged to %logPath%.
echo Packages with the error have been logged to %errorLogPath%.

Currently we are decrypting the arguments file every time a list is run, even though we only care about them in scenarios where we might output them to the user (when Verbose is specified on the list command or with the info --local-only command). This updates the handling of the remembered arguments to be consistent between the List method and the scenario in an Upgrade where we want to use the remembered arguments. We now will only throw an error in a scenario where we can't decrypt the contents and we need them for the scenario to succeed. We are also stating what file we couldn't decrypt so the user can troubleshoot.

Add some Pester tests for the arguments file decryption handling. Ensuring that both invalid keys and base64 corruption works correctly.

Currently we are decrypting the arguments file every time a list is run, even though we only care about them in scenarios where we might output them to the user (when Verbose is specified on the list command or with the info --local-only command). This updates the handling of the remembered arguments to be consistent between the List method and the scenario in an Upgrade where we want to use the remembered arguments. We now will only throw an error in a scenario where we can't decrypt the contents and we need them for the scenario to succeed. We are also stating what file we couldn't decrypt so the user can troubleshoot.

Add some Pester tests for the arguments file decryption handling. Ensuring that both invalid keys and base64 corruption works correctly.

Currently we are decrypting the arguments file every time a list is run, even though we only care about them in scenarios where we might output them to the user (when Verbose is specified on the list command or with the info --local-only command). This updates the handling of the remembered arguments to be consistent between the List method and the scenario in an Upgrade where we want to use the remembered arguments. We now will only throw an error in a scenario where we can't decrypt the contents and we need them for the scenario to succeed. We are also stating what file we couldn't decrypt so the user can troubleshoot.

Add some Pester tests for the arguments file decryption handling. Ensuring that both invalid keys and base64 corruption works correctly.

- Use OrdinalIgnoreCase for command name comparison. - Log with Warn or Error where appropriate and emit to log file only as needed. - Use explicitly named parameters instead of true/false. - Remove comment that's no longer valid.

- Use OrdinalIgnoreCase for command name comparison. - Use explicitly named parameters instead of true/false. - Remove comment that's no longer valid.

Currently we are decrypting the arguments file every time a list is run, even though we only care about them in scenarios where we might output them to the user (when Verbose is specified on the list command or with the info --local-only command). This updates the handling of the remembered arguments to be consistent between the List method and the scenario in an Upgrade where we want to use the remembered arguments. We now will only throw an error in a scenario where we can't decrypt the contents and we need them for the scenario to succeed. We are also stating what file we couldn't decrypt so the user can troubleshoot.

Add some Pester tests for the arguments file decryption handling. Ensuring that both invalid keys and base64 corruption works correctly.

- Use OrdinalIgnoreCase for command name comparison. - Use explicitly named parameters instead of true/false. - Remove comment that's no longer valid.

(#3503, #3513) Handle arguments file decryption failures

The CommandName is null when the list method is called during alternate source commands.

(#3503, #3513) Add null check to Command Name

vexx32 · 2024-11-12T22:42:55Z

🎉 This issue has been resolved in version 2.4.0 🎉

The release is available on:

Git-North added the Bug label Aug 20, 2024

gep13 added this to the 2.4.0 milestone Aug 21, 2024

gep13 added the 0 - Backlog label Aug 21, 2024

corbob added a commit to corbob/choco that referenced this issue Oct 25, 2024

(chocolatey#3503, chocolatey#3513) Handle decryption failures better

713c42a

corbob mentioned this issue Oct 28, 2024

(#3503, #3513) Handle arguments file decryption failures #3540

Merged

10 tasks

corbob added a commit to corbob/choco that referenced this issue Oct 29, 2024

(chocolatey#3503, chocolatey#3513) Add tests for arguments file errors

d183bb2

Add some Pester tests for the arguments file decryption handling. Ensuring that both invalid keys and base64 corruption works correctly.

corbob added a commit to corbob/choco that referenced this issue Oct 30, 2024

(chocolatey#3503, chocolatey#3513) Add tests for arguments file errors

8248dd0

Add some Pester tests for the arguments file decryption handling. Ensuring that both invalid keys and base64 corruption works correctly.

corbob added 3 - Review and removed 2 - Working labels Oct 30, 2024

corbob added a commit to corbob/choco that referenced this issue Nov 4, 2024

(chocolatey#3503, chocolatey#3513) Add tests for arguments file errors

e53eb35

Add some Pester tests for the arguments file decryption handling. Ensuring that both invalid keys and base64 corruption works correctly.

corbob added a commit to corbob/choco that referenced this issue Nov 4, 2024

(chocolatey#3503, chocolatey#3513) Add tests for arguments file errors

cf047ef

Add some Pester tests for the arguments file decryption handling. Ensuring that both invalid keys and base64 corruption works correctly.

vexx32 added a commit that referenced this issue Nov 5, 2024

Merge pull request #3540 from corbob/handle-decryption-failures

242b3fc

(#3503, #3513) Handle arguments file decryption failures

vexx32 closed this as completed in #3540 Nov 5, 2024

vexx32 added 4 - Done and removed 3 - Review labels Nov 5, 2024

corbob added a commit to corbob/choco that referenced this issue Nov 6, 2024

(chocolatey#3503, chocolatey#3513) Add null check for CommandName

516f1a0

The CommandName is null when the list method is called during alternate source commands.

corbob mentioned this issue Nov 6, 2024

(#3503, #3513) Add null check to Command Name #3553

Merged

10 tasks

corbob added a commit to corbob/choco that referenced this issue Nov 6, 2024

(chocolatey#3503, chocolatey#3513) Add null check for CommandName

f5f2da1

The CommandName is null when the list method is called during alternate source commands.

vexx32 added a commit that referenced this issue Nov 6, 2024

Merge pull request #3553 from corbob/update-tests

e0c728d

(#3503, #3513) Add null check to Command Name

vexx32 changed the title ~~Key not valid for use in specified state.~~ Ensure .arguments files that cannot be decrypted do not prevent running CLI commands Nov 12, 2024

vexx32 changed the title ~~Ensure .arguments files that cannot be decrypted do not prevent running CLI commands~~ Ensure .arguments files that cannot be decrypted do not prevent running Chocolatey CLI commands Nov 12, 2024

vexx32 added the 5 - Released label Nov 12, 2024

vexx32 removed the 4 - Done label Nov 13, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Ensure .arguments files that cannot be decrypted do not prevent running Chocolatey CLI commands #3503

Ensure .arguments files that cannot be decrypted do not prevent running Chocolatey CLI commands #3503

Git-North commented Aug 20, 2024 •

edited

Loading

Git-North commented Aug 20, 2024

gep13 commented Aug 20, 2024

Git-North commented Aug 20, 2024 •

edited

Loading

Git-North commented Aug 20, 2024

gep13 commented Aug 20, 2024

Git-North commented Aug 20, 2024

gep13 commented Aug 21, 2024 •

edited

Loading

gep13 commented Aug 21, 2024

gep13 commented Aug 21, 2024 •

edited

Loading

Git-North commented Aug 21, 2024

Git-North commented Aug 21, 2024 •

edited

Loading

gep13 commented Aug 21, 2024

gep13 commented Aug 22, 2024

Git-North commented Aug 22, 2024

Git-North commented Aug 24, 2024

Git-North commented Aug 24, 2024 •

edited

Loading

gep13 commented Aug 24, 2024

Git-North commented Aug 27, 2024

Git-North commented Aug 27, 2024 •

edited

Loading

Git-North commented Aug 29, 2024

tfonias74 commented Sep 2, 2024

pauby commented Sep 2, 2024

tfonias74 commented Sep 2, 2024

pauby commented Sep 2, 2024

jbuedel commented Sep 4, 2024

jbuedel commented Sep 4, 2024

Git-North commented Sep 5, 2024

vexx32 commented Nov 12, 2024

Ensure .arguments files that cannot be decrypted do not prevent running Chocolatey CLI commands #3503

Ensure .arguments files that cannot be decrypted do not prevent running Chocolatey CLI commands #3503

Comments

Git-North commented Aug 20, 2024 • edited Loading

Checklist

What You Are Seeing?

What is Expected?

How Did You Get This To Happen?

System Details

Installed Packages

Output Log

Additional Context

Git-North commented Aug 20, 2024

gep13 commented Aug 20, 2024

Git-North commented Aug 20, 2024 • edited Loading

Git-North commented Aug 20, 2024

gep13 commented Aug 20, 2024

Git-North commented Aug 20, 2024

gep13 commented Aug 21, 2024 • edited Loading

gep13 commented Aug 21, 2024

gep13 commented Aug 21, 2024 • edited Loading

Git-North commented Aug 21, 2024

Git-North commented Aug 21, 2024 • edited Loading

gep13 commented Aug 21, 2024

gep13 commented Aug 22, 2024

Git-North commented Aug 22, 2024

Git-North commented Aug 24, 2024

Git-North commented Aug 24, 2024 • edited Loading

gep13 commented Aug 24, 2024

Git-North commented Aug 27, 2024

Git-North commented Aug 27, 2024 • edited Loading

Git-North commented Aug 29, 2024

tfonias74 commented Sep 2, 2024

pauby commented Sep 2, 2024

tfonias74 commented Sep 2, 2024

pauby commented Sep 2, 2024

jbuedel commented Sep 4, 2024

jbuedel commented Sep 4, 2024

Git-North commented Sep 5, 2024

vexx32 commented Nov 12, 2024

Git-North commented Aug 20, 2024 •

edited

Loading

Git-North commented Aug 20, 2024 •

edited

Loading

gep13 commented Aug 21, 2024 •

edited

Loading

gep13 commented Aug 21, 2024 •

edited

Loading

Git-North commented Aug 21, 2024 •

edited

Loading

Git-North commented Aug 24, 2024 •

edited

Loading

Git-North commented Aug 27, 2024 •

edited

Loading