Yum deltarpm

[Ahmed Kamal]

Thanks for the reply. The points raised are important and must be validated,
before we implement such a system. I will now try to debunk the FUD ;)

basically, drpm does construct a byte-for-byte rpm that is equivalent to the
new rpm, then it installs that. If constructing such rpm fails for whatever
reason, the drpm operation is aborted, and the system falls back to full
rpms. One more interesting point to note, is that checking whether
constructing a new rpm will be successful, is done prior to downloading the
drpm, so bandwidth usage is kept minimal.

While researching the topic, I found the mandriva folks were having similar
discussions.
http://qa.mandriva.com/show_bug.cgi?id=24535
Comment #13 is from the deltarpm author

I also stumbled upon a forum poll, about adding deltarpm support for 2007 in
Mandriva
http://forum.club.mandriva.com/viewtopic.php?t=52030
http://forum.club.mandriva.com/viewtopic.php?t=52029
Surprisingly most users do think it's nice feature to have. Although not too
many people voted, but that's what we have.

BTW, using bittorrent does not seem like a good idea for yum:
http://wiki.linux.duke.edu/YumTodont


On 1/14/07, Elliot Lee <sopwith at gmail.com> wrote:
>
>
> 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
>
>
> _______________________________________________
> Fedora-infrastructure-list mailing list
> Fedora-infrastructure-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.fedoraproject.org/pipermail/infrastructure/attachments/20070114/3b2cc4a4/attachment.html