Re: [jgit-dev] Veryfing paths in the incoming pack

[Shawn Pearce <spearce@xxxxxxxxxxx>]

On Wed, Dec 14, 2011 at 11:22, Pawel Kozlowski
<pkozlowski.opensource@xxxxxxxxx> wrote:
> I'm looking into ways of veryfing incoming pack. The requirement is to
> scan incoming trees and reject the pack if certain path patterns are
> present in one of the trees. What I'm looking for here is the way to
> prevent people from pushing commits with certain file types (for
> example - jar files).
>
> Was browsing through jgit sources and I can see that there is a
> org.eclipse.jgit.lib.ObjectChecker that I can set on the PackParser.
> My idea was along those lines: subclass ObjectChecker  and override
> the checkTree method. Am I on the right track here? I wonder if the
> ObjectChecker  is a proper place to perform such paths-checks?

It depends on what you are trying to do.

During checkTree() you only see the names as they appear in this tree.
That is for the file paths in the repository:

  src/org/foo/Thing.java
  src/org/bar/Other.java

when checking the top level tree, you only see "src", when checking
that tree, you only see "org" (and have no knowledge this is from
"src"). If all you want to do is look at a file name and reject names
that match "*.jar" or "*.zip" you may be able to do this within an
ObjectChecker. But it wasn't the intended use for an ObjectChecker.

> Alternativelly I was looking into the PreReceiveHook but my impression
> is that this hook is called when all the object are alredy in the git
> object database and the only thing I could do is to prevent updating a
> ref.

Correct. The objects are already stored by the time the PreReceiveHook
is invoked.

An ObjectChecker is run at different phases during the pack being
consumed off the network. Parts of it are written to disk by the time
the ObjectChecker is invoked, but only to a temporary file. If the
ObjectChecker rejects something the temporary file will be removed. An
evil client can still order the pack stream in such a way as to send a
huge blob and then later send the trees at the end, causing a lot of
temporary disk space to be used until that tree can be found and
reject the item by name. But we have that object limit feature now.
:-)