The most recent code is at:

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 <> 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:

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....