[SSSD] [RFC] Add basic support for CI test execution

Nikolai Kondrashov Nikolai.Kondrashov at redhat.com
Tue Jun 24 09:58:34 UTC 2014


On 06/24/2014 09:48 AM, Jakub Hrozek wrote:
> On Wed, Jun 11, 2014 at 08:07:12PM +0300, Nikolai Kondrashov wrote:
>> This is not about *our* spec file. This is about enabling superuser access
>> from user's account. This is about inciting the user to add a sudo rule
>> essentially allowing execution of any code as root without asking for a
>> password.
>
> Where are the packages installed from? It's still only the repositories
> that are enabled on the CI machine, right?

Sure.

> btw if you're concerned about CI running untrusted code as rpm scriptlets,
> isn't the same issue with the code submitted?

No, I'm not really concerned about that.

> What if someone submits a patch to CI that calls system(3) from one of the
> processes running as root?

Well, that would be nice to avoid, and so far I seem to manage that, but it's
not the problem I'm referring to.

> Since the CI machinery runs inside Red Hat firewall, I'm not too concerned
> about this part. Or did you plan on opening the CI to the public?

No, I didn't plan on opening the CI service in the current shape.

This is about developers running CI locally. They will need to either enter
sudo password often when CI starts and tries to install packages, or add a
sudo rule allowing it to do that without asking for a password.

In the case of "yum install" that rule will be relatively safe to have on the
system, in the case of "yum-builddep" it won't, as it essentially allows
executing arbitrary code.

So, using "yum-builddep" in CI would incite developers into adding an unsafe
sudo rule into configuration of their workstations.

Still, this is a minor problem compared to the increased complexity and
lowered reliability of extracting dependencies from a spec file, IMO.

>> I prefer avoiding duplication wherever possible myself, but in this case I
>> think it is not worth it. Besides, with the alternative approach we would in
>> fact be creating duplication of the package list sources and .spec file
>> processing code.
>
> I realize we still need to maintain the list for other distributions.
>
> How, from a CI user perspective would I submit a patch to CI that needs
> an additional dependency?

You would add that dependency to contrib/ci/deps.sh, in the same commit with
the code change requiring it, and CI would honor it when verifying the commit.

>> So far we don't have any conditionals, but I think we can tolerate a few
>> without tipping the complexity scale. Especially considering we're branching
>> for distro families anyway.
>>
>> Let's also hear what others have to say.
>
> Sorry for the delay, this is one of the last threads I have in the
> backlog since my vacation.

No problem, thank you for spending time to read it :)

Sincerely,
Nick



More information about the sssd-devel mailing list