Decryption fails if line ending is not set to LF on Windows systems

Version: sops 3.7.1

To replicate the problem, use a Windows system or VM with Windows
Instructions:

1. Create a new folder - sopstest
2. git init
3. create file .sops.yaml. (edit to put in your AWS account # and KMS guid id)

creation_rules:
  - path-regex: .*
    kms: 'arn:aws:kms:us-east-2:[AWSACCOUNT]:key/[KEY-GUID]'

4. Create a keyvalue file test.txt with content

A=B
C=D

5. Encrypt the file using sops

AWS_PROFILE=default sops -e test.txt > text.txt.enc

6. Verify text.txt.enc has LF line endings
7. Verify that your c:\users\[USER]\.gitconfig has

[core]
	autocrlf = true # recommended for Windows systems

8. git add . --all
9. git commit -m "First commit"

Now, clone the repo by doing this:

1. cd .. (move to the parent folder of sopstest)
2. git clone ./sopstest sopstest2
3. Load test.txt.enc in sopstest2 folder in an editor. The line endings will be CRLF
4. decrypt the file using sops by

AWS_PROFILE=default sops -d test.txt.enc > test.txt

(an error message is shown that it can't parse the date, and the file is not decrypted.)
Verify that line endings in test.txt.enc are CRLF.

Workaround:
Create a .gitattributes file at the root of your repo, and add this line

*.enc -cr

This will prevent the auto cr → crlf conversion for files with extension .enc

It would be good for sops to handle CRLF terminated encrypted files correctly -- and that's why I am submitting this issue.

Start by reproducing the Windows checkout and CRLF decryption failure described in the issue, using the sample .sops.yaml and test.txt.enc workflow. Trace the decryption path that reports the date-parsing error; done means sops decrypts CRLF-terminated encrypted files without requiring the .gitattributes workaround.