Yum deltarpm

[Ahmed Kamal]

The most recent code is at:
http://people.redhat.com/~herrmann/deltarpm/

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! It's not really the drpm's fault.

Yes the old code is focused on up2date. It will take some cleaning. And I am
all for dropping the server side code completely. drpms are to be generated
by a cron-job and *not* on the fly as is the current implementation. So, the
servers should not be running additional software.

On 1/13/07, Toshio Kuratomi <a.badger at gmail.com> wrote:
>
> On Sat, 2007-01-13 at 20:40 +0200, Ahmed Kamal wrote:
> > FYI, this yum deltarpm support, is based on that same deltarpm package
> > that is made by suse. This suse package can create new rpms from drpm
> > + (either ondisk files, or old rpm). Either way, a new rpm is created,
> > then installed. Never does it replace files directly. Not sure why
> > this would be bad security wise
>
> It's the construction of the rpm from ondisk files that I don't like.
> You lose the ability to sign the rpm that you're installing.  Patching
> an older rpm is a safer transformation.
>
> I just googled and found an August post to yum-devel about what I think
> is this plugin:
>
> https://lists.dulug.duke.edu/pipermail/yum-devel/2006-August/002385.html
>
> Is this right?  Is there more recent code?  It looks like that code is
> tied into up2date so it wouldn't help Fedora users much.  It also needs
> a server side which implies the mirrors would have to run additional
> software to make it functional....
>
> -Toshio
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.fedoraproject.org/pipermail/infrastructure/attachments/20070114/2255885f/attachment.html