Skip to content

v1.1.0

Choose a tag to compare

@github-actions github-actions released this 07 May 14:28
· 1 commit to master since this release
v1.1.0
c7c5ebb

Added

  • 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.