Line ending issue with identity file on Windows?

[kapsiR]

Environment

• OS: Windows 10 21H1 (OS Build 19043.1415)
• age version: v1.0.0
• Terminal: Windows Terminal 1.11.3471.0
• Shell: PowerShell 7.2.1

What were you trying to do

Generate an identity file with an auto-generated passphrase and use it.

What happened

Keygen

.\age-keygen.exe | .\age.exe -p > key3.age
Public key: age1e07kjcnfp4d76q9ymahnnajrqu34x3xwnu5jmgaunl0y59dml3yqm5mwr3
Enter passphrase (leave empty to autogenerate a secure one):
Using the autogenerated passphrase "***".

Use it

Get-Content .\test.txt | .\age.exe -e -i key3.age -r age1e07kjcnfp4d76q9ymahnnajrqu34x3xwnu5jmgaunl0y59dml3yqm5mwr3 -o test.txt.age
age: error: internal error processing "key3.age": failed to decrypt identity file: failed to read header: parsing age header: unexpected intro: "age-encryption.org/v1\r\n"
age: report unexpected or unhelpful errors at https://filippo.io/age/report

Change CRLF to LF

Get-Content .\test.txt | .\age.exe -e -i key3.age -r age1e07kjcnfp4d76q9ymahnnajrqu34x3xwnu5jmgaunl0y59dml3yqm5mwr3 -o test.txt.age
Enter passphrase for identity file "key3.age":
age: error: internal error processing "key3.age": failed to read secret keys file: failed to decrypt and authenticate payload chunk
age: report unexpected or unhelpful errors at https://filippo.io/age/report

[str4d]

The age format requires LF everywhere, not CRLF. But this is problematic on Windows, which will in some situations swap LF for CRLF in pipelines IIRC. I think this is what is happening during your keygen step. The ASCII-armored age encapsulation exists to get around this issue. Could you try this and see if it helps?

.\age-keygen.exe | .\age.exe -p -a > key3.age

You will likely also need to use -a when encrypting the actual ciphertexts, for a similar reason.

[str4d]

See also #290.

[kapsiR]

Thanks! I'll try that and report it back here.

[EDIT]
I've verified it and with -a it works. Thanks!

[FiloSottile]

Indeed, this is a duplicate of #290. You just can't use redirection without -a on Windows. Alternatively, also using -o would work. I really wish we could find a way to detect this and print a warning, but it's kind of ridiculous for every CLI tool that outputs binary to have this issue.