#2072 closed defect (fixed)

enable Travis-CI for the main Tahoe-LAFS repo

Reported by: daira Owned by: warner
Priority: normal Milestone: soon (release n/a)
Component: dev-infrastructure Version: 1.10.0
Keywords: security travis github Cc:
Launchpad Bug:

Description

Travis-CI is a virtual-machine-based continuous integration system, which does various neat things like annotating pull requests with the results of testing a build.

I've added a single-purpose travis-tahoe github user to confirm that this works with Tahoe-LAFS. Here are the successful results for that user's fork of the tahoe-lafs repo: https://travis-ci.org/travis-tahoe/tahoe-lafs

Unfortunately Travis requires a github user with admin rights over the repo it is reporting on. We need to decide whether to grant those rights for the main tahoe-lafs/tahoe-lafs repo.

(The Tahoe-LAFS commit to add the configuration file for Travis build testing is on master already. By itself it has no security consequences.)

Change History (23)

comment:1 Changed at 2013-09-01T01:06:50Z by daira

  • Keywords brians-opinion-needed added

comment:2 Changed at 2013-09-01T02:38:35Z by daira

Also see #1810 #2052.

Last edited at 2013-09-01T02:41:08Z by daira (previous) (diff)

comment:3 Changed at 2013-09-01T15:20:56Z by zooko

I posted a request to the travis-ci twitter account:

https://twitter.com/zooko/status/374190039355232257

comment:5 Changed at 2013-09-01T16:14:33Z by daira

I asked on the Travis ticket:

As a workaround, would it work to enable Travis and then afterward revoke the github user's admin permission (leaving it with read permissions, and not revoking the OAuth grant)?

roidrage answered:

You can certainly try that combination. Whether it will work in all scenarios, we can't guarantee.

I think we should try this.

comment:6 Changed at 2013-09-01T16:45:33Z by daira

  • Owner set to warner

Brian, please give travis-tahoe temporary admin permission to tahoe-lafs/tahoe-lafs.

comment:7 follow-up: Changed at 2013-09-01T16:47:32Z by daira

Oh hang on, I can test this myself with a different repo, to see whether it will work.

comment:8 in reply to: ↑ 7 ; follow-up: Changed at 2013-09-01T17:35:30Z by daira

Replying to daira:

Oh hang on, I can test this myself with a different repo, to see whether it will work.

Actually I can't, because only an organisation can grant a user other than a repo's owner admin access to that repo. Creating an organisation requires a paid github account.

comment:9 in reply to: ↑ 8 Changed at 2013-09-01T19:27:59Z by daira

Replying to daira:

Creating an organisation requires a paid github account.

I was mistaken about that.

The result of the testing was that you can revoke Administrative access and the status updating still works, but you cannot revoke write (push) access.

Last edited at 2013-09-01T19:28:24Z by daira (previous) (diff)

comment:10 Changed at 2013-09-04T19:31:13Z by warner

I've used travis-ci on a different project (https://github.com/warner/python-versioneer). It's pretty nice. On that one, I revoked it's admin access after adding the post-commit hook which triggers builds. (from what I could tell, the main use case for that access was to simplify the hook installation, and could be done manually by copy/pasting some tokens from travis-ci into github's repo config page). I haven't explored the "mark a revision as passing" feature or what authority it needs.

You can add an IMG tag to the README which will show the current build status for a single branch. That's a non-authority-requiring way to display build status.

Is travis really capable of running our build and test suite? Its buildslaves are all donated by supporters, and impose a pretty strict timeout. The build-in-a-sandbox feature is pretty nice, but my general impression is that it's most suitable for small projects with simple dependencies (e.g. things which are pip-installable). I'll look at the test results you posted.

comment:11 Changed at 2013-09-04T20:59:07Z by warner

Hm, another thought is to run a small daemon on our hardware (org) that polls or watches travis-ci for build results, then uses the github API to update the build-status data. The github repo admin token would then live on our own box, not on the travis box.

comment:12 Changed at 2013-09-04T21:09:14Z by daira

Replying to warner:

Is travis really capable of running our build and test suite? Its buildslaves are all donated by supporters, and impose a pretty strict timeout.

The timeout is 50 minutes, or 10 minutes with no output, which is fine for Tahoe-LAFS' test suite.

Do you think the remaining permission issue is important enough to justify the separate daemon? It seems like quite a bit of work. Personally I don't mind that the travis-tahoe user can commit provided that it can only commit as itself, which I think is the case.

If revoking the admin permission after setting the hook is okay, then please give travis-tahoe admin access to tahoe-lafs/tahoe-lafs (in a new Team so that you can change that permission independently).

comment:13 Changed at 2013-10-02T00:47:17Z by warner

FYI, I've set up travis on some of my own projects with somewhat limited authority. To sign into travis at all, you have to grant it an awful lot of power (the basic OAuth request includes write access to your repositories). But there is an incantation you can speak to Github's API to reduce the scope of the travis-ci oauth token to do less. Before or after you attenuate the token like that, you can go to the travis account page and copy down the travis token. Then you can paste this token into the "travis-ci" service hook on one of your repositories.

Activating the hook with that token will, I believe, cause travis to start building things when you push a new change.

The incantation to attenuate the oauth token is (fill in USER and ID):

curl -u USER https://api.github.com/authorizations
# note the "id" number for the Travis app. Ignore the Gist app.
curl -X PATCH -d'{"remove_scopes": ["public_repo"]}' -u USER https://api.github.com/authorizations/ID
curl -X PATCH -d'{"add_scopes": ["repo:status"]}' -u USER https://api.github.com/authorizations/ID

curl will ask for your github password with each request (it uses HTTP basic auth, over SSL).

One problem with this scheme is that, eventually (I'm not sure exactly when), your travis session will expire, and if you re-"sign in with github", it will replace the attenuated oauth token with a full-power one, and you'll have to do this dance again.

And of course, this attenuation removes travis's ability to automatically configure your repo's hooks for you. I don't think that's a problem: pasting the travis token into the webhook configuration seems to be enough to trigger builds.

And there's still the window of time (after sign-in, before the PATCH api call) during which travis gets full access to your repos.

comment:14 Changed at 2013-10-02T10:55:30Z by daira

I don't think the approach in comment:13 gives enough of a security improvement to be worth the complexity or hassle when the token expires. Shall we just give travis-tahoe admin access then revoke it (i.e. change to write access) after the automatic hook setting as described in comment:12? If I understand correctly, any undesired operations it did with the admin authority (well, other than deleting the repo) would show up in the log for tahoe-lafs/tahoe-lafs that is viewable through the github Web interface. Then, after the revocation, any write to the repo would show up as a push (possibly a force-push) by the travis-tahoe user, so it couldn't write silently.

Last edited at 2013-10-02T10:58:52Z by daira (previous) (diff)

comment:15 Changed at 2013-10-02T11:00:56Z by daira

BTW, setting the hook manually seems to leave the travis Web interface in a state where it doesn't know that the repo has been enabled. That's why I don't want to do it that way.

Last edited at 2013-10-02T11:01:12Z by daira (previous) (diff)

comment:16 Changed at 2013-10-02T12:27:47Z by zooko

I'm okay with any of the authority-managing mechanisms mentioned above.

comment:17 Changed at 2013-10-23T15:15:36Z by zooko

What's the state of this ticket? Somebody move this forward, please! I think the current state is "Brian and Daira disagree about how to do it.", so I think the next-step is for the two of them to come to agreement and then go ahead and implement what they've agreed.

comment:18 Changed at 2013-10-23T15:46:14Z by daira

My last comments were comment:14 and comment:15; I was blocked on warner responding to those. Also I don't have the necessary permissions to grant the admin access (which is fine).

comment:19 Changed at 2014-02-26T15:42:30Z by daira

  • Keywords brians-opinion-needed removed
  • Milestone changed from undecided to soon (release n/a)
  • Owner changed from warner to daira
  • Status changed from new to assigned

https://github.com/travis-ci/travis-ci/issues/1390 has been fixed, so we should revisit this. I still think it's a good idea to use the travis-tahoe user for defence in depth.

Last edited at 2014-02-27T00:44:49Z by daira (previous) (diff)

comment:20 Changed at 2014-03-19T16:30:35Z by zooko

  • Summary changed from decide whether to enable Travis-CI for the main Tahoe-LAFS repo to enable Travis-CI for the main Tahoe-LAFS repo

comment:21 follow-up: Changed at 2014-09-01T15:06:01Z by daira

  • Owner changed from daira to warner
  • Status changed from assigned to new

warner: please add the travis-tahoe github user as a contributor to tahoe-lafs/tahoe-lafs (or alternatively, give the daira user admin access).

comment:22 in reply to: ↑ 21 Changed at 2014-09-01T15:24:50Z by daira

Replying to daira:

warner: please add the travis-tahoe github user as a contributor to tahoe-lafs/tahoe-lafs (or alternatively, give the daira user admin access).

Oh, actually travis-tahoe will still need admin access temporarily to add the webhook. So please give daira admin access, so that I can grant travis-tahoe admin access, turn on the webhook, and then revoke admin.

comment:23 Changed at 2014-09-09T18:27:12Z by daira

  • Resolution set to fixed
  • Status changed from new to closed

Fixed!

We also have build status badges on the tahoe-lafs.org frontpage and README.rst.

Note: See TracTickets for help on using tickets.