git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: Git documentation at kernel.org

From
KRKonstantin Ryabitsev <icon@mricon.com>
Date
Feb 10, 2012, 18:55 UTC
Message-ID
<1328900154.3171.27.camel@i5.mricon.com>
In-Reply-To
<FC56A942-EE70-48B7-A2D3-CF53A189A55E@mit.edu>
On Fri, 2012-02-10 at 13:00 -0500, Theodore Tso wrote:
Show 8 quoted lines
> 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
Previous: Theodore TsoNext: Ted Ts'o
Message 6 of 21 in “Git documentation at kernel.org”
  1. Petr OnderkaFeb 7, 2012
  2. Clemens BuchacherFeb 8, 2012
  3. Junio C HamanoFeb 10, 2012
  4. Matthieu MoyFeb 10, 2012
  5. Theodore TsoFeb 10, 2012
  6. Konstantin RyabitsevFeb 10, 2012
  7. Ted Ts'oFeb 10, 2012
  8. Junio C HamanoFeb 10, 2012
  9. Ted Ts'oFeb 10, 2012
  10. Junio C HamanoFeb 10, 2012
  11. Jeff KingFeb 10, 2012
  12. Junio C HamanoFeb 10, 2012
  13. Jeff KingFeb 10, 2012
  14. Matthieu MoyFeb 12, 2012
  15. Jeff KingFeb 12, 2012
  16. Scott ChaconFeb 12, 2012
  17. Jeff KingFeb 13, 2012
  18. Junio C HamanoFeb 13, 2012
  19. Jeff KingFeb 14, 2012
  20. Konstantin RyabitsevFeb 13, 2012
  21. Neal KreitzingerFeb 10, 2012

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.