Use new subcommands in README and examples.

Signed-off-by: Felix Fontein <[email protected]>

Author: felixfontein

README.rst

@@ -154,7 +154,7 @@ To decrypt a file in a ``cat`` fashion, use the ``-d`` flag:
 
 .. code:: sh
 
-    $ sops -d mynewtestfile.yaml
+    $ sops decrypt mynewtestfile.yaml
 
 SOPS encrypted files contain the necessary information to decrypt their content.
 All a user of SOPS needs is valid AWS credentials and the necessary
@@ -195,7 +195,7 @@ the ``--age`` option or the **SOPS_AGE_RECIPIENTS** environment variable:
 
 .. code:: sh
 
-    $ sops --encrypt --age age1yt3tfqlfrwdwx0z0ynwplcr6qxcxfaqycuprpmy89nr83ltx74tqdpszlw test.yaml > test.enc.yaml
+    $ sops encrypt --age age1yt3tfqlfrwdwx0z0ynwplcr6qxcxfaqycuprpmy89nr83ltx74tqdpszlw test.yaml > test.enc.yaml
 
 When decrypting a file with the corresponding identity, SOPS will look for a
 text file name ``keys.txt`` located in a ``sops`` subdirectory of your user
@@ -245,11 +245,11 @@ sdk:
 
 Now you can encrypt a file using::
 
-    $ sops --encrypt --gcp-kms projects/my-project/locations/global/keyRings/sops/cryptoKeys/sops-key test.yaml > test.enc.yaml
+    $ sops encrypt --gcp-kms projects/my-project/locations/global/keyRings/sops/cryptoKeys/sops-key test.yaml > test.enc.yaml
 
 And decrypt it using::
 
-     $ sops --decrypt test.enc.yaml
+     $ sops decrypt test.enc.yaml
 
 Encrypting using Azure Key Vault
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -319,11 +319,11 @@ from the commandline:
 
 Now you can encrypt a file using::
 
-    $ sops --encrypt --azure-kv https://sops.vault.azure.net/keys/sops-key/some-string test.yaml > test.enc.yaml
+    $ sops encrypt --azure-kv https://sops.vault.azure.net/keys/sops-key/some-string test.yaml > test.enc.yaml
 
 And decrypt it using::
 
-     $ sops --decrypt test.enc.yaml
+     $ sops decrypt test.enc.yaml
 
 
 Encrypting using Hashicorp Vault
@@ -374,7 +374,7 @@ To easily deploy Vault locally: (DO NOT DO THIS FOR PRODUCTION!!!)
     $ vault write sops/keys/thirdkey type=chacha20-poly1305
     Success! Data written to: sops/keys/thirdkey
 
-    $ sops --encrypt --hc-vault-transit $VAULT_ADDR/v1/sops/keys/firstkey vault_example.yml
+    $ sops encrypt --hc-vault-transit $VAULT_ADDR/v1/sops/keys/firstkey vault_example.yml
 
     $ cat <<EOF > .sops.yaml
     creation_rules:
@@ -384,7 +384,7 @@ To easily deploy Vault locally: (DO NOT DO THIS FOR PRODUCTION!!!)
           hc_vault_transit_uri: "$VAULT_ADDR/v1/sops/keys/thirdkey"
     EOF
 
-    $ sops --verbose -e prod/raw.yaml > prod/encrypted.yaml
+    $ sops encrypt --verbose prod/raw.yaml > prod/encrypted.yaml
 
 Adding and removing keys
 ~~~~~~~~~~~~~~~~~~~~~~~~
@@ -839,7 +839,7 @@ You can then decrypt the file the same way as with any other SOPS file:
 
 .. code:: sh
 
-    $ sops -d example.json
+    $ sops decrypt example.json
 
 Key service
 ~~~~~~~~~~~
@@ -879,14 +879,14 @@ service exposed on the unix socket located in ``/tmp/sops.sock``, you can run:
 
 .. code:: sh
 
-    $ sops --keyservice unix:///tmp/sops.sock -d file.yaml`
+    $ sops decrypt --keyservice unix:///tmp/sops.sock file.yaml`
 
 And if you only want to use the key service exposed on the unix socket located
 in ``/tmp/sops.sock`` and not the local key service, you can run:
 
 .. code:: sh
 
-    $ sops --enable-local-keyservice=false --keyservice unix:///tmp/sops.sock -d file.yaml
+    $ sops decrypt --enable-local-keyservice=false --keyservice unix:///tmp/sops.sock file.yaml
 
 Auditing
 ~~~~~~~~
@@ -953,7 +953,7 @@ written to disk.
 .. code:: sh
 
     # print secrets to stdout to confirm values
-    $ sops -d out.json
+    $ sops decrypt out.json
     {
             "database_password": "jf48t9wfw094gf4nhdf023r",
             "AWS_ACCESS_KEY_ID": "AKIAIOSFODNN7EXAMPLE",
@@ -1103,7 +1103,7 @@ Below is an example of publishing to Vault (using token auth with a local dev in
 
     $ export VAULT_TOKEN=...
     $ export VAULT_ADDR='http://127.0.0.1:8200'
-    $ sops -d vault/test.yaml
+    $ sops decrypt vault/test.yaml
     example_string: bar
     example_number: 42
     example_map:
@@ -1144,23 +1144,23 @@ extension after encrypting a file. For example:
 
 .. code:: sh
 
-    $ sops -e -i myfile.json
-    $ sops -d myfile.json
+    $ sops encrypt -i myfile.json
+    $ sops decrypt myfile.json
 
 If you want to change the extension of the file once encrypted, you need to provide
 ``sops`` with the ``--input-type`` flag upon decryption. For example:
 
 .. code:: sh
 
-    $ sops -e myfile.json > myfile.json.enc
+    $ sops encrypt myfile.json > myfile.json.enc
 
-    $ sops -d --input-type json myfile.json.enc
+    $ sops decrypt --input-type json myfile.json.enc
 
 When operating on stdin, use the ``--input-type`` and ``--output-type`` flags as follows:
 
 .. code:: sh
 
-    $ cat myfile.json | sops --input-type json --output-type json -d /dev/stdin
+    $ cat myfile.json | sops decrypt --input-type json --output-type json /dev/stdin
 
 YAML anchors
 ~~~~~~~~~~~~
@@ -1276,13 +1276,13 @@ encrypt the file, and redirect the output to a destination file.
 
     $ export SOPS_KMS_ARN="arn:aws:kms:us-west-2:927034868273:key/fe86dd69-4132-404c-ab86-4269956b4500"
     $ export SOPS_PGP_FP="C9CAB0AF1165060DB58D6D6B2653B624D620786D"
-    $ sops -e /path/to/existing/file.yaml > /path/to/new/encrypted/file.yaml
+    $ sops encrypt /path/to/existing/file.yaml > /path/to/new/encrypted/file.yaml
 
 Decrypt the file with ``-d``.
 
 .. code:: sh
 
-    $ sops -d /path/to/new/encrypted/file.yaml
+    $ sops decrypt /path/to/new/encrypted/file.yaml
 
 Encrypt or decrypt a file in place
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -1293,9 +1293,9 @@ original file after encrypting or decrypting it.
 .. code:: sh
 
     # file.yaml is in cleartext
-    $ sops -e -i /path/to/existing/file.yaml
+    $ sops encrypt -i /path/to/existing/file.yaml
     # file.yaml is now encrypted
-    $ sops -d -i /path/to/existing/file.yaml
+    $ sops decrypt -i /path/to/existing/file.yaml
     # file.yaml is back in cleartext
 
 Encrypting binary files
@@ -1322,10 +1322,10 @@ In-place encryption/decryption also works on binary files.
     $ sha512sum /tmp/somerandom
     9589bb20280e9d381f7a192000498c994e921b3cdb11d2ef5a986578dc2239a340b25ef30691bac72bdb14028270828dad7e8bd31e274af9828c40d216e60cbe /tmp/somerandom
 
-    $ sops -e -i /tmp/somerandom
+    $ sops encrypt -i /tmp/somerandom
     please wait while a data encryption key is being generated and stored securely
 
-    $ sops -d -i /tmp/somerandom
+    $ sops decrypt -i /tmp/somerandom
 
     $ sha512sum /tmp/somerandom
     9589bb20280e9d381f7a192000498c994e921b3cdb11d2ef5a986578dc2239a340b25ef30691bac72bdb14028270828dad7e8bd31e274af9828c40d216e60cbe /tmp/somerandom
@@ -1339,7 +1339,7 @@ values, like keys, without needing an extra parser.
 
 .. code:: sh
 
-    $ sops -d --extract '["app2"]["key"]' ~/git/svc/sops/example.yaml
+    $ sops decrypt --extract '["app2"]["key"]' ~/git/svc/sops/example.yaml
     -----BEGIN RSA PRIVATE KEY-----
     MIIBPAIBAAJBAPTMNIyHuZtpLYc7VsHQtwOkWYobkUblmHWRmbXzlAX6K8tMf3Wf
     ImcbNkqAKnELzFAPSBeEMhrBN0PyOC9lYlMCAwEAAQJBALXD4sjuBn1E7Y9aGiMz
@@ -1356,7 +1356,7 @@ them.
 
 .. code:: sh
 
-    $ sops -d --extract '["an_array"][1]' ~/git/svc/sops/example.yaml
+    $ sops decrypt --extract '["an_array"][1]' ~/git/svc/sops/example.yaml
     secretuser2
 
 Set a sub-part in a document tree
@@ -1439,7 +1439,7 @@ keys that match the supplied regular expression.  For example, this command:
 
 .. code:: sh
 
-    $ sops --encrypt --encrypted-regex '^(data|stringData)$' k8s-secrets.yaml
+    $ sops encrypt --encrypted-regex '^(data|stringData)$' k8s-secrets.yaml
 
 will encrypt the values under the ``data`` and ``stringData`` keys in a YAML file
 containing kubernetes secrets.  It will not encrypt other values that help you to
@@ -1451,7 +1451,7 @@ that match the supplied regular expression. For example, this command:
 
 .. code:: sh
 
-    $ sops --encrypt --unencrypted-regex '^(description|metadata)$' k8s-secrets.yaml
+    $ sops encrypt --unencrypted-regex '^(description|metadata)$' k8s-secrets.yaml
 
 will not encrypt the values under the ``description`` and ``metadata`` keys in a YAML file
 containing kubernetes secrets, while encrypting everything else.

cmd/sops/main.go

@@ -124,7 +124,7 @@ func main() {
 
    The -p, -k, --gcp-kms, --hc-vault-transit and --azure-kv flags are only used to encrypt new documents. Editing
    or decrypting existing documents can be done with "sops file" or
-   "sops -d file" respectively. The KMS and PGP keys listed in the encrypted
+   "sops decrypt file" respectively. The KMS and PGP keys listed in the encrypted
    documents are used then. To manage master keys in existing documents, use
    the "add-{kms,pgp,gcp-kms,azure-kv,hc-vault-transit}" and "rm-{kms,pgp,gcp-kms,azure-kv,hc-vault-transit}" flags.
 

examples/all_in_one/README.rst

@@ -42,7 +42,7 @@ In both development and production, we will be storing the secrets file unencryp
 
 As peace of mind, think about this:
 
-- Unencrypted on disk is fine because if the attacker ever gains access to the server, then they can run ``sops --decrypt`` as well.
+- Unencrypted on disk is fine because if the attacker ever gains access to the server, then they can run ``sops decrypt`` as well.
 
 Files
 -----
@@ -69,7 +69,7 @@ For testing in a public CI, we can copy ``secret.enc.json`` to ``secret.json``.
 
 ..
 
-    For convenience, we can run ``CONFIG_COPY_ONLY=TRUE bin/decrypt-config.sh`` which will use ``cp`` rather than ``sops --decrypt``.
+    For convenience, we can run ``CONFIG_COPY_ONLY=TRUE bin/decrypt-config.sh`` which will use ``cp`` rather than ``sops decrypt``.
 
 For testing in a private CI where we need private information, see the `Production instructions <#production>`_.
 

examples/all_in_one/bin/decrypt-config.sh

@@ -17,6 +17,6 @@ for file in $secret_files; do
     cp "$src_file" "$target_file"
   # Otherwise, decrypt it
   else
-    sops --decrypt "$src_file" > "$target_file"
+    sops decrypt "$src_file" > "$target_file"
   fi
 done

examples/per_file/README.rst

@@ -47,7 +47,7 @@ In both development and production, we will be storing the secrets file unencryp
 
 As peace of mind, think about this:
 
-- Unencrypted on disk is fine because if the attacker ever gains access to the server, then they can run ``sops --decrypt`` as well.
+- Unencrypted on disk is fine because if the attacker ever gains access to the server, then they can run ``sops decrypt`` as well.
 
 Files
 -----
@@ -78,7 +78,7 @@ For testing in a public CI, we can copy ``config.enc`` to ``config``. The secret
 
 ..
 
-    For convenience, we can run ``CONFIG_COPY_ONLY=TRUE bin/decrypt-config.sh`` which will use ``ln -s`` rather than ``sops --decrypt``.
+    For convenience, we can run ``CONFIG_COPY_ONLY=TRUE bin/decrypt-config.sh`` which will use ``ln -s`` rather than ``sops decrypt``.
 
 For testing in a private CI where we need private information, see the `Production instructions <#production>`_.
 

examples/per_file/bin/decrypt-config.sh

@@ -25,7 +25,7 @@ for src_file in config.enc/*; do
   # If the file is our secret, then decrypt it
   if echo "$src_filename" | grep -E "${secret_ext}$" &&
       test "$CONFIG_COPY_ONLY" != "TRUE"; then
-    sops --decrypt "$src_file" > "$target_file"
+    sops decrypt "$src_file" > "$target_file"
   # Otherwise, symlink to the original file
   else
     ln -s "../$src_file" "$target_file"