Dpl: Deploy to Github Pages with a deploy key instead of a token

Created on 28 Sep 2017 · 20Comments · Source: travis-ci/dpl

https://github.com/travis-ci/dpl#github-pages currently needs a GitHub oauth token with the repo permission in order to commit to the gh-pages branch. Storing a github token as a TravisCI secret has the side-effect that anyone with write access to the repository can steal the ability to commit to any repository as me. So it'd be nice if the github-pages deployment would let me use a single-repository deploy key instead.

We're doing this manually in repositories like https://github.com/heycam/webidl/blob/master/deploy.sh and https://github.com/w3c/permissions/blob/master/deploy.sh. The basic strategy is to use travis encrypt-file on the key, and pass the decrypted version to ssh-add before trying to git push.

pages (GitHub Pages) stale

Source

jyasskin

👍21

Most helpful comment

@slifty that's why protect your secrets :)
I cannot see what else could be done except for adding a deploy key instead of token. I think, if this PR lands, I'd be thinking of deprecating token argument in favor of it or at least putting big red warning there in docs.
A good thing I see in implementing this provider in travis's default toolset is that there's now a possibility to improve people's literacy in terms of security: before this, there were lots of different guides to follow, they all didn't urge readers about impact of using a personal token. Now, however, it may become possible to teach users some bits of security.

webknjaz on 17 Feb 2018

👍4

All 20 comments

@jyasskin this side-effect usually isn't an issue, because travis stores secure vars bound to user's encryption key, so other person won't see values of vars you encrypted from within their account.

webknjaz on 25 Nov 2017

👎1

@webknjaz https://docs.travis-ci.com/user/encryption-keys/#Fetching-the-public-key-for-your-repository says it's a public/private keypair for the repository, not the user.

Even if it were a keypair for the user, anyone with write access to the .travisci script could add an echo $SECURE_VAR|base64 command to print the secret to the log. (|base64 hides it from the log's filter that replaces the literal secret with "[secure]".)

jyasskin on 26 Nov 2017

👍1

@jyasskin fair enough.

It looks like Travis already generates a keypair (doc) for each repo and the public key is exposable via travis pubkey command.

The problem is that it's unclear where's the private part of that key. There's nothing in ~/.ssh dir.

@BanzaiMan Can we reuse that existing key somehow? I couldn't find anything in fs or env vars.
Is it the same this doc refers to as one being used for fetching private deps?

webknjaz on 26 Nov 2017

It looks like a user key can only be set for travis-ci.com accounts, not travis-ci.org, but if we can find instructions that match the travis-ci.org UI, and it hides the key from other committers, that could replace this change.

jyasskin on 27 Nov 2017

@jyasskin I'm talking about auto-generated key, which is present in travis-ci.org and isn't bound to user, but to the repo. It wouldn't produce commits on the behalf of human user. We just need to figure out where the private key resides in the build box.

webknjaz on 27 Nov 2017

Ah, I see, https://developer.travis-ci.org/resource/key_pair_generated discusses a single key for each repository used for git operations by default, and shows how to get its public key. We could have folks set that key as the deploy key for 1 respository that the pages dpl provider pushes to, but https://docs.travis-ci.com/user/private-dependencies/#Deploy-Key mentions that github won't allow that key to be used for 2 or more deployments.

I believe the single-repo restriction would be fine for my purposes, so if that's what @BanzaiMan wants to do, I can update the patch.

I don't think we need explicit access to that private key; it's just used by default? I can test this if that's the direction we want to go.

jyasskin on 27 Nov 2017

@jyasskin I've tested ssh -Tvvvvv [email protected] and saw that it results in permission denied and looking up for keys in ~/.ssh only. They probably use it differently somehow.

webknjaz on 27 Nov 2017

👍1

@BanzaiMan Do you have any insight on https://github.com/travis-ci/dpl/issues/694#issuecomment-347016558?

webknjaz on 5 Jan 2018

@BanzaiMan could you please clarify that question about pre-existing key?

webknjaz on 18 Jan 2018

@BanzaiMan any info?

webknjaz on 26 Jan 2018

Just wanted to chime in to say that this raised my red flags as well; I don't like the idea of putting any form of peer / contributor access to a token that gives the ability to push to any of my public repositories into a scriptable environment.

I may be missing something, but even if contributors can't see the key, couldn't they write scripts with encrypted access to the value that therefore have the capability to overwrite the content of ANY of my public repositories?

Put another way, by using my access token as an encrypted variable in a travis repository isn't it the case that I'm giving write permission to ALL my repositories to anybody who has write access to this one? If so, that seems like an incredibly serious op-sec fail.

slifty on 17 Feb 2018

❤3

webknjaz on 17 Feb 2018

👍4

Thanks for contributing to this issue. As it has been 90 days since the last activity, we are automatically closing the issue. This is often because the request was already solved in some way and it just wasn't updated or it's no longer applicable. If that's not the case, please do feel free to either reopen this issue or open a new one. We'll gladly take a look again! You can read more here: https://blog.travis-ci.com/2018-03-09-closing-old-issues