*.py packaging, again

[Tomasz Pala]

On Thu, Jul 14, 2011 at 07:21:35 -0400, Jeff Johnson wrote:

>>> compiles stuff? If so, can we then launch a suid helper that injects
>>> the newly created files into the rpm package that contained the
>>> original .py?
>> 
>> OMG...
>> Please don't mess with rpm database in indeterministic time (like some
>> runtime) and do NOT use SUID.
>> 
>> This is excelent example of what I've called 'overcomplicated'.
>> 
> 
> And you comments (which I agree with) are negatively phrased.
> 
> State what you want to see positively.

1. I don't know python internals, but if these cache files are not
strictly machine-dependant (i.e. they don't differ on machines having
the same arch) they should be shipped in compiled form (otherwise we
might as well end up with %_make; %configure; ... in %build of every
package) - this is not gentoo.

2. if anything wants to alter rpm database, it must be done during
transaction or shortly after it (i.e. within installation process); it's
not acceptable to do changes there during regular system use (on
unprivilidged account) - after all it's MD5 repo and might be
hard-locked by admin.

3. install -> compile -> save to rpmdb is pointless - saved MD5 might be already
compromised by some malicious software and thus undetectable even via
verification run from outer source (i.e. rescuecd). Checksums must be
calculated in clean environment and be comparable between different
systems (so we're back to point 1).


Otherwise we might just put some
rm -f /usr/share/python/**/__pycache__/* to cron or %post of python
pkgs to ensure that no malicious/leftovers will harm our system. If the
files are to be regenerated by regular user, why not remove them once a
week to save space?

> Or prepare yourself for
> the SUID audit that will inevitably be attempted.

SUID is broken by design and obsoleted (and disabled entirely on some
machines). Are we talking about CAP_DAC_OVERRIDE?

-- 
Tomasz Pala <gotar at pld-linux.org>