# VCS Account Request: jenkins - Thread: https://externals.io/message/65568 - Original archive: https://news-web.php.net/php.internals/65568 - Started by jenkins on 2013-02-03T12:30:22+00:00 - Messages: 11 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #65568 — jenkins — 2013-02-03T12:30:22+00:00 URL: https://externals.io/message/65568#65568 this account will be used to keep the ci.qa.php.net jenkins installation\'s config file in sync with the web/jenkins git repo. --- ## #65569 — Ferenc Kovacs — 2013-02-03T12:33:11+00:00 URL: https://externals.io/message/65568#65569 · In reply to: #65568 > this account will be used to keep the ci.qa.php.net jenkins > installation\'s config file in sync with the web/jenkins git repo. > > > -- > > > > hi, I requested this one, please approve it and also grant him karma for web/jenkins.git -- Ferenc Kovács @Tyr43l - http://tyrael.hu --- ## #65570 — Pierre Joye — 2013-02-03T13:10:22+00:00 URL: https://externals.io/message/65568#65570 · In reply to: #65569 hi, > > > > […] > hi, > > I requested this one, please approve it and also grant him karma for > web/jenkins.git I really do not think that we should give write access to some web exposed bot to any of your repositories. We never allowed that in the past and I do not think we should begin to do that. For what I understand from Ferenc's explanation on IRC, it is about being to store the configuration changed done via the web frontend in git. As the idea itself is good (having that in the repo is good), I would rather go the other way round, modify the configuration in the repo by human being. Configurations can be exported or fetched relatively easily. Cheers, -- Pierre @pierrejoye --- ## #65571 — Ferenc Kovacs — 2013-02-03T14:18:44+00:00 URL: https://externals.io/message/65568#65571 · In reply to: #65570 > hi, > > > > […] > > I really do not think that we should give write access to some web > exposed bot to any of your repositories. We never allowed that in the > past and I do not think we should begin to do that. > > For what I understand from Ferenc's explanation on IRC, it is about > being to store the configuration changed done via the web frontend in > git. As the idea itself is good (having that in the repo is good), I > would rather go the other way round, modify the configuration in the > repo by human being. Configurations can be exported or fetched > relatively easily. > > Cheers, > -- > Pierre > > @pierrejoye > Hi, 99% of the changes to the jenkins configuration files (/config.xml, /job/*/config.xml) will be done through the admin interface, and I don't think that anybody here would be able to edit these files manually without tripping over something. So the other was around solution would require either 1, to have a development environment, where you do the changes, then fetch the changes in the xml files, then commit and push those changes, then log in to the jenkins admin and pull the changes (then restart jenkins if required). or 2, to change it on the jenkins admin, then fetch the changes in the xml files(this would require having ssh account there), then commit & push. I think that 1, is would be too cumbersome to be used and 2, would require giving out ssh accounts and would prone people not fetching and pushing the changes when they do change something. The plugin that I wanted to use ( https://wiki.jenkins-ci.org/display/JENKINS/SCM+Sync+configuration+plugin) would allow the changes to be pushed/pulled from the jenkins allow interface and would also show the current status (changes not pushed, etc.) so it is less likely to we forget to do it. Personally I'm not convinced about the security implications (as this is a separate repository and nothing else would use this repo for anything else), but if you think this is a major concern, I can use my personal github account for storing the configs for the time being. I just thought that it would be better to keep them on git.php.net, thats all. ps: some background info: some of the config files were lost when the previous ci.qa.php.net went down and I want to prevent that from happening ever again. -- Ferenc Kovács @Tyr43l - http://tyrael.hu --- ## #65642 — Florian Anderiasch — 2013-02-04T17:43:51+00:00 URL: https://externals.io/message/65568#65642 · In reply to: #65571 > > […] Wouldn't it be a possibility to just create a github repo and allow key access only there? Greetings, Florian --- ## #65643 — Ferenc Kovacs — 2013-02-04T17:49:32+00:00 URL: https://externals.io/message/65568#65643 · In reply to: #65642 On Mon, Feb 4, 2013 at 6:43 PM, Florian Anderiasch wrote: > > > > […] > > Wouldn't it be a possibility to just create a github repo and allow key > access only there? > > Greetings, > Florian > Yeah, this what I mentioned by 'I can use my personal github account for storing the configs for the time being'. If you mean creating a repo under the http://github.com/php then I think it would be a little bit confusing, because all of the repos there are only mirrors for the ones on http://git.php.net/ -- Ferenc Kovács @Tyr43l - http://tyrael.hu --- ## #65645 — johannes@schlueters.de — 2013-02-04T18:07:38+00:00 URL: https://externals.io/message/65568#65645 · In reply to: #65643 > > Yeah, this what I mentioned by 'I can use my personal github account for > storing the configs for the time being'. > If you mean creating a repo under the http://github.com/php then I think it > would be a little bit confusing, because all of the repos there are only > mirrors for the ones on http://git.php.net/ Another approach might be that jenkins commits locally and the git server pulls itself via cronjob or something. No idea whether that's more useful, just throwing ideas out. johannes --- ## #65646 — Ferenc Kovacs — 2013-02-04T18:13:01+00:00 URL: https://externals.io/message/65568#65646 · In reply to: #65645 On Mon, Feb 4, 2013 at 7:07 PM, Johannes Schlüter wrote: > > > […] > think it > > […] > > Another approach might be that jenkins commits locally and the git > server pulls itself via cronjob or something. > > No idea whether that's more useful, just throwing ideas out. > > johannes > > > yeah, that would work also, but it has some of the concerns that were mentioned about the git push way: if you somehow compromise the jenkins box, you can get rouge commits to the jenkins git.php.net repo. as I mentioned, I think I will use some 3rd party repo(github probably) for the configs and manually merge stuff to the web/jenkins repo on git.php.netonce in a while. -- Ferenc Kovács @Tyr43l - http://tyrael.hu --- ## #65647 — Florian Anderiasch — 2013-02-04T18:14:21+00:00 URL: https://externals.io/message/65568#65647 · In reply to: #65646 > yeah, that would work also, but it has some of the concerns that were > mentioned about the git push way: > if you somehow compromise the jenkins box, you can get rouge commits to > the jenkins git.php.net repo. > as I mentioned, I think I will use some 3rd party repo(github probably) > for the configs and manually merge stuff to the web/jenkins repo on > git.php.net once in a while. I omitted "if people are against giving the bot access" - that's why I suggested GitHub - and I know it's usually only mirroring, but why not add new repos for "different security contexts" there? (With a big "not mirrored warning ofc") Greetings, Florian --- ## #65651 — johannes@schlueters.de — 2013-02-04T21:13:57+00:00 URL: https://externals.io/message/65568#65651 · In reply to: #65646 > yeah, that would work also, but it has some of the concerns that were > mentioned about the git push way: > if you somehow compromise the jenkins box, you can get rouge commits to the > jenkins git.php.net repo. > as I mentioned, I think I will use some 3rd party repo(github probably) for > the configs and manually merge stuff to the web/jenkins repo on > git.php.netonce in a while. Well, when having the git server pulling: what could happen? - An attacker might write new revision of config files. It can't do forced pushes or such to hide his traces, the attacker can't abuse the account for other things like deleting notes oder manipulating bug reports. But then again: I have no idea about the nature of config files :-) johannes --- ## #67521 — PHP Group — 2013-05-25T15:48:54+00:00 URL: https://externals.io/message/65568#67521 · In reply to: #65568 VCS Account Rejected: jenkins rejected by rasmus /o\