On Fri, 2012-02-10 at 13:00 -0500, Theodore Tso wrote:
> This would satisfy the security concerns, and it wouldn't be hard, but it would
> require some implementation work. Anyone have some perl hacking time to
> take a look at:
>
> git://git.kernel.org/pub/scm/utils/kup/kup.git
>
> … and add a "UNPACK pathanme" to the kup-server file, and work with the
> sysadmins at kernel.org to get it reviewed and accepted?
I have a few comments off the top of my head:
1. "kup rm" will need to be modified, as it currently only allows
deleting things that have a matching signature. The alternative
is for UNPACK to create a foo.tar.manifest file that will be
consulted upon "kup rm" to clean up any unpacked contents upon
the deletion of the source archive. Note, that there are many,
many gotchas with this solution -- e.g. .manifest should
probably contain checksums, too, as there are bound to be
conditions when two tarballs reference the same files, and you
want to make sure that you delete files matching the contents of
the old tarball, not the newer one, etc.
2. I would suggest that UNPACK ignores any directory structure in
the archive, and only copies over files matching a restricted
set of extensions (.html, .txt, .jpg, .png) into the same dir as
the original tarball. Basically, untar into a temporary
directory, then find any files matching the above set of
extensions, copy them into another temporary location, force
permissions to 0644, and then move them into the final "live"
location in the same dir with the tarball (with the
corresponding .manifest, if that solution used). There should be
logic to make sure that we never overwrite any files that have a
matching .sign file.
3. There should be some support to ensure that the unpack process
is terminated if unpacked content size reaches a certain limit,
or if it is taking too long to complete.
Best regards,
--
Konstantin Ryabitsev
Systems Administrator, Kernel.org
Montréal, Québec
Attachment:
signature.asc
Description: This is a digitally signed message part