<     May 2017     >
Su Mo Tu We Th Fr Sa  
    1  2  3  4  5  6  
 7  8  9 10 11 12 13  
14 15 16 17 18 19 20  
21 22 23 24 25 26 27  
28 29 30 31
00:09 adwin joined
00:27 dave0x6d joined
01:42 rodarmor joined
02:29 parkr joined
02:52 rickmak_ joined
03:04 kingarmadillo joined
04:05 kingarmadillo joined
04:21 hcpl joined
04:38 ski7777 joined
04:42 rickmak_ joined
05:24 Diaoul joined
05:51 lpin joined
06:06 kingarmadillo joined
06:16 rickmak joined
06:19 timwis joined
06:20 MJD joined
06:20 dmj` joined
06:21 yena joined
06:21 yo61 joined
06:21 Gankro joined
06:25 infernix joined
07:05 mtodor joined
07:05 lpin joined
07:37 lislis joined
07:39 lislis joined
07:51 ssbarnea joined
08:07 kingarmadillo joined
08:28 rickmak_ joined
08:39 lislis joined
08:54 rickmak joined
09:13 Cloudflare joined
09:16 rickmak joined
09:23 SimonVT joined
09:24 timeless joined
09:41 jcrugzz joined
09:52 petems joined
10:26 albanc joined
11:08 kingarmadillo joined
11:13 kingarmadillo joined
11:18 kingarmadillo joined
11:23 kingarmadillo joined
11:28 kingarmadillo joined
11:33 kingarmadillo joined
11:38 kingarmadillo joined
11:39 itaipu joined
11:40 ixti joined
11:43 kingarmadillo joined
11:48 kingarmadillo joined
11:50 jantman joined
11:53 kingarmadillo joined
11:58 kingarmadillo joined
12:03 kingarmadillo joined
12:08 kingarmadillo joined
12:13 kingarmadillo joined
12:18 kingarmadillo joined
12:23 kingarmadillo joined
12:28 kingarmadillo joined
12:30 kingarmadillo joined
12:35 kingarmadillo joined
12:40 kingarmadillo joined
12:45 kingarmadillo joined
12:50 kingarmadillo joined
12:55 kingarmadillo joined
13:00 kingarmadillo joined
13:05 kingarmadillo joined
13:07 notebox joined
13:09 itaipu joined
13:10 kingarmadillo joined
13:15 kingarmadillo joined
13:20 kingarmadillo joined
13:22 davehunt joined
13:25 kingarmadillo joined
13:30 kingarmadillo joined
13:35 kingarmadillo joined
13:40 kingarmadillo joined
13:45 kingarmadillo joined
13:50 kingarmadillo joined
13:55 kingarmadillo joined
14:00 npmccallum joined
14:00 kingarmadillo joined
14:05 kingarmadillo joined
14:10 kingarmadillo joined
14:15 kingarmadillo joined
14:20 kingarmadillo joined
14:22 sean797 joined
14:23 <sean797> I have a build that wont start due to " GitHub payload is missing a merge commit (mergeable_state: "unknown", merged: false) ". it had a merge conflict but i have since resolved it
14:23 <sean797> any ideas?
14:25 kingarmadillo joined
14:30 kingarmadillo joined
14:35 kingarmadillo joined
14:40 kingarmadillo joined
14:44 strk joined
14:45 kingarmadillo joined
14:50 zupo joined
14:51 kingarmadillo joined
14:51 <strk> I'm a bit confused by secure variables - is there any way to allow PRs to have access to secure variables IFF the owner of the fork knows that secret ?
14:51 Meow-J joined
14:51 <strk> am I correct that "Environment Variables" as set from the repository-setting would serve that purpose ?
14:54 yrashk joined
14:54 jeffreylevesque joined
14:55 <jantman> strk - not really. "that secret" is a per-repository encryption key, that *nobody* should really know
14:55 zupo_ joined
14:55 <jantman> there's some information about secure variables in the docs
14:55 <jantman> but the bottom line is each project (repo) on Travis has a unique encryption key, and that's used to encrypt secure variables
14:56 kingarmadillo joined
14:56 <strk> are "Environment Variables" never considered "secure" ?
14:56 <strk> to be honest I fail to see the actual security... it's actually a secret you share with all Travis builders, right ?
14:57 <mtodor> sean797: try to push new commit, sometimes build is not triggered after rebase -> force push
14:59 <jantman> well it's a secret that Travis generates
15:00 <jantman> IIRC the implementation is a bit more complicated than that... but the bottom line to the actual security is that (1) you can put it in .travis.yml and it's meaningless to anyone who sees it, unless they've severely compromised the Travis infrastructure, and (2) you can't see it in plain text anywhere unless you explicitly print or echo it
15:00 kingarmadillo joined
15:01 <jantman> my understanding is that it's not a secret you share with *all* Travis builders... it's a secret that Travis generates for each repo, and presumably is only given to builders that are running jobs for your repo
15:02 <jantman> you could probably find out more by looking at the Travis API docs and the code of the `travis` ruby gem... and maybe other places in the public Travis codebase
15:05 kingarmadillo joined
15:07 <strk> well obviously builders will need that secret, so no matter how: they will get the secret
15:07 <strk> if it wasn't needed, we wouldn't put it in there
15:08 <jantman> ok sorry, I thought you were talking about the encryption key, not the value...
15:08 <jantman> yes, it's a secret that you share with all Travis builders... it's intended for things (secrets) that your tests need, but you don't want people looking at
15:09 <jantman> i.e. if you have acceptance tests that need to authenticate to some API or hosted service, you'd use the secure variables to store your creds, so the tests have access to them but random people can't see them in your repo
15:09 lorenzo joined
15:10 <strk> what if I put those values in environment variables defined via the repository setting ?
15:10 kingarmadillo joined
15:11 <strk> would those variables be inspectable by all forks or just those with code in the repository defining it ?
15:11 <strk> ^it^them
15:11 <jantman> you mean in the web UI?
15:11 <strk> yes
15:12 <jantman> the forks will not have access to them at all, aside from when your repo is building PRs
15:12 <jantman> if you define them in the web UI, they belong to *that circle project*, not the code
15:13 <jantman> beyond building pull requests from forks, there's no connection at all on the Travis side between your repo and forks of it
15:13 <strk> so the build from *any* PR (even those with PR code in a fork) would have access to that env variable ?
15:14 <jantman> as long as you have fork pull request building enabled, yes
15:14 <strk> say I define SECRET=a in my repository R1 setting
15:14 <strk> you fork it to R2, having read access to R1
15:14 <strk> then you add code sending $SECRET to your server and open a PR
15:14 <strk> travis builds, and leaks that secret ?
15:14 <strk> is that how it would work ?
15:14 ixti joined
15:15 <jantman> ok hang on, let's step back a minute
15:15 <jantman> if you define SECRET=a as a *regular* (not secure) environment variable, it will show up in plaintext output of every build
15:15 kingarmadillo joined
15:16 <jantman> can I ask why you don't just test this?
15:16 <jantman> ok, I was wrong about part of that
15:16 <jantman> https://docs.travis-ci.com/user/environment-variables/
15:17 <jantman> https://docs.travis-ci.com/user/environment-variables/#Defining-encrypted-variables-in-.travis.yml
15:17 <mtodor> does anyone knows, is there any workaround for artifacts upload to work with eu-central-1?
15:17 <jantman> "Encrypted variables are not available to untrusted builds such as pull requests coming from another repository."
15:18 <strk> *encrypted* though
15:18 <strk> but I don't see from the UI a way to define *encrypted* variables. Unless that's done by default when using the UI
15:18 <strk> (UI does not say)
15:19 <jantman> I'm pretty sure you can't define encrypted variables in the UI
15:19 <jantman> granted, I've never done... anything... through the UI, aside from adding new repos
15:20 <jantman> you define encrypted variables by encrypting a string with the travis command line tool
15:20 <strk> jantman: basically I'm trying to find out a way to allow share secrets with selected forks
15:20 <jantman> or, presumably, via the API
15:20 <jantman> ahhh
15:20 kingarmadillo joined
15:20 <strk> ie: I give you the secret, you put it in your fork, and then can send PRs whose builds have access to that secret
15:21 <strk> because putting the secrets in .travis.yml requires you (the forker) to update .travis.yml too for every PR, and that's not a change I want to merge back
15:21 <jantman> right
15:22 <jantman> so my understanding is you can't do that, because the Travis encryption keys are strictly per-repository
15:22 <jantman> honestly the simplest solution I can think of to that would involve some out-of-band or other encryption scheme
15:26 kingarmadillo joined
15:28 <strk> whatever scheme you use you still need a way to *trust* specific forks
15:28 <strk> it looked promising for repository-setting Environment variables to be only available to builds from that specific repository
15:29 <strk> if that's how it works, it should give me what I'm after
15:29 <strk> of course my approach is based on trusting "trusted-forkers" at least the same than Travis itself
15:30 <strk> ie: being able to give them the secrets
15:30 kingarmadillo joined
15:35 ssbarnea joined
15:35 kingarmadillo joined
15:40 kingarmadillo joined
15:44 <strk> I'm thinking there might be an additional mechanism that would give me the best of the two approaches
15:44 <strk> .travis.yml only referencing the name of an env variable containing the encripted variables
15:44 <strk> that's a possibility, right ?
15:44 <strk> so each fork repo admin would then write encrypted variables in there
15:45 <strk> not sure how that would help, actually..
15:45 kingarmadillo joined
15:50 kingarmadillo joined
15:51 <jantman> so unless there's something major I'm missing (which could be), your options are either (a) give the secrets directly to the trusted forkers, (b) encrypt the secrets yourself (i.e. with GPG or something) and let the trusted forkers manage decrypting in their builds, or (c) now that GitHub has branch restrictions that let you determine which users or teams
15:51 <jantman> can push to which branches, just give the trusted forkers perms to push to specific branches in your origin repo, that will run their tests
15:55 kingarmadillo joined
16:00 kingarmadillo joined
16:05 tobias1 joined
16:05 kingarmadillo joined
16:06 mtodor joined
16:06 <strk> jantman: yup, I'm evaluating (a) at the moment, but wanted to be sure that those who do not have those secrets cannot find it in the main repository settings
16:07 <strk> (b) would not be much different, only more complex...
16:07 <strk> (c) would be different in that contributors would not need to know the secret
16:07 <jantman> unless I'm missing something, nobody outside of your Travis account should be able to see your repo settings
16:08 <strk> every repo writer, I guess
16:08 <strk> (or admin)
16:08 <strk> actually those can *write* the env variable, but the value is indeed not shown
16:09 <strk> unless "Display value in build log" is activated, there should be no way to read that variable (other than explicitly printing it in .travis.yml recipes)
16:10 kingarmadillo joined
16:15 kingarmadillo joined
16:18 <jantman> or in any code in the build
16:21 kingarmadillo joined
16:26 kingarmadillo joined
16:27 <strk> right, still triggered by .travis.yml recipe
16:30 kingarmadillo joined
16:32 Sound joined
16:35 kingarmadillo joined
16:39 Sound_ joined
16:40 kingarmadillo joined
16:46 kingarmadillo joined
16:50 kingarmadillo joined
16:54 yo61 joined
16:54 adw1n joined
16:55 kingarmadillo joined
17:01 kingarmadillo joined
17:06 kingarmadillo joined
17:11 kingarmadillo joined
17:16 kingarmadillo joined
17:17 lislis joined
17:21 kingarmadillo joined
17:26 kingarmadillo joined
17:31 kingarmadillo joined
17:36 kingarmadillo joined
17:41 kingarmadillo joined
17:43 lasconic joined
17:44 fkautz joined
17:46 kingarmadillo joined
17:51 kingarmadillo joined
17:52 `3rdEden joined
17:56 kingarmadillo joined
18:01 kingarmadillo joined
18:03 yena joined
18:04 andrewstewart joined
18:06 kingarmadillo joined
18:09 itaipu joined
18:09 notebox joined
18:11 kingarmadillo joined
18:11 machty joined
18:15 MLM__ joined
18:16 kingarmadillo joined
18:21 kingarmadillo joined
18:26 kingarmadillo joined
18:31 kingarmadillo joined
18:36 kingarmadillo joined
18:41 kingarmadillo joined
18:46 kingarmadillo joined
18:49 JSharp joined
18:51 kingarmadillo joined
18:59 lislis joined
19:11 bmcorser joined
19:16 ljharb joined
19:44 kingarmadillo joined
20:08 emdantrim joined
20:47 Anticom joined
22:10 meatballhat joined
22:15 kus joined
22:22 jeffreylevesque joined
23:25 drupol joined
23:53 gyre007 joined