[ovirt-devel] [Important!][Action required!] CI-whitelist re-activated

[Martin Sivak]

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.
>
> [1]: https://ovirt-jira.atlassian.net/browse/OVIRT-1154

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 at 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 at redhat.com
> RHCE, RHCi, RHV-DevOps Team
> https://ifireball.wordpress.com/
> _______________________________________________
> Devel mailing list
> Devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel