On 01-07-28 Marcus Brinkmann wrote:
> On Sat, Jul 28, 2001 at 12:49:13PM +0200, Christian Kurz wrote:
> > But, our packages are not only available burned on CD, but from lots of
> > ftp servers, where they are located on a writable media, called hard
> > disk. So, the packages can still be modified and a checksum changed so
> > that you won't notice it. Also you forget that the package and the
> > md5sum are generated on a system about which you have absolutely no
> > information and can't make any assumption about it's security and if
> > it's trustworthy or not. So, I find your argumentation above absolutely
> > not legaly, as you are not looking at the whole problem.
s/legaly/logical/
> The point I am trying to make is, that self-generating the checksums
> introduces a single point of failure, my system. If every maintainer
> generates them themselve, some packages might have wrong checksums, but in
> general this would not affect the checksums in other packages. Also, the
Which will stail undermine your plan of verifying which binaries are
modified or damaged, because you'll still only be able to verify a part
of the packages and not all like you want to achieve it.
> checksums can be verified by lintian, the upload queue daemons, dinstall,
Are you aware that there's already a md5sum for the .dsc, .orig.tar.gz
or .tar.gz, the .diff.gz if it exists and the .deb that you are
uploading the .changes file, which is again signed by your key? So
dinstall will already verify those checksums (By the way, dput already
does verify them before uploading. ;) lintian shouldn't in my opionion
calculate and verify checksum, but instead check the compliance of the
package to the policy and look for packaging errors. The upload queue
daemons shouldn't do any check, because like their name suggested they
are just queues for helping out with uploads. The check should always be
done by dinstall and that's what happening currently.
> mirrors, CD creators and all users individually, so they will get a thorough
If mirrors and CD creators will really need and want to check them is
something about which I don't want to make assumptions. How shall
mirrors check the checksums which are stored inside a package?
Completely extract it and then check it and repackage it? And for Users
this will only be a small help, since for example those md5sums won't
work on config-files or files which are created at or after runtime of a
program without being included in deb.
> For the maintainers/builders machine, the best we can hope for is that the
> checksum matches the contained files. There is *nothing* in our process
> which makes sure that those files are sane, except for the maintainers
> careful work to protect the packages he builts. If the maintainers build
Right and until we can assure that every machine used to build a system
is not broken in any way, that the maintainers are careful enough to
create the package and md5sum correctly, I'm not very fond of "forcing"
to include md5sums everywhere.
> whole build might be broken (contain a trojan etc). Providing wrong
> checksums, which don't match the packages files, would only make the attacker
> to reveal himself.
But still a attacker could place a trojan inside a package, create a new
md5sum for the while files and the package and install it into the
archive.
> Have I made it more clear this time what the difference is?
Partly, but I still think this is the wrong approach.
Christian
--
Debian Developer (http://www.debian.org)
1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853
Attachment:
pgp_TB2pI6HLX.pgp
Description: PGP signature