Giter VIP home page Giter VIP logo

ejson's Introduction

ejson

ejson is a utility for managing a collection of secrets in source control. The secrets are encrypted using public key, elliptic curve cryptography (NaCl Box: Curve25519 + Salsa20 + Poly1305-AES). Secrets are collected in a JSON file, in which all the string values are encrypted. Public keys are embedded in the file, and the decrypter looks up the corresponding private key from its local filesystem.

demo

The main benefits provided by ejson are:

  • Secrets can be safely stored in a git repo.
  • Changes to secrets are auditable on a line-by-line basis with git blame.
  • Anyone with git commit access has access to write new secrets.
  • Decryption access can easily be locked down to production servers only.
  • Secrets change synchronously with application source (as opposed to secrets provisioned by Configuration Management).
  • Simple, well-tested, easily-auditable source.

See the manpages for more technical documentation.

See ejson2env for a useful tool to help with exporting a portion of secrets as environment variables for environments/tools that require this pattern.

Installation

You can download the .deb package from Github Releases.

On development machines (64-bit linux or OS X), the recommended installation method is via Homebrew:

brew tap shopify/shopify
brew install ejson

Workflow

1: Create the Keydir

By default, EJSON looks for keys in /opt/ejson/keys. You can change this by setting EJSON_KEYDIR or passing the -keydir option.

$ mkdir -p /opt/ejson/keys

For Mac OS users. By default you won't have write permissions to /opt/ejson folder. Make sure to run the following command to grant these permissions:

sudo chown -R $(whoami) /opt/ejson

2: Generate a keypair

When called with -w, ejson keygen will write the keypair into the keydir and print the public key. Without -w, it will print both keys to stdout. This is useful if you have to distribute the key to multiple servers via configuration management, etc.

$ ejson keygen
Public Key:
63ccf05a9492e68e12eeb1c705888aebdcc0080af7e594fc402beb24cce9d14f
Private Key:
75b80b4a693156eb435f4ed2fe397e583f461f09fd99ec2bd1bdef0a56cf6e64
$ ejson keygen -w
53393332c6c7c474af603c078f5696c8fe16677a09a711bba299a6c1c1676a59
$ cat /opt/ejson/keys/5339*
888a4291bef9135729357b8c70e5a62b0bbe104a679d829cdbe56d46a4481aaf

3: Create an ejson file

The format is described in more detail later on. For now, create a file that looks something like this. Fill in the <key> with whatever you got back in step 2.

Create this file as test.ejson:

{
  "_public_key": "<key>",
  "_database_username": "1234username",
  "database_password": "1234password"
}

4: Encrypt the file

Running ejson encrypt test.ejson will encrypt any new plaintext keys in the file and leave any existing encrypted keys or keys with property names prefixed with _ untouched:

{
  "_public_key": "63ccf05a9492e68e12eeb1c705888aebdcc0080af7e594fc402beb24cce9d14f",
  "_database_username": "1234username",
  "database_password": "EJ[1:WGj2t4znULHT1IRveMEdvvNXqZzNBNMsJ5iZVy6Dvxs=:kA6ekF8ViYR5ZLeSmMXWsdLfWr7wn9qS:fcHQtdt6nqcNOXa97/M278RX6w==]"
}

Try adding another plaintext secret to the file and run ejson encrypt test.ejson again. The database_password field will not be changed, but the new secret will be encrypted.

5: Decrypt the file

To decrypt the file, you must have a file present in the keydir whose name is the 64-byte hex-encoded public key exactly as embedded in the ejson document. The contents of that file must be the similarly-encoded private key. If you used ejson keygen -w, you've already got this covered.

Unlike ejson encrypt, which overwrites the specified files, ejson decrypt only takes one file parameter, and prints the output to stdout:

$ ejson decrypt foo.ejson
{
  "_public_key": "63ccf05a9492e68e12eeb1c705888aebdcc0080af7e594fc402beb24cce9d14f",
  "_database_username": "1234username",
  "database_password": "1234password"
}

Format

The ejson document format is simple, but there are a few points to be aware of:

  1. It's just JSON.
  2. There must be a key at the top level named _public_key, whose value is a 32-byte hex-encoded (i.e. 64 ASCII byte) public key as generated by ejson keygen.
  3. Any string literal that isn't an object key will be encrypted by default (ie. in {"a": "b"}, "b" will be encrypted, but "a" will not.
  4. Numbers, booleans, and nulls aren't encrypted.
  5. If a key begins with an underscore, its corresponding value will not be encrypted. This is used to prevent the _public_key field from being encrypted, and is useful for implementing metadata schemes.
  6. Underscores do not propagate downward. For example, in {"_a": {"b": "c"}}, "c" will be encrypted.

See also

  • If you use Capistrano for deployment you can use capistrano-ejson to automatically decrypt the secrets on deploy.
  • If you use pre-commit, you can use it to automatically encrypt secrets on commit.

ejson's People

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

ejson's Issues

"Ejson is not supported on your platform" error

I have installed Ejson on KDE5 (using gem install ejson), and when I type "ejson" an infinite stream of the error "Ejson is not supported on your platform" is printed.

So, for visual explanation:

$ sudo gem install ejson 
Fetching: ejson-1.0.1.gem (100%)
Successfully installed ejson-1.0.1
Parsing documentation for ejson-1.0.1
Installing ri documentation for ejson-1.0.1
Done installing documentation for ejson after 0 seconds
1 gem installed

$ ejson
Ejson is not supported on your platform.
Ejson is not supported on your platform.
Ejson is not supported on your platform.
Ejson is not supported on your platform.
Ejson is not supported on your platform.
Ejson is not supported on your platform.
^C/usr/lib/ruby/2.1.0/rubygems.rb:8:in `require': Interrupt
        from /usr/lib/ruby/2.1.0/rubygems.rb:8:in `<top (required)>'
        from <internal:gem_prelude>:1:in `require'
        from <internal:gem_prelude>:1:in `<compiled>'

[Feature Request] Read private key from environment variable

Heroku, Netlify and many other PaaS are stateless so files don't stick around permanently. And because ejson look up private key from EJSON_KEYDIR file, this can pose a bit of challenge to adopt ejson.

What we know that these platforms uses environment variables as the 1st class citizen, so why don't we look up from environment variable for private key instead?

Here is one example:

Private Key: 123
Public Key: abcdef

The ejson app would try to look for environment variable abcdef before falling back to reading $EJSON_KEYDIR/abcdef file. Alternatively, we could let user define which environment variable to lookup:

{
    "_public_key": "<public key here>",
    "_private_key_env_var": "<the_name_of_the_env_var_that_contains_the_private_key>",
     "SECRET_SHELL_VARIABLE": "<encrypted data>"
}

Any Change Causes All Hashes to be Re-written

Maybe I'm doing something funny here but the readme states

Changes to secrets are auditable on a line-by-line basis with git blame.

However, if I decrypt my file, change a setting and re-encrypt it. Every line has changed.

My git blame shows everything changed by the last commit, not just the one thing I changed/added.

Segmentation fault when running on M1 Macs (Apple Silicon / Darwin arm64)

Hi there,

I've just tested ejson on a M1 Macbook and while it was installed without any issues/errors, it won't run:

$ bundle exec ejson
[1]    80653 segmentation fault  bundle exec ejson

Considerations:

I think the reason why I was able to install is because this line also matches the return of uname -sm in the new architecture:

$ uname -sm
Darwin arm64

It might need to be split like this:

- when /^Darwin/       ; "darwin-amd64"
+ when /^Darwin amd64/ ; "darwin-amd64"
+ when /^Darwin arm64/ ; "darwin-arm64"

I'm happy to provide more information if you need it.

No EOL on encrypt

When doing ejson encrypt, the resulting file is missing a newline symbol on the last line.

Similarly the private keys also do not contain EOL.

unable to install ejson

i tried installing ejson through homebrew but getting error that the formula is not available

[2020-09-22 16:47:07+0530] yogesh@yogesh> brew install ejson
Updating Homebrew...
Error: No available formula with the name "ejson" 
==> Searching for a previously deleted formula (in the last month)...
Error: No previously deleted formula found.
==> Searching for similarly named formulae...
This similarly named formula was found:
generate-json-schema
To install it, run:
  brew install generate-json-schema
==> Searching taps...
==> Searching taps on GitHub...
Error: No formulae found in taps.

AWS KMS support

Proposal: Support for storing the private key encrypted with a given KMS key inside the EJSON document. Decryption of secrets would require permission to decrypt with the KMS key, not access to the unencrypted private key on disk as before.

This is similar to how sops works in how it wraps the private key with KMS and stores it in the yaml file.

Benefits (for applications on AWS):

  • Reduced exposure of the private key. Unencrypted private keys don't need to be stored or shipped anywhere.
  • Much easier to setup since private key file storage & distribution isn't required.
  • No risk of leaking the private key through a misconfigured key storage (S3/KMS/ParameterStore) setup since key storage isn't necessary now.
  • Decryption of secrets is audible through use of the KMS key.
  • Developers that need to view secrets on their machine don't need to put the private key on their filesystem (they just assume a role that has decrypt permission).

I imagine it working like this:

❯ aws-vault exec [profile] -- ejson keygen --kms-key-id [kms_key_id]
Public Key:
[public_key]
Private Key:
[private_key]
KMS Encrypted Private Key:
[private_key_enc_w_kms_key]

❯ # create test.ejson with the above

❯ cat test.ejson
{
  "_public_key": "[public_key]",
  "_kms_encrypted_private_key": "[private_key_enc_w_kms_key]",
  "test": "EJ[...]"
}

❯ aws-vault exec [profile] -- ejson decrypt test.ejson
{
  "_public_key": "[public_key]",
  "_kms_encrypted_private_key": "[private_key_enc_w_kms_key]",
  "test": "sssh! it's a secret"
}

ejson encrypt command throws error - Windows

When I try to use ejson encrypt command I am getting below error

ejson command : ejson encrypt

C:/Ruby25-x64/lib/ruby/gems/2.5.0/gems/ejson-1.2.2/bin/ejson:2:in ``': No such file or directory - uname -sm (Errno::ENOENT)

Platform - Windows 10
ejson version - 1.2.2

ejson fails on ~ in path

☁  spy [downtime_for_icinga] ejson --keydir=~/.ejson keygen -w
Key generation failed: open ~/.ejson/0a7ff372db0702f54219acb91c04348d37625adcde4ad7eabbb3268197a80929: no such file or directory
☁  spy [downtime_for_icinga] touch ~/.ejson/0a7ff372db0702f54219acb91c04348d37625adcde4ad7eabbb3268197a80929
☁  spy [downtime_for_icinga] ls -lha ~/.ejson
total 0
drwxr-xr-x    3 n1ko  staff   102B Mar 20 20:51 .
drwxr-xr-x+ 106 n1ko  staff   3.5K Mar 20 20:52 ..
-rw-r--r--    1 n1ko  staff     0B Mar 20 20:51 0a7ff372db0702f54219acb91c04348d37625adcde4ad7eabbb3268197a80929````

Missing dev instructions

I wanted to fix one of the issues, but I got stuck for a long time just trying to get ejson to build. It would be great if there was a short section in the README about:

  • what go version is expected
  • how are the dependencies managed
  • how to go from git clone ... on a completely clean host, to a built ejson binary

Man files contain an error message string in version 1.0.2 of the gem

I just installed the latest version of ejson and was seeing a really weird error message. After looking into it, I discovered that the actual contents of the ejson*.gz man files contained the error string.

% gem install ejson --version '= 1.0.2'
Fetching: ejson-1.0.2.gem (100%)
Successfully installed ejson-1.0.2
1 gem installed
% PAGER=head ejson
bundler: command not found: ronn Install missing gem executables with `bundle install`










% cd $GEM_HOME/gems/ejson-1.0.2
% gzcat man/man1/ejson.1.gz
bundler: command not found: ronn
Install missing gem executables with `bundle install`
% gzcat man/man1/ejson-decrypt.1.gz
bundler: command not found: ronn
Install missing gem executables with `bundle install`

issue installing and running on MacOS 10.12.5

ejson is functioning after install, but man is failing and it runs with errors.

I'm a java guy, but pretty good at different tooling (python, bash, etc). But totally new to ruby stuff.

On terminal this is what happened. Google and Stackoverflow were not instructive.

Thoughts?

 ~ $ gem install ejson
ERROR:  While executing gem ... (Gem::FilePermissionError)
    You don't have write permissions for the /Library/Ruby/Gems/2.0.0 directory.

 ~ $ sudo gem install ejson
Password:
Successfully installed ejson-1.0.2
Parsing documentation for ejson-1.0.2
1 gem installed

 ~ $ man ejson
No manual entry for ejson

 ~ $ ejson
[this showed up in buffer window like vi:]
bundler: command not found: ronn Install missing gem executables with `bundle install`

 ~ $ bundle install
Could not locate Gemfile or .bundle/ directory

 ~ $ sudo bundle install
Don't run Bundler as root. Bundler can ask for sudo if it is needed, and installing your bundle as root will break this application for all non-root users on
this machine.
Could not locate Gemfile or .bundle/ directory

I did finally get it to work, after I realized that the /opt/ejson/keys directory was only writable by root. After I adjusted that, I could run ejson keygen, ejson encrypt and ejson decrypt but man still doesn't work with the same bundle install error.

Just wanted to pass this along. great tool!!

prevent committing unencrypted secrets by mistake

ejson looks great, but I'm slightly worried that developers might add an unencrypted secret and forget to encrypt it before committing / pushing. I guess we can ask them to add a git hook, but that's also easy to forget, or if you move your dev environment and forget.

I wonder about ways to avoid this. Perhaps having the encrypted file with a different name from the unencrypted one, and .gitignoreing the unencrypted one and only committing the encrypted version? instead of using the same file.

Support for easier use in projects that don't read from JSON files

We are using ejson to store our secrets encrypted in our repos, however, our applications expect settings to be set in the environment rather than reading from a file.

Currently, we use this bit of hackery to load the json settings as env variables:

 echo "${EJSON_PRIVATE_KEY}" | ejson decrypt --key-from-stdin "$(env_file_name)" | jq -r '. | delpaths( env | keys + (keys | map("_"+.)) + ["_public_key"] | map([.]) ) | to_entries | .[] | "declare -x " + (.key | gsub("^_"; "")) + "=" + (.value | @sh)' > /tmp/env
    . /tmp/env
    rm /tmp/env
    env -u EJSON_PRIVATE_KEY "$@"

This is kind of a mess and I would love it if ejson supported writing out json content in a way that was easy to consume into an environment.

How would you all feel about a contribution that outputs the json content in a format like:

if [ -z ${KEY+x} ]; then
  declare -x "KEY"="VAL"
fi

for each variable so that it can be easily consumed by *sh for loading into shell environments before starting applications?

Weird behaviour if space between key and colon

If I have a valid json file like

{
  "_public_key": "827ec2078b64d83e1a0bebdedd8769289d4e5ef1e03403da3a4c60407fb0d516",
  "foo" : "bar",
  "bar": "foo"
}

(note the space between foo and :)

running ejson encrypt gives me

{
  "_public_key": "827ec2078b64d83e1a0bebdedd8769289d4e5ef1e03403da3a4c60407fb0d516",
  "foo" "foo" : "EJ[1:wKT8j2st5FPH/nx/vDyHJWDD+5VleU1+sDq+/LjnQUU=:u7OOwFwSdY9RQvRPOh/fxXywYdGUwJ7C:7xnqT7iVubp7e8kaR7hu7NGeSw==]",
  "bar": "EJ[1:wKT8j2st5FPH/nx/vDyHJWDD+5VleU1+sDq+/LjnQUU=:ZfGGyhDrjufcsZZK3Ik+q4ESoSc61hxQ:Hh+ofr0O6lW9fv0jis8RHC4rdw==]"
}

ejson on M1

Installing ejson on M1 fails because it fails installing ffi (1.9.18) .

┃ An error occurred while installing ffi (1.9.18), and Bundler cannot continue.
┃ 
┃ Make sure that `gem install ffi -v '1.9.18' --source 'https://rubygems.org/'`
┃ 
┃ succeeds before bundling.

After some digging, I found that ffi version 1.14.0 fixes Mac M1 compatibility issues.

I tried this version on my m1 machine and it works.

Can we update the ffi version that ejson uses to v1.14.0+?

Add support for suffix/prefix for encrypting

Currently ejson doesn't encrypt keys starting with _ which can be a good default.
We are trying to make it explicit which keys need to be encrypted by using a suffix _encrypted.

Do you think this would be a good idea for ejson as an optional flag ?

Permission denied to create /opt/ejson/keys on MacOS (Big Sur v11.1)

I'm getting Permission denied for default installation instructions

➜ mkdir -p /opt/ejson/keys

mkdir: /opt/ejson/keys: Permission denied

if I force it with sudo then it will fail a bit later:

➜ ejson keygen -w              

Key generation failed: open /opt/ejson/keys/60d0a301cb16469fe74dc09f6390003515f4c78ebb4b1b12074c06c9e7d0b64c: permission denied

ejson prints non-errors to stderr

In a385d6d a change was made to print errors to stderr. It also changed the output for encrypt and keygen to also go to stderr. Since these are not errors they should probably go to stdout

Any plans to release with upgraded golang?

We have been using the ejson utility in some of our projects and recently attempted to deploy one of our images with ejson and were stopped due to CVE's related to the golang version for the 1.2.1 release.

CVE Severity
CVE-2018-16874 Medium
CVE-2018-16873 Medium
CVE-2017-15042 Medium
CVE-2019-11888 High
CVE-2018-6574 High
CVE-2018-16875 High
CVE-2019-17596 Medium
CVE-2017-15041 High

I was able to update the go modules and recompile with go version 1.14.3 and the scanning tool no longer flagged anything with ejson. Just wondering if there are any plans for a new release with a newer version of golang.

goreleaser / GitHub Actions

EJSON's binary releases are compiled on a developer machine.
Given EJSON's place low in the stack, users trust it to handle keys and decrypted secrets. Building release binaries in ephemeral CI would provide greater assurance they haven't been tampered with.

Another Shopify OSS project, toxiproxy, recently adopted goreleaser to compile artifacts and configured release build on GitHub Actions. Could EJSON do that too?

Related

Go implementation

I'd PR this, but it has no code in common with the previous ruby implementation, so it wouldn't provide a whole lot of value.

Instead, see https://github.com/Shopify/ejson

Highlights:

  • Implements EJSON v1.0 RFC except with nacl/box instead of PKCS7.
  • Elliptic Curve Crypto rather than Prime Factorization (RSA)
    • DJB code rather than OpenSSL code
    • Relative difficulty of ECC problem allows much shorter keys and ciphertexts => more tractable EJSON files
  • Makefile generates rubygem and debian package
    • Saner distribution to production nodes
  • Simplified key management
    • /opt/ejson/keys directory contains files named with full public key, containing private key.
    • ejson decrypt looks up key referenced by ejson file in /opt/ejson/keys
  • We can link this codebase into our container init script so that we don't have to shell out to ruby for decryption.
  • Improved tests

I'll keep poking at this over the next couple of days, but it's basically ready for feedback. The code is pretty well compartmentalized and documented; I don't think it'll be very hard to grok what's going on. Start with README.md, then ejson.go and cmd/ejson/*.go.

Review/cc any combination of: @Shopify/stack, @Shopify/secops. It can easily wait until BFCM if you're busy.

Asset for darwin/arm64 wasn't released at ejson v1.4.0

Asset for darwin/arm64 wasn't released at ejson v1.4.0.

https://github.com/Shopify/ejson/releases/tag/v1.4.0

image

Release workflow succeeded but the following warning was outputted and the asset for darwin/arm64 wasn't built.

https://github.com/Shopify/ejson/actions/runs/4872615287/jobs/8691044230#step:6:30

         • DEPRECATED: skipped darwin/arm64 build on Go < 1.16 for compatibility, check https://goreleaser.com/deprecations/#builds-for-darwinarm64 for more info.

Support enryption for multiple public keys

Hey,

would like to be able to encrypt the contents of a single ejson file for several public keys.
The idea is to have a list of keys in a git repo so that everyone is able to encrpt secret files for all of the keys and add the encrypted ejson to the git repo.

In the ejson file, the value of "_public_key" could be a list of public keys instead of a single key.
encrypt => encrypt for each key (encrypt symmetrically, encrypt symm. key for each public key)
decrypt => try to find the private key for any of the listed public keys and decypt

Any chance to have this supported?

Strings not interpolated

I installed via rubygem and get strings not being interpolated when encrypting.

➜  secrets git:(master) ejson encrypt env.dev.ejson
Wrote %d bytes to %s.
463env.dev.ejson⏎

Can _public_key be removed from the decrypted output?

Terraform is complaining about _public_key not being a known root level key, so I would love an option to remove the public key from the decrypted output.

As an aside the help text (ejson --help) bundle install fails when calling ejson --help, (requesting bundle install - which also fails due to lack of a Gemfile).

Ejson not supported on your platform

If I run ejson on a Raspberry Pi 3 B+ I get the following error:

Ejson is not supported on you platform

Is there any support planned for Raspberry Pi?

Public key with repo

hey @burke what do you think about saving the public key with the repo? It's pretty hard to ask ops give you public key from databag everytime we want to update keys.

Encryption failed: public key has invalid format

Failure

~/t/ejson_tutorial ❯❯❯ uname -a
Darwin xxxxxxxx.local 22.2.0 Darwin Kernel Version 22.2.0: Fri Nov 11 02:08:47 PST 2022; root:xnu-8792.61.2~4/RELEASE_X86_64 x86_64
~/t/ejson_tutorial ❯❯❯ ejson --version
ejson version 1.3.1
~/t/ejson_tutorial ❯❯❯ cat test.ejson
{
  "_public_key": "<key>",
  "_database_username": "1234username",
  "database_password": "1234password"
}
~/t/ejson_tutorial ❯❯❯ ejson encrypt test.ejson
Encryption failed: public key has invalid format
~/t/ejson_tutorial ❯❯❯ echo $EJSON_KEYDIR                                  ✘ 1 
/opt/ejson/keys
~/t/ejson_tutorial ❯❯❯ ejson keygen -w
18c17aae0d07962805723d30330f9b61d7d6274e8e7ce9fdf2d9dd8ed8664f19
~/t/ejson_tutorial ❯❯❯ ejson encrypt test.ejson
Encryption failed: public key has invalid format

Changes from `1.1.0` to `v1.2.1`

The latest version is v1.2.1 while the last (and the only) entry in CHANGELOG.md is 1.1.0.

Is there any breaking change between these versions?

Will CHANGELOG.md be updated?

Thanks! 🙏

Secret meta schema

Each secret should require the following metadata fields be populated. Secret meta should probably be stored in plain text, as it's not actually secret. We might want to implement this using the comment format described in #3

Ejson should refuse to encrypt (or at least bitch heavily) if every secret that it is encrypting does not have the an associated secret meta field with the following attributes:

    "secret_type" : "#{AWS|SSH|SSL|PASSWORD|TOKEN|OAUTH|OTHER}",
    "severity" : "#{LOW|MED|HIGH}",
    "notes" : "effect of key if leaked",
    "external_urls" : [
      "urls to apps and / or hosts where this credential is used"
    ],
    "rotation" : "url or plaintext instructions"

It probably makes sense to add a yaml file or something similar to the ejson gem to describe what the required fields for the secret meta are, so that this can be overridden, or have the secret meta feature be disabled entirely by 3rd parties not at shopify who want to use ejson without this feature.

Additionally, ejson should maintain a sequential version number on each secret. This will allow us to automatically determine if the credential has been rotated (it should probably also therefor not allow the user to specify this field or override it when encrypting).

I think that the following format makes the most sense:

{
  "my_secret" : {
    "_some_comment" : "some comment about this secret that isn't secret meta"
     "secret" : "the actual encoded secret here"
     "__meta__" : {
       (metadata described above)
     }
  }
}

@burke for thoughts

linux-amd64 binary for 1.1.0?

We install ejson in an alpine docker image and are stuck on 1.0.2 because there is no binary available for 1.1.0.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.