Yum deltarpm

[Elliot Lee]

On Jan 13, 2007, at 5:11 PM, Ahmed Kamal wrote:

> We should be able to sign the drpms (not sure yet!) Reconstructing  
> the new rpm from ondisk files, doesn't look bad security wise,  
> because the new data is signed. If the on disk files are not  
> trusted, this means the system is already compromised!

Installed files get modified for reasons other than a hacked system.  
Think about config files that the sysadmin edits after a package is  
installed. Think about documentation files, whose may not be  
installed at all. Think about dealing with file conflicts between  
installed packages. Run 'rpm -Va' on a sample of Fedora systems and  
tell me that all those changes just don't matter... And make sure to  
talk to a sysadmin who has had to recover from a rootkit-ed system,  
and tell them that the rootkit'd files will get rolled into their  
newly installed packages if drpm is enabled during recovery.

Relying on the integrity of installed files when generating and  
applying rpm diffs is just a bad idea, period. It's a hack that  
relies on hope instead of best practices, and it gives up the  
guarantees that are a substantial part of rpm's value. Any rpm delta  
solution must produce results that are identical to the original  
desired file, down to the last byte.

Maybe there is a clever way to use a network server and local  
installed files, along with the rsync algorithm, to generate a .rpm  
file that is guaranteed to be byte-for-byte identical to the desired  
file. Mix BitTorrent technology in there, and there is plenty of room  
for innovation without resorting to a really bad hack. :)

Best,
-- Elliot