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
The consumer then (oversight) combines a plaintext YAML document with the YAML document they already encrypted, creating a single (amalgamated) YAML file with two separate YAMl documents. They do not include the encrypted YAML document first (i.e. when the cli searches branches[0] for existing metadata, the metadata key "sops" will not be identified and encryption will be performed).
This way, a file that is "partially encrypted" (encrypted in its entirety and then later combined with additional documents or objects) will not be encrypted a second time, resulting in data loss (since the file can now no longer be decrypted) and a panic on the cli's side when an attempt is made to decrypt the file.
Reasoning
CLI should only panic if there is a developer error, not a consumer oversight. If the panic can be prevented when an attempt is made to "doubly encrypt" a file, that would be ideal and allow the cli to exit gracefully. If the proposed solution is not ideal, for reasons of efficiency or otherwise, some mechanism should be employed to prevent a panic when an attempt to decrypt a "doubly-encrypted" file is made.
The text was updated successfully, but these errors were encountered:
Problem
When attempting to decrypt a file that has been (inadvertently) encrypted twice, cli panics.
Example
Consumer encrypts the following YAML file.
The result is:
The consumer then (oversight) combines a plaintext YAML document with the YAML document they already encrypted, creating a single (amalgamated) YAML file with two separate YAMl documents. They do not include the encrypted YAML document first (i.e. when the cli searches branches[0] for existing metadata, the metadata key "sops" will not be identified and encryption will be performed).
They encrypt the file (no error, no panic) and the contents are modified to:
When the consumer attempts to decrypt this file, sops will panic:
Proposed Solution
In the code, rather than iterating over only the first branch, looking for the "sops" metadata key in the file:
Code should iterate over all branches:
This way, a file that is "partially encrypted" (encrypted in its entirety and then later combined with additional documents or objects) will not be encrypted a second time, resulting in data loss (since the file can now no longer be decrypted) and a panic on the cli's side when an attempt is made to decrypt the file.
Reasoning
CLI should only panic if there is a developer error, not a consumer oversight. If the panic can be prevented when an attempt is made to "doubly encrypt" a file, that would be ideal and allow the cli to exit gracefully. If the proposed solution is not ideal, for reasons of efficiency or otherwise, some mechanism should be employed to prevent a panic when an attempt to decrypt a "doubly-encrypted" file is made.
The text was updated successfully, but these errors were encountered: