It looks like cached patches are truncated to the nearest 1024-byte
boundary in the patch body. E.g.:
> mricon@nikko:[/tmp]$ wget -O no-cache
> "http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/patch/?id=6e1b4fdad5157bb9e88777d525704aba24389bee"
...
> 2014-06-11 15:34:51 (80.4 MB/s) - ‘no-cache’ saved [4767]
Patch is complete, without truncation. Next hit, with cache in place:
> mricon@nikko:[/tmp]$ wget -O yes-cache
> "http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/patch/?id=6e1b4
> fdad5157bb9e88777d525704aba24389bee"
...
> 2014-06-11 15:35:01 (17.0 MB/s) - ‘yes-cache’ saved [4096/4096]
Length truncated to 4096. The cache on disk looks truncated as well, so
the bug must me during the process of saving cache. The same is true for
larger patches:
> mricon@nikko:[/tmp]$ wget -O no-cache
> "http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/patch/?id=2840c566e95599cd60c7143762ca8b49d9395050"
...
> 2014-06-11 15:41:33 (1.07 MB/s) - ‘no-cache’ saved [979644]
979644 bytes with a cache-miss
> mricon@nikko:[/tmp]$ wget -O yes-cache
> "http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/patch/?id=2840c
> 566e95599cd60c7143762ca8b49d9395050"
...
> 2014-06-11 15:41:46 (1.05 MB/s) - ‘yes-cache’ saved [978944]
978944 (956KB exactly) with a cache-hit
Since the "html" functions use raw write(2) to STDIO_FILENO, we don't
notice problems with most pages, but raw patches write using printf(3).
This is fine if we're outputting straight to stdout since the buffers
are flushed on exit, but we close the cache output before this, so the
cached output ends up being truncated.
Make sure the buffers are flushed when we finish outputting a patch so
that we avoid this.
No other UIs use printf(3) so we do not need to worry about them.
Actually, it's slightly more interesting than this... since we don't set
GIT_FLUSH, Git decides whether or not it will flush stdout after writing
each commit based on whether or not stdout points to a regular file (in
maybe_flush_or_die()).
Which means that when writing directly to the webserver, Git flushes
stdout for us, but when we redirect stdout to the cache it points to a
regular file so Git no longer flushes the output for us.
The patch is still correct, but perhaps the full explanation is
interesting!
Reported-by: Konstantin Ryabitsev <mricon@kernel.org>
If you search for a bogus range string here:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/log/
Using something like "range" and "qwerty123456", it returns an "Internal
Server Error" and the following in the logs:
> [Tue Jun 10 17:45:32 2014] [error] [client 172.21.1.6] fatal:
> ambiguous argument 'qwerty123456': unknown revision or path not in the
> working tree., referer:
> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/
> [Tue Jun 10 17:45:32 2014] [error] [client 172.21.1.6] Use '--' to
> separate paths from revisions, like this:, referer:
> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/
> [Tue Jun 10 17:45:32 2014] [error] [client 172.21.1.6] 'git <command>
> [<revision>...] -- [<file>...]', referer:
> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/
> [Tue Jun 10 17:45:32 2014] [error] [client 172.21.1.6] Premature end
> of script headers: cgit, referer:
> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/
The cache will kick in, so if you search for the same string again,
it'll show an empty range, so you have to change the bogus strings each
time.
This is because we just pass the arguments straight to Git's revision
parsing machinery which die()s if it cannot parse an argument, printing
the above to stderr and exiting.
The patch below makes it a bit friendlier by just ignoring unhandled
arguments, but I can't see an easy way to report errors when we can't
parse revision arguments without losing the flexibility of supporting
all of the revision specifiers supported by Git.
Reported-by: Konstantin Ryabitsev <mricon@kernel.org>
prefixcmp() and suffixcmp() have been remove, functionality is now
provided by starts_with() and ends_with(). Retrurn values have been
changed, so instead of just renaming we have to fix logic.
Everything else looks just fine.
For example, if I have two repos (remove-suffix is enabled):
/foo
/foo/bar
http://cgit/foo/bar/ is interpreted as "repository 'foo', command 'bar'"
instead of "repository 'foo/bar'"
The check in parse_user that eventually makes it into committer_date and
tagger_date is:
else if (mode == 3 && isdigit(*p)) {
*date = atol(p);
mode++;
}
Since isdigit('-') is always false, date will never be negative. Thus
the sign of this function:
static int cmp_age(int age1, int age2)
{
if (age1 != 0 && age2 != 0)
return age2 - age1;
if (age1 == 0 && age2 == 0)
return 0;
if (age1 == 0)
return +1;
return -1;
}
Will always be the same as the sign of this function:
static inline int cmp_age(int age1, int age2)
{
return age2 - age1;
}
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Idea-by: Lukas Fleischer <cgit@cryptocrack.de>
I have a number of repositories that start tagging with just '1' and
count up. Actually references with sting length of one are skipped, this
patch changes that.
If time-to-live is set to zero, we don't need to regenerate the cache
slots on every request. Instead, just skip the caching process and
immediately provide the dynamically generated version of the page.
Setting time-to-live to zero is useful when you want to disable caching
for certain pages.
Signed-off-by: Lukas Fleischer <cgit@cryptocrack.de>
This can be used to specify the TTL for snapshots. Snapshots are usually
static and do not ever change. On the other hand, tarball generation is
CPU intensive.
One use case of this setting (apart from increasing the lifetime of
snapshot cache slots) is caching of snapshots while disabling the cache
for static/dynamic HTML pages (by setting TTL to zero for everything
except for snapshot requests).
Signed-off-by: Lukas Fleischer <cgit@cryptocrack.de>
Right now if you visit:
<http://git.zx2c4.com/systemd/diff/src/udev/udev-builtin-input_id.c?id=bcfce235>
you'll see that if you reload the page a few times, a bunch of times the
diffstat comes out with no lines being shown or changed. I'm not
currently sure what the cause of this is, but I suspect it might have to
do with this uninitialized data.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Some people may clone the cgit repository and compile within a sandbox
or on another machine where git is not necessarily installed. When it
happens, cgit is getting compiled with an empty version number.
This commit fixes this.
This breaks compat with the previous LUA_IMPLEMENTATION but gives more
flexibility in that user can specify the pkg-config package name
directly.
Signed-off-by: Natanael Copa <ncopa@alpinelinux.org>
sendfile() does the same job and avoids to copy the content into userland
and back. One has to define NO_SENDFILE in case the OS (kernel / libc)
does not supported. It is disabled by default on non-linux environemnts.
According to the glibc, sendfile64() was added in Linux 2.4 (so it has
been there for a while) but after browsing over the mapage of FreeBSD's I
noticed that the prototype is little different.
Signed-off-by: Sebastian Andrzej Siewior <sebastian@breakpoint.cc>
Drop the context parameter from the following functions (and all static
helpers used by them) and use the global context instead:
* cgit_print_http_headers()
* cgit_print_docstart()
* cgit_print_pageheader()
Remove context parameter from all commands
Drop the context parameter from the following functions (and all static
helpers used by them) and use the global context instead:
* cgit_get_cmd()
* All cgit command functions.
* cgit_clone_info()
* cgit_clone_objects()
* cgit_clone_head()
* cgit_print_plain()
* cgit_show_stats()
In initialization routines, use the global context variable instead of
passing a pointer around locally.
Remove callback data parameter for cache slots
This is no longer needed since the context is always read from the
global context variable.
Signed-off-by: Lukas Fleischer <cgit@cryptocrack.de>
This also gives us some CSRF protection. Note that we make use of the
hmac to protect the redirect value.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
This leverages the new lua support. See
filters/simple-authentication.lua for explaination of how this works.
There is also additional documentation in cgitrc.5.txt.
Though this is a cookie-based approach, cgit's caching mechanism is
preserved for authenticated pages.
Very plugable and extendable depending on user needs.
The sample script uses an HMAC-SHA1 based cookie to store the
currently logged in user, with an expiration date.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
* Rename the capitalize-* filters to dump.* since they also dump the
arguments.
* Add full argument validation to the email filters.
Signed-off-by: Lukas Fleischer <cgit@cryptocrack.de>
This did not really break anything in the past since spaces are ignored
when rendering HTML. Remove the preceding space anyway to prevent from
potential future problems.
Signed-off-by: Lukas Fleischer <cgit@cryptocrack.de>
* Validate the email filter by manipulating stdin. Additional checks for
all the arguments can be added in a later patch.
* Add the exec prefix to all informational messages.
* Rename the filter repository to filter-exec. The Git repository itself
is not renamed since it can be shared amongst all filter types.
* In the filter checks, check whether all arguments are passed properly
instead of validating the buffer/stdin only.
Signed-off-by: Lukas Fleischer <cgit@cryptocrack.de>
Filters can now indicate a status back to cgit by means of the exit code
for exec, or the return value from close for Lua.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Christian Hesse