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.
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
hi,
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
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,
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.gitI 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
I requested this one, please approve it and also grant him karma for
web/jenkins.git
Wouldn't it be a possibility to just create a github repo and allow key
access only there?
Greetings,
Florian
On Mon, Feb 4, 2013 at 6:43 PM, Florian Anderiasch florian@anderiasch.dewrote:
I requested this one, please approve it and also grant him karma for
web/jenkins.gitWouldn'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
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
On Mon, Feb 4, 2013 at 7:07 PM, Johannes Schlüter johannes@schlueters.dewrote:
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
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
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 http://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 http://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
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
VCS Account Rejected: jenkins rejected by rasmus /o\