Hi, now the longer version..
We (the infra team) know that the current mechanism can sound draconian and be inconvenient. But we had to put something in place quickly. Please join the discussion at [1] to improve it.
The JIRA issue deals with automating the whitelist. But the whitelist by itself is a wrong solution. Let me explain why I think we should do stuff (very) differently: 1) automation directory is part of sources This allows any pull request to configure the CI scripts for itself, that is indeed dangerous and is one of the reasons why I do not like it (Travis has the same issue). The automation (and build matrix) configuration should be limited to maintainers which means we need a separate repository with project configuration for it (I keep telling you that something distgit-like is what we need) 2) no patch can be merged without CI approval and maintainers are commonly not even looking at patches without CI+ flag The whitelist will create another barrier to entry for anybody wanting to contribute just a random patch or two. Most of my contributions to other project fall exactly in that category - fixing the one thing that bothers me and moving on. Our code presents a barrier that is already high enough for that and making it even higher won't win us any more contributors. 3) most projects I know about limit what you can do during build or use monitoring and blacklists Fedora does not allow you to access network during builds at all, copr does, but you can be banned. The same Git Hub / Travis where you are allowed to do anything, but you can be banned for abusing the system. You do not have to be whitelisted first to configure Travis CI or to submit a copr job. Fedora used to require a sponsor and a GPG signed CLA, but the requirement was removed. We are again moving against the crowd here. Unfortunately I really feel we are again hacking around something and repeating other's mistakes instead of designing a proper solution while learning from others. But the current CI was indeed a security hole, there is no questioning that. Just think about the goals we have (like getting a real developer community) while fixing it. Regards Martin Sivak oVirt / SLA On Tue, Feb 21, 2017 at 6:53 PM, Barak Korren <bkorren@redhat.com> wrote:
TL;DR: If you are a patch author, please ask your project maintainer to have you added to the CI whitelist.
The oVirt CI system tries to be a useful and powerful tool for patch authors and project maintainers. With the current CI-standards, power is placed in the hands of patch authors to make the system do almost anything.
We try to be an "open" Open-Source project, so permission is given to anyone to open a Gerrit account and submit patches.
The above opens the door to the CI system being maliciously exploited, so some countermeasure was needed. The builders of the CI system foresaw this and have put in place a white-list mechanism that makes the CI system only run jobs for patches that come from listed authors.
In recent years the CI system had been re-engineered with the push towards the CI standards, and the whitelist mechanism was rendered non-active.
Finally realizing the potential for harm, we acted quickly to re-enable the whitelist mechanism. We made an effort to include current authors and maintainers, but we do not know everyone. People not included in the whitelist will see the following message when submitting patches:
To avoid overloading the infrastructure, a whitelist for running gerrit triggered jobs has been set in place, if you feel like you should be in it, please contact infra at ovirt dot org
If you come across this message, please ask the project maintainer to send a message to the infra team asking for you to added to the CI whitelist. We'd rather not receive direct messages from individual contributors, because we do not know everyone and cannot verify sources.
We (the infra team) know that the current mechanism can sound draconian and be inconvenient. But we had to put something in place quickly. Please join the discussion at [1] to improve it.
[1]: https://ovirt-jira.atlassian.net/browse/OVIRT-1154
-- Barak Korren bkorren@redhat.com RHCE, RHCi, RHV-DevOps Team https://ifireball.wordpress.com/ _______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel