New version of mock working (I think)

Clark Williams williams at redhat.com
Mon Jun 26 21:07:26 UTC 2006


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Michael_E_Brown at Dell.com wrote:
> 
>
>> -----Original Message-----
>> From: fedora-buildsys-list-bounces at redhat.com
>> [mailto:fedora-buildsys-list-bounces at redhat.com] On Behalf Of
>> Clark Williams
>> Sent: Monday, June 26, 2006 3:07 PM
>> To: Discussion of Fedora build system
>> Subject: Re: New version of mock working (I think)
>>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Michael_E_Brown at Dell.com wrote:
>>> Yes, feedback from Dan would be good. My initial thoughts
>> are that a
>>> client implementation would be best at this point, due to
>> the security
>>> implications of a server. Something where we call a server API
>>> provided by plague like:
>>>     server.begin_mock_status( "my.src.rpm", MY_PID)
>>>     server.set_mock_status( "my.src.rpm", "status_string", MY_PID)
>>>     ...
>>>     server.end_mock_status( "my.src.rpm", return_code, MY_PID)
>>>
>> Ah, and you thought I really *meant* it when I said I'd shut up. Ha!
>>
>> Don't you think that a simple server where we just have a
>> listen socket  and respond to "what's your status?" would be
>> more straight forward?
>
> I would like to foster discussion. It would be bad if one of the
> co-maintainers failed to voice their concerns over project direction, so
> no, I would hope that you never shut up.
<aside>

/me hopes everyone takes note of the above.

Please don't construe my opposition to a proposal on the list as
anything personal.  It's just my opinions based on a couple of decades
of programming experience.  My programming philosophy will pretty much
always boil down to: simpler is better.

I can be talked around to solution that I initially oppose. I just
need some encouragement :)

</aside>
>
> My initial thoughts around this is that having an xmlrpc server exposes
> too much of our (running with elevated privs) internals to random,
> untrusted strangers. There has already been one reported vulnerability
> in the python xmlrpc code.
>
> Both code-wise (7-10 lines for client, vs at least 20 for server), and
> security-wise, I think a client would be 'simpler'.
>
> Also, adding a server entices future additions along the lines you
> already said we don't want to go, and starts to supplant plague/brews
> role.

Ok, I can go with that. Probably the most convincing portion of the
above argument is the idea of implementing a root-privilege server as
opposed to pushing that back to the build system maintainers.

So I suppose it means that we should publish a call-out specification
that says: if you invoke mock with the  --server-mumble=X on the
command line, mock will use X as a URL to make an XML-RPC call with
the state  as an argument in <as yet to be determined> form.  We will
then have to wrap that in a try/except and possibly some timeout logic
to make sure that if the other end isn't speaking our language, we
continue or fail in a controlled fashion.

Clark


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFEoEyNHyuj/+TTEp0RAoToAJ9jNUmUqLkyxsAh0HoUNEu94lEq8wCffdIh
YTkO7OshBbqn1eymgtrMP3c=
=pl/z
-----END PGP SIGNATURE-----




More information about the Fedora-buildsys-list mailing list