Makes sure that the 'data' key refers to strings. Also
improves error messages, and on CLI hints at the --output-type
option.
Signed-off-by: Felix Fontein <felix@fontein.de>
More 2023 alike :-)
This change is fully backwards compatible, as the checksum is only used
to make a comparison before and after the file has been opened by the
editor.
Signed-off-by: Hidde Beydals <hidde@hhh.computer>
This changes the logic of the edit target to close the temporary file
before it is opened by the user their editor. This works around an
issue on Windows where editors are unable to open the file because the
Go standard library opens file handles with only shared read and write
access (excluding deletion access, which is required by some).
Signed-off-by: Hidde Beydals <hidde@hhh.computer>
Deprecation of `io/ioutil`, removal of unused functions, possible nil
pointer dereference, and other tiny nits.
There are (many) more, but these would require their own (commit)
context.
Signed-off-by: Hidde Beydals <hidde@hhh.computer>
This commit renames the Go module from `go.mozilla.org/sops/v3` to
`github.com/getsops/sops/v3` without a major version bump, to align
with new stewardship.
For more information around this change, refer to
https://github.com/getsops/sops/issues/1246.
For a one-liner to change the `go.mod` and any import paths in your
Go project making use of this module, run:
```
find /path/to/repo -type f \( -name "*.go" -o -name "go.mod" \) -exec sed -i 's|go.mozilla.org/sops/v3|github.com/getsops/sops/v3|g' {} \;
find /path/to/repo -type f \( -name "*.go" -o -name "go.mod" \) -exec sed -i '' 's|go.mozilla.org/sops/v3|github.com/getsops/sops/v3|g' {} \;
```
Signed-off-by: Hidde Beydals <hidde@hhh.computer>
I encountered an issue when I tried so specify multiple age recipients
in the .sops.yaml config file of my repository.
I tried running `sops --age 'agePubKey1,agePubKey2' -e -i values.secret.yaml`
which produced an appropriate file with two entries in the `/sops/age/-`
part of the encrypted yaml file.
However, I then continued to set multiple recipients in my .sops.yaml
file to simplify handling:
```yaml
creation_rules:
- encrypted_regex: '^(data|stringData|spec)$'
age: 'agePubKey1,agePubKey2'
```
However, this resulted in encryption only being done for the first
specified agePubKey, not the second or third one.
After digging a bit trough the code, I think this should fix it.
I verified the fix locally on my machine and got it working. Also adding
some unit tests and extending the repository examples so they can be
decrypted using the age keys provided in `age/keys.txt`
Signed-off-by: Cedric Kienzler <github@cedric-kienzler.de>
* Close tmpfile after writing
Windows will not allow for deletion of a file with an open handle,
close tmpfile after writing to prevent unencrypted tmpfiles out-living
the execution
* Update cmd/sops/edit.go
Co-authored-by: Adrian Utrilla <adrianutrilla@gmail.com>
* defer edited file close
Co-authored-by: Adrian Utrilla <adrianutrilla@gmail.com>
"sops updatekeys" is not working the same as when encrypting a file. The
reason is that for "sops --encrypt", the file path is made absolute before
it is compared with the path_regex in the config file. This is not done for
"sops updatekeys", therefore it does not match the correct entry in the
config file when updating keys.
* update 'updatekeys' subcommand to use config (if exists) from commandline
* Fix #671: `updatekeys` checks for config file flag
The 'updatekeys' subcommand did not check for the config flag
in the command line. Add that check and if found use it to set configPath.
* Fix #671: `updatekeys` checks for config file flag
The 'updatekeys' subcommand did not check for the config global string flag.
Add that check and if found use it to set configPath.
* Fix #671: `updatekeys` checks for config file flag
The 'updatekeys' subcommand did not check for the config global string flag.
Add that check and if found use it to set configPath.
Edit: Remove mistake file addition
* Update cmd/sops/main.go
Co-authored-by: Adrian Utrilla <adrianutrilla@gmail.com>
* feat: initial adding of vualt transit backend to sops
initial work on integration
feat(vault): added cli coomands working for vualt"
fix(vault): fixed config with correct tests
fix(vault): added vault to keygroup and to keyservice server
fixed metadata load
* feat(docs): added docs in README.md and in command help
fix(doc): fix rst formatting"
fix(doc): fix rst formatting
* fix(vault): addressed typos and fixes from autrilla
feat(cli): moved vault to hc-vault naming
* fix(test): typo while rebasing
* fix typos and imporve error messages for vault kms
* rename package from vault to hcvault
* refactor vault keysource url validation
* add negative test cases for vault keysource
* add hc vault transit config option via objects
additional to URIs
* remove vault_example.yml
* streamline key name to snake case
* rename `BackendPath` to `EnginePath` for hc vault
* correction in hc-vault-transit commands
Signed-off-by: vnzongzna <github@vaibhavk.in>
* resolving conflict
Signed-off-by: vnzongzna <github@vaibhavk.in>
* Apply suggestions from code review
Co-Authored-By: Adrian Utrilla <adrianutrilla@gmail.com>
* allowing only hc_vault_transit_uri as input
Co-Authored-By: gitirabassi
Co-Authored-By: ldue
Signed-off-by: vnzongzna <github@vaibhavk.in>
Co-authored-by: gitirabassi <giacomo@tirabassi.eu>
Co-authored-by: ldue <larsduennwald@gmail.com>
Co-authored-by: Vaibhav Kaushik <vaibhavkaushik@vaibhavka-ltm1.internal.salesforce.com>
Co-authored-by: Adrian Utrilla <adrianutrilla@gmail.com>
Rationale
=========
The dotenv store as it exists right now performs splitting on newlines
to determine where a new key-value pair or comment begins. This works
remarkably well, up until you need to handle values that contain
newlines.
While I couldn't find an offical dotenv file format spec, I sampled a
number of open-source dotenv parsers and it seems that they typically
apply the following rules:
Comments:
* Comments may be written by starting a line with the `#` character.
Newline handling:
* If a value is unquoted or single-quoted and contains the character
sequence `\n` (`0x5c6e`), it IS NOT decoded to a line feed (`0x0a`).
* If a value is double-quoted and contains the character sequence `\n`
(`0x5c6e`), it IS decoded to a line feed (`0x0a`).
Whitespace trimming:
* For comments, the whitespace immediately after the `#` character and any
trailing whitespace is trimmed.
* If a value is unquoted and contains any leading or trailing whitespace, it
is trimmed.
* If a value is either single- or double-quoted and contains any leading or
trailing whitespace, it is left untrimmed.
Quotation handling:
* If a value is surrounded by single- or double-quotes, the quotation marks
are interpreted and not included in the value.
* Any number of single-quote characters may appear in a double-quoted
value, or within a single-quoted value if they are escaped (i.e.,
`'foo\'bar'`).
* Any number of double-quote characters may appear in a single-quoted
value, or within a double-quoted value if they are escaped (i.e.,
`"foo\"bar"`).
Because single- and double-quoted values may contain actual newlines,
we cannot split our input data on newlines as this may be in the middle
of a quoted value. This, along with the other rules around handling
quoted values, prompted me to try and implement a more robust parsing
solution. This commit is my first stab at that.
Special Considerations
======================
This is _not_ a backwards-compatible change:
* The `dotenv` files produced by this version of SOPS _cannot_ be read
by an earlier version.
* The `dotenv` files produced by an earlier version of SOPS _can_ be
read by this version, with the understanding that the semantics around
quotations and newlines have changed.
Examples
========
The below examples show how double-quoted values are passed to the
running environment:
```console
$ echo 'FOO="foo\\nbar\\nbaz"' > plaintext.env
$ sops -e --output ciphertext.env plaintext.env
$ sops exec-env ciphertext.env 'env | grep FOO | xxd'
00000000: 464f 4f3d 666f 6f5c 6e62 6172 5c6e 6261 FOO=foo\nbar\nba
00000010: 7a0a z.
```
```console
$ echo 'FOO="foo\nbar\nbaz"' > plaintext.env
$ sops -e --output ciphertext.env plaintext.env
$ sops exec-env ciphertext.env 'env | grep -A2 FOO | xxd'
00000000: 464f 4f3d 666f 6f0a 6261 720a 6261 7a0a FOO=foo.bar.baz.
```
* first pass: add --exec flag
* fix spacing
* subcommand for exec as well as other bits n bobs
--placeholder to pass files to child procs (similar to `find(1)`'s -exec flag)
--background to background processes if you don't need them to be interactive
* break the 2 execs into 2 subcommands
* add a non-fifo option for people who like files instead
* added a setuid flag just in case
* oups, used the wrong functions
* Update README.rst
* typo
* first attempt at separating out windows/unix functionality
* add the caveat about windows
* windows: make sure --no-fifo is being used and warn when it's not
* stray fixes
* switch to logrus, break out the command builder, and remove /tmp/ default
