Date: Thu, 8 Feb 2001 18:37:39 -0800 From: Jeremy Lea <reg@FreeBSD.ORG> To: Wes Peters <wes@softweyr.com> Cc: Wes Peters <wes@FreeBSD.ORG>, cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG Subject: Re: cvs commit: src/usr.sbin/pkg_install/sign Makefile README check.c common.c extern.h gzip.c gzip.h main.c pgp.h pgp_check.c pgp_sign.c pkg_sign.1 sha1.c sign.c stand.c stand.h x509.c Message-ID: <20010208183738.J8780@shale.csir.co.za> In-Reply-To: <3A810D78.6669D9D2@softweyr.com>; from wes@softweyr.com on Wed, Feb 07, 2001 at 01:55:20AM -0700 References: <200102060646.f166kgf65013@freefall.freebsd.org> <20010206022059.G8780@shale.csir.co.za> <3A810D78.6669D9D2@softweyr.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi, On Wed, Feb 07, 2001 at 01:55:20AM -0700, Wes Peters wrote: > Yes, but on the other hand, it works now. In pkg_add, there is some > finite point in time at which you have all the bits available and haven't > yet started stuffing files onto the system; this is the ideal point in > time to check a signature and abort the installation. All we have to > do is identify that spot in the code and arrange to check the signature > in a way to that doesn't muck up the rest of the code any more than > necessary, right? It occurs in the current pkg_add in perform.c:pkg_do() at the point where we use the "--extract-only" flag for tar (grep for that). At this point we extract +CONTENTS, +COMMENT and +DESCR from the tarball - or these are already sitting in the playpen allocated to the fetch command. At this point we could either also extract +CERT, or check for a @comment (or @sign - but we can't implement new @ commands without breaking backwards compatibility - the contents file needs a API version...), which contains a signature which signs the packaging list (up too but not including the @sign line). We verify the signature, hence validating the MD5's and then we check the MD5s of all of the files in the package. > I like the idea of storing the signature in the actual tar data, rather > than the gzip header, because it makes it independent of the compression > format. Keep in mind that an X.509 certificate can be bigger than a > filename size, I'm not sure how the @comment is actually represented in > the tarball. The cpio format is actually somewhat more flexbile for > these kinds of shenanigans. I'd prefer to see us move to .zip files. We can put the entire +CONTENTS file into the comment field, and the zip format includes checksums, so we verify the checksums in the zip header against the signed +CONTENTS, and rely on unzip to complain about a checksum mismatch during decompression. > I'm sorry I haven't been more responsive, I'm interested in working with > you to flesh this out for the next step in the package tools. Do you have > some code or a design document I can look at? At http://people.freebsd.org/~reg/ is the code, although it hasn't been updated for the last round of changes by Jordan and Maxim - I'm still trying to work these into the design properly. There is also a small discussion about the design, although I need to expand that a lot more for it to be considered a 'design document'. If you are looking at the code, the best place to start is lib/lib.h - you can get a pretty good idea of how the design works by looking at the hierarchy of structures from the PkgMgr down. Regards, -Jeremy -- FreeBSD - Because the best things in life are free... http://www.freebsd.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010208183738.J8780>