'We're mostly concerned that some kind of sensitive data finding it's way into our repo would result in that same data being duplicated in Greenkeeper somewhere.'
Greenkeeper does not clone the repos at all. We do explicitly keep permanent copies of parts of your package.json files and your greenkeeper.json config file, if you have the latter. So from this, we have your project names, greenkeeper and the following fields from all your package.json files:
- name
- dependencies
- devDependencies
- optionalDependencies
- peerDependencies
- greenkeeper
- engines
- maintainers
- author
So even if you store sensitive data in your package.json files, we throw that way before storage, as long as it isn’t stored in one of the keys in this list.
In addition, we receive webhooks from GitHub that notify us of all changes to files in your repos, so we can see when your package or config files change. However, we throw away all events that don’t concern these files:
- package.json
- package-lock.json
- npm-shrinkwrap.json
- yarn.lock
- greenkeeper.json
From this, we store which lockfiles you have and where in the repo they live, so we get folder names inside repositories if you use monorepos, which means that theoretically we’d know what your project’s components are called. We also get branch names and commit messages for these files.
So even if you do end up accidentally committing env files or certificates or user data, we never get those (save for the very unlikely case described above). When greenkeeper-lockfile updates your lockfiles on your CI (where it does have access to the entire repo), we have no access to the repos or the runs, and no logs are produced on our machines.
'We're mostly concerned that some kind of sensitive data finding it's way into our repo would result in that same data being duplicated in Greenkeeper somewhere.'
Greenkeeper does not clone the repos at all. We do explicitly keep permanent copies of parts of your
package.jsonfiles and yourgreenkeeper.jsonconfig file, if you have the latter. So from this, we have your project names, greenkeeper and the following fields from all yourpackage.jsonfiles:So even if you store sensitive data in your package.json files, we throw that way before storage, as long as it isn’t stored in one of the keys in this list.
In addition, we receive webhooks from GitHub that notify us of all changes to files in your repos, so we can see when your package or config files change. However, we throw away all events that don’t concern these files:
From this, we store which lockfiles you have and where in the repo they live, so we get folder names inside repositories if you use monorepos, which means that theoretically we’d know what your project’s components are called. We also get branch names and commit messages for these files.
So even if you do end up accidentally committing env files or certificates or user data, we never get those (save for the very unlikely case described above). When greenkeeper-lockfile updates your lockfiles on your CI (where it does have access to the entire repo), we have no access to the repos or the runs, and no logs are produced on our machines.