On Wed, Jun 11, 2014 at 08:07:12PM +0300, Nikolai Kondrashov wrote:
On 06/11/2014 06:19 PM, Lukas Slebodnik wrote:
>On (11/06/14 17:28), Nikolai Kondrashov wrote:
>>It will expand macros, which can include Lua scripts, and those can do
>>basically anything. See
http://www.rpm.org/wiki/PackagerDocs/RpmLua
>>
>>Try putting %{lua: os.execute('echo "Hello, world!"')} into a
spec file and
>>running "sudo yum-builddep" on it.
>>
>It isn't valid argument. You can execute a shell command from C source code.
> system("echo "Hello, world!");
>
>Solution:
>We should not push any patch to CI without reading code.
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?
btw if you're concerned about CI running untrusted code as rpm scriptlets,
isn't the same issue with the code submitted? What if someone submits a
patch to CI that calls system(3) from one of the processes running as root?
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?
A developer having added such a rule would be open to an attack such as
installing a keylogger or a traffic sniffer. The attacker would only have to
create a .spec file with the appropriate content and execute "sudo
yum-builddep" on it under the user's account.
Also, with this approach the user would need to add *two* sudo rules instead
of one: another one for "yum install".
Still, this is not the worst part of this, IMO, but the unnecessary complexity
is.
>>>>A package missing from CI dependencies would be immediately obvious as
CI
>>>>builds would fail and it would be easy to then update the lists.
>>>RPM dependencies are subset of CI dependencies.
>>>
>>>you can install CI dependencies with yum install and sssd dependencies with
>>>yum-builddep
>>
>>Sure, but this will be more complicated than just installing them with
>>yum-builddep.
>>
>Sorry,
>You did not persuade me.
>I still prefer to to reuse build dependencies from spec file.
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?
>In spec file, you can use different packages for different OS.
>e.g.
> %if 0%{?rhel5_minor} >= 7
> BuildRequires: openldap24-libs-devel
> %else
> BuildRequires: openldap-devel
> %endif
>
>Everything is possible to solve it in bash script, but it will be another
>complication. This is a reason why I want to avoid any duplicity.
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.