You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
'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.
The text was updated successfully, but these errors were encountered:
'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 yourgreenkeeper.json
config file, if you have the latter. So from this, we have your project names, greenkeeper and the following fields from all yourpackage.json
files: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.
The text was updated successfully, but these errors were encountered: