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
Binary-mode SOPS files now open in the split-view editor. The .sops extension is recognised in addition to .bin, so files driven by a .sops.yaml rule like path_regex: \.sops$ work out of the box. The decrypted plaintext is shown on the left, the JSON envelope on the right (always read-only for binary mode), and saving re-encrypts the file in place. The decrypted side picks its syntax highlighting from the inner extension, so app.conf.sops is highlighted as .conf while the encrypted side stays as plain text.
The plugin now auto-detects the SOPS format from a file's content. The content is the source of truth for both whether a file is SOPS at all and which of the five supported formats it uses, so files with non-standard extensions (for example secrets.config containing per-key encrypted YAML, or data.cfg containing per-key encrypted JSON) are picked up automatically, and renamed or mislabeled files still decrypt with the right store. Filename-based matching is only consulted as a fallback when content has no SOPS markers, e.g. for plaintext files headed for the Encrypt with SOPS action. Resolves #1.
Changed
New SOPS files created with the Binary format now default to a .sops extension (previously .bin) and start from an empty plaintext template. The new default lines up with the typical .sops.yaml rule path_regex: \.sops$ so a fresh file is encrypted as binary out of the box.
Removed
The TOML format dropped out of the supported list. The sops CLI accepts --input-type toml but treats it internally as binary mode, so a .toml SOPS file produced by SOPS is in fact a JSON envelope and was never recognised by the previous TOML probe. Files with a .toml extension that contain SOPS data are now detected as binary mode, which matches what SOPS actually produces.
Fixed
Save (Ctrl+S) on a SOPS file no longer crashes with Write-unsafe context! on newer IntelliJ Platform builds. VFS writes and editor document updates are now scheduled through a non-modal write-action helper that sets up the correct modality, so the platform's reload-from-disk listener can run safely.
Opening a SOPS file with CRLF line endings (typical when SOPS produces a JSON envelope on Windows) no longer fails with a Wrong line separators assertion. Content is normalised to LF before it reaches the editor document.
Decrypting and re-encrypting SOPS files now passes --input-type and --output-type to the sops CLI based on the detected format, so files with non-standard extensions decrypt with the right store. Without these flags sops fell back to the binary store on unknown extensions and failed on per-key encrypted YAML/JSON.
Security
Added a SECURITY.md documenting the vulnerability reporting process and the triage policy for transitive dependency CVEs that do not apply to an IDE plugin (no network listener, no remote-supplied JSON parsing).
The build workflow now sets explicit permissions: contents: read to follow least-privilege for the GITHUB_TOKEN.