[Important!][Action required!] CI-whitelist re-activated
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/
On Tue, Feb 21, 2017 at 7: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.
Like this: git clone https://gerrit.ovirt.org/jenkins-whitelist Send a patch like this one: https://github.com/oVirt/jenkins-whitelist/commit/fd24902b24a53f4b14ef88a4ac...
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
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:
How can the maintainer trigger the CI for a 3rd party patch? We won't merge anything that didn't pass the tests first so we need a way to trigger them. -- 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
On Tue, Feb 21, 2017 at 10:23 PM, Martin Sivak <msivak@redhat.com> wrote:
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:
How can the maintainer trigger the CI for a 3rd party patch? We won't merge anything that didn't pass the tests first so we need a way to trigger them.
Triggering the patch manually does not work, even if a valid user trigger the build. My poor workaround was to upload the next version of a patch. In vdsm we can also run the tests on travis. After your setup travis on your fork in github, you can push the change to github to test it like this: git review -d patch-number git push github Using: $ git remote -v | grep github github git@github.com:nirs/vdsm.git (fetch) github git@github.com:nirs/vdsm.git (push) Interesting that Travis is not worried about everyone running CI, no whitelist is needed :-)
-- 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
Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
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
Just think about the goals we have (like getting a real developer community) while fixing it.
Btw, I just found a project that uses whitelist - kubernetes. But they make it very easy for maintainers to accept patches. Check for example this pull request: https://github.com/kubernetes/kubernetes/pull/41119 The idea I like is that the CI will immediately tell me what needs to be done in the comments. No need to search through documentation for the right keyword. - The bot told the contributor who the relevant maintainers are, computed the list of people with enough permissions and notified them too. And just a comment by maintainer was needed to enable CI for the pull request. - The same for failing tests - they provide the command to retrigger it directly in the message It all basically boils down to "Do not make me think" approach. Everything that needs to be done is immediately obvious without searching. And that I could accept even with the whitelist enabled. Martin On Tue, Feb 21, 2017 at 9:45 PM, Martin Sivak <msivak@redhat.com> wrote:
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
On 22 Feb 2017, at 10:45, Martin Sivak <msivak@redhat.com> wrote:
Just think about the goals we have (like getting a real developer community) while fixing it.
Btw, I just found a project that uses whitelist - kubernetes. But they make it very easy for maintainers to accept patches. Check for example this pull request: https://github.com/kubernetes/kubernetes/pull/41119
The idea I like is that the CI will immediately tell me what needs to be done in the comments. No need to search through documentation for the right keyword.
- The bot told the contributor who the relevant maintainers are, computed the list of people with enough permissions and notified them too. And just a comment by maintainer was needed to enable CI for the pull request. - The same for failing tests - they provide the command to retrigger it directly in the message
It all basically boils down to "Do not make me think" approach.
I agree with everything you said (in this thread, that is;-), thanks. It’s more like “Do not force me to go through email archives and waste more time than it took me to fix the damn code” approach
Everything that needs to be done is immediately obvious without searching. And that I could accept even with the whitelist enabled.
Martin
On Tue, Feb 21, 2017 at 9:45 PM, Martin Sivak <msivak@redhat.com> wrote:
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
Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
participants (4)
-
Barak Korren -
Martin Sivak -
Michal Skrivanek -
Nir Soffer