[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

dpkg, verify, testing.

dpkg developers,

I care deeply about my users, and was saddened to find that one of them
has corrupted his system when updating libc6. The deb itself had been
corrupted, the frontend didn't notice and dpkg (rather dpkg-deb)
partially unpacked data.tar.gz and his system was toast.

I would like to propose a minor change to dpkg, the ability to run the
unpack phase in verification mode first.

Where is dpkg development right now? 

I've already made the required changes on a local tree, and I'm in the
process of finishing a small testsuite that exercises some of the
extract functionality. There are about 10 test right now of various
types of package corruption that expect that 'dpkg-deb -x' should fail,
warn, and never ever partially unpack anything unless it passes a

The verification phase was trivially easy, just run extracthalf() once
with the taroptions set to 't'. If anything fails, the error handlers
catch the failure. If it doesn't fail then extracthalf() is run again
with the standard 'xp' options.

I think dpkg needs to be made safer, hopefully I can do my part. I know
the code is a little hairy in places, I've cleaned up parts of extract.c
to make it more legible and understandable.

I'm not talking about a fundamental change here, I'm not even talking
about the merits of unapcking in place vs. unpacking in /tmp and
verifying. Rather just a simple dry run through the unpack process to
make *absolutely* sure it doesn't go sour. It doesn't even have to be
turned on for all the packages, rather just a critical subset.

Please cc.


p.s. I'm on the nm queue.

Reply to: