Re: [PATCH 0/3] Add support for git's mailmap.
Ack and for edge cases a config entry ignore_mailmap = True On 02.11.2017 21:48, Jason A. Smith wrote: > If people don't need or want this coalescing behavior and want to see > each individual identity then they don't need to make the .mailmap file > to begin with. signature.asc Description: OpenPGP digital signature ___ CGit mailing list CGit@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/cgit
Re: [PATCH] Use https for submodule
Like: Using PKI via https to avoid MITM attacks on git submodule. Regards MonkZ On 19.09.2017 21:18, John Keeping wrote: > Please make use of the commit message to explain why this is a good > change. > > On Mon, Sep 18, 2017 at 04:09:53PM -0400, Daniel M. Weeks wrote: >> Signed-off-by: Daniel M. Weeks <d...@danweeks.net> > > With a more comprehensive commit message, > > Reviewed-by: John Keeping <j...@keeping.me.uk> > >> --- >> .gitmodules | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/.gitmodules b/.gitmodules >> index 1daea94..5c6ecb4 100644 >> --- a/.gitmodules >> +++ b/.gitmodules >> @@ -1,3 +1,3 @@ >> [submodule "git"] >> -url = git://git.kernel.org/pub/scm/git/git.git >> +url = https://git.kernel.org/pub/scm/git/git.git >> path = git > ___ > CGit mailing list > CGit@lists.zx2c4.com > https://lists.zx2c4.com/mailman/listinfo/cgit > signature.asc Description: OpenPGP digital signature ___ CGit mailing list CGit@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/cgit
GPG-signing of commits was: Re: your mail
Phew, that part isn't easy to solve.
cgit has no input forms that write persistent data (regarding server
security, i'm glad it does not have that).
So we don't have a keyring of user-uploaded GPG-Pubkeys to fetch key
information from, like github does.
So we have two options:
1. read the fingerprint and provide a link to a (configurable) search
page like https://pgp.key-server.io/ or https://pgp.mit.edu/, to enable
users to look at the key (if it is uploaded there). This wouldn't allow
cgit to perform validity checks and i'm not in favor of this option.
2. a admin-operated GPG keyring specifically for cgit, where the admin
decides which key would be in this keyring and/or if he trusts this key.
Based on this, cgit can display key information and validitiy (please be
aware that keys may sign commits even if they are forged), and if the
admin trusts this key... maybe a green checkmark and a text "this
signature is trusted by (this site|the admin of this site|site
owner|)"
And a red X if the signature is valid but the trustlevel is "I do NOT
trust".
Maybe we should even avoid giving people a false sense of security, by
showing every GPG signature or link to searchpages, leading them to
think everything is cryptographically secure.
A configurable trustlevel threshold with a reasonable default ("show
only signatures if the trustlevel is set" or "show only fully trusted keys")
MfG
MonkZ
On 22.07.2017 14:04, John Keeping wrote:
> On Tue, May 09, 2017 at 03:35:57AM -0400, Ghost Squad 57 wrote:
>> Lately I've gotten into the habit of signing commits and tags with my GPG
>> key (https://git-scm.com/book/en/v2/Git-Tools-Signing-Your-Work)
>>
>> But it appears cgit doesn't support showing commits that have been signed.
>>
>> Is there a way to enable this?
>
> No, we don't have any support for this at the moment. What would you
> expect to see for a signed commit? Do you want the server to validate
> the signature? In which case, how should the trusted signers be
> configured?
> ___
> CGit mailing list
> CGit@lists.zx2c4.com
> https://lists.zx2c4.com/mailman/listinfo/cgit
>
signature.asc
Description: OpenPGP digital signature
___
CGit mailing list
CGit@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/cgit
Re: cgit and symlinks
Am 12.03.2017 um 15:18 schrieb John Keeping: > On Thu, Mar 09, 2017 at 08:58:43AM +0100, MonkZ wrote: >> Am 09.03.2017 um 01:15 schrieb John Keeping: >>> On Wed, Mar 08, 2017 at 02:28:11PM +0100, MonkZ wrote: >>>> >>>> >>>> Am 08.03.2017 um 13:30 schrieb John Keeping: >>>>> On Wed, Mar 08, 2017 at 12:38:38PM +0100, MonkZ wrote: >>>>>> Am 07.03.2017 um 00:35 schrieb John Keeping: >>>>>>> We can't reliably follow the link because there is no guarantee that the >>>>>>> target lies within the repository and I don't know what we would output >>>>>>> for the case where we can't display the target. >>>>>> >>>>>> INADH (I'm not a dev here) >>>>>> >>>>>> I would recommend to continue ignoring it or returning the blob, because >>>>>> following symlinks (internally) might result - if not done carefully - >>>>>> in directory traversal security issues. Maybe resolving a symlink to a >>>>>> HTTP301 could work. >>>>>> >>>>>> For the UI there might be a html-link (in a notification box "This is a >>>>>> symlink that points to ...") to the symlink-destination below or above >>>>>> the blob, to get a user via click to a file/directory. >>>>> >>>>> We're talking about the "plain" UI here (for example [0]), so we don't >>>>> have anywhere to put additional content and it has to be something >>>>> basic. >>>> Of course. It would be handled like a content-rewrite to return a http301. >>>> >>>> Pseudocode: >>>> handle_symlinks = True # new config item >>>> if this_file_is_a_symlink and symlink_is_relative and handle_symlinks: >>>>if plain_ui: >>>># rewrite blob to http301 >>>># by attaching the path to the end of current basedir >>>># cgit is already able to handle ../ in a path >>>>if !plain_ui: >>>># show blob >>>># show notification that this is a symlink >>>># show a link to a url >>>># like the one that would be used in plain_ui >>>> >>>>> >>>>> I'm not actually too worried about directory traversal if we were to try >>>>> following links because we're looking things up in a Git tree at a >>>>> particular commit and not on the filesystem. A bigger concern would be >>>>> whether the internals of Git do anything bad (like invalid memory >>>>> access) if we give the tree traversal machinery a path that goes up out >>>>> of the repository; I doubt it but I have not checked. >>>> If we use url-rewrites (and let the http-client care about getting the >>>> correct file or directory), this would be a non-issue. >>> >>> It could also mean that cross-repository symlinks work if the server >>> layout matches that that is expected for checkouts of the repositories. >>> >>> But it's not exactly helpful if a repository contains an absolute >>> symlink and I don't think we want to start figuring out whether a >>> redirect makes sense - what do we do if we decide it doesn't? >>> >> >> Absolute symlinks must be ignored. There is no deterministic way to >> resolve them - every clone can be at a different location, and there >> isn't really a deterministic mapping from url to filesystem. Absolute >> symlinks would only work if resolved internally - with additional >> security risks. >> >> Relative inter-repository links may allowed/handled/redirected if >> explicitly configured, otherwise it might be confusing if the server >> layout doesn't match. On the other hand a notification "This is a >> symlink outside this repository" might suffice (but i don't have a plan >> for plain-ui). > > We can consider improvements to the tree UI separately, but I really > don't think we should be getting into anything clever with symlinks in > the plain UI because it ends up with complicated rules like the above. > > It's difficult to explain and will end up surprising users, so my > preference is for my original patch that just displays the content of > the blob when a symlink is found. This is consistent with both > "git show" and "git cat-file". Yep, it's a tough decision to make - full support of symlinks(in my eyes can't be done to serve all usecases), only relative symlinks or none. One argument for "only relative symlinks": Olliver Schinagl had his git to debian-repository usecase, that would still be possible if he copies the files in place of the symlink - git compression would take care of deduplication. On the other hand checking out said repository/branch could lead to a full filesystem. Config option would be s.th. like "handle_relative_symlinks" or offering a "symlink filter" hook for users to write own scripts. One argument for "none": "do one thing and do it well" and if we can't handle absolute symlinks, we should leave them alone. MfG MonkZ signature.asc Description: OpenPGP digital signature ___ CGit mailing list CGit@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/cgit
Re: cgit and symlinks
Am 09.03.2017 um 01:15 schrieb John Keeping: > On Wed, Mar 08, 2017 at 02:28:11PM +0100, MonkZ wrote: >> >> >> Am 08.03.2017 um 13:30 schrieb John Keeping: >>> On Wed, Mar 08, 2017 at 12:38:38PM +0100, MonkZ wrote: >>>> Am 07.03.2017 um 00:35 schrieb John Keeping: >>>>> We can't reliably follow the link because there is no guarantee that the >>>>> target lies within the repository and I don't know what we would output >>>>> for the case where we can't display the target. >>>> >>>> INADH (I'm not a dev here) >>>> >>>> I would recommend to continue ignoring it or returning the blob, because >>>> following symlinks (internally) might result - if not done carefully - >>>> in directory traversal security issues. Maybe resolving a symlink to a >>>> HTTP301 could work. >>>> >>>> For the UI there might be a html-link (in a notification box "This is a >>>> symlink that points to ...") to the symlink-destination below or above >>>> the blob, to get a user via click to a file/directory. >>> >>> We're talking about the "plain" UI here (for example [0]), so we don't >>> have anywhere to put additional content and it has to be something >>> basic. >> Of course. It would be handled like a content-rewrite to return a http301. >> >> Pseudocode: >> handle_symlinks = True # new config item >> if this_file_is_a_symlink and symlink_is_relative and handle_symlinks: >> if plain_ui: >> # rewrite blob to http301 >> # by attaching the path to the end of current basedir >> # cgit is already able to handle ../ in a path >> if !plain_ui: >> # show blob >> # show notification that this is a symlink >> # show a link to a url >> # like the one that would be used in plain_ui >> >>> >>> I'm not actually too worried about directory traversal if we were to try >>> following links because we're looking things up in a Git tree at a >>> particular commit and not on the filesystem. A bigger concern would be >>> whether the internals of Git do anything bad (like invalid memory >>> access) if we give the tree traversal machinery a path that goes up out >>> of the repository; I doubt it but I have not checked. >> If we use url-rewrites (and let the http-client care about getting the >> correct file or directory), this would be a non-issue. > > It could also mean that cross-repository symlinks work if the server > layout matches that that is expected for checkouts of the repositories. > > But it's not exactly helpful if a repository contains an absolute > symlink and I don't think we want to start figuring out whether a > redirect makes sense - what do we do if we decide it doesn't? > Absolute symlinks must be ignored. There is no deterministic way to resolve them - every clone can be at a different location, and there isn't really a deterministic mapping from url to filesystem. Absolute symlinks would only work if resolved internally - with additional security risks. Relative inter-repository links may allowed/handled/redirected if explicitly configured, otherwise it might be confusing if the server layout doesn't match. On the other hand a notification "This is a symlink outside this repository" might suffice (but i don't have a plan for plain-ui). MfG MonkZ P.S.: Interrepository links sounds a lot like resolving submodules - but i think that is too much for cgit. MfG MonkZ signature.asc Description: OpenPGP digital signature ___ CGit mailing list CGit@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/cgit
Re: cgit and symlinks
Am 08.03.2017 um 13:30 schrieb John Keeping: > On Wed, Mar 08, 2017 at 12:38:38PM +0100, MonkZ wrote: >> Am 07.03.2017 um 00:35 schrieb John Keeping: >>> We can't reliably follow the link because there is no guarantee that the >>> target lies within the repository and I don't know what we would output >>> for the case where we can't display the target. >> >> INADH (I'm not a dev here) >> >> I would recommend to continue ignoring it or returning the blob, because >> following symlinks (internally) might result - if not done carefully - >> in directory traversal security issues. Maybe resolving a symlink to a >> HTTP301 could work. >> >> For the UI there might be a html-link (in a notification box "This is a >> symlink that points to ...") to the symlink-destination below or above >> the blob, to get a user via click to a file/directory. > > We're talking about the "plain" UI here (for example [0]), so we don't > have anywhere to put additional content and it has to be something > basic. Of course. It would be handled like a content-rewrite to return a http301. Pseudocode: handle_symlinks = True # new config item if this_file_is_a_symlink and symlink_is_relative and handle_symlinks: if plain_ui: # rewrite blob to http301 # by attaching the path to the end of current basedir # cgit is already able to handle ../ in a path if !plain_ui: # show blob # show notification that this is a symlink # show a link to a url # like the one that would be used in plain_ui > > I'm not actually too worried about directory traversal if we were to try > following links because we're looking things up in a Git tree at a > particular commit and not on the filesystem. A bigger concern would be > whether the internals of Git do anything bad (like invalid memory > access) if we give the tree traversal machinery a path that goes up out > of the repository; I doubt it but I have not checked. If we use url-rewrites (and let the http-client care about getting the correct file or directory), this would be a non-issue. MfG MonkZ signature.asc Description: OpenPGP digital signature ___ CGit mailing list CGit@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/cgit
Re: possible bug in config readme
Am 19.02.2017 um 16:17 schrieb John Keeping: > On Sat, Feb 18, 2017 at 11:12:08PM +0100, MonkZ wrote: >> As i have my cgit + uwsgi + nginx + gitolite setup in a LXD container, i >> can publish it. >> Would this be helpful? > > Probably not necessary I was nearly done with it though :D - i've already stripped all private data and custom configs. > - I had another look at your config file and I > realised that almost every "readme" line has a trailing space. The CGit > configfile parser strips whitespace around the "=" character but does > not strip trailing whitespace. WORKS Thank you very much! > > Strangely the rest of the lines in the file do not have any trailing > spaces and the line "readme=:install" doesn't but all the rest do (try > "cat -E cgitrc" to show this). The readme config block was copy/pasted from a howto... my fault. > >> Am 18.02.2017 um 17:57 schrieb John Keeping: >>> On Tue, Jan 24, 2017 at 11:19:09PM +0100, MonkZ wrote: >>>> i'm using cgit 1.1 and trying to configure a global list of possible >>>> readme files (see attachment), but all i can get to work are >>>> "cgit.readme" entries in git-config files. >>>> >>>> I would expect, that this list would be active until a repo config or >>>> git-config comes around to overwrite it. >>> >>> I can't see anything wrong with your config, and I have just tried >>> something similar here and it seems to work. >>> >>> Having looked at the code, one small subtlety is that if there is a >>> repository-specific readme configuration it overrides the default list >>> rather than appending to it, but if you don't have any repository >>> configuration then the list in cgitrc should be used. signature.asc Description: OpenPGP digital signature ___ CGit mailing list CGit@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/cgit
Re: possible bug in config readme
As i have my cgit + uwsgi + nginx + gitolite setup in a LXD container, i can publish it. Would this be helpful? Am 18.02.2017 um 17:57 schrieb John Keeping: > On Tue, Jan 24, 2017 at 11:19:09PM +0100, MonkZ wrote: >> i'm using cgit 1.1 and trying to configure a global list of possible >> readme files (see attachment), but all i can get to work are >> "cgit.readme" entries in git-config files. >> >> I would expect, that this list would be active until a repo config or >> git-config comes around to overwrite it. > > I can't see anything wrong with your config, and I have just tried > something similar here and it seems to work. > > Having looked at the code, one small subtlety is that if there is a > repository-specific readme configuration it overrides the default list > rather than appending to it, but if you don't have any repository > configuration then the list in cgitrc should be used. > signature.asc Description: OpenPGP digital signature ___ CGit mailing list CGit@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/cgit
Re: About tab not showing on repo page
Hi David, which version do you use? I've a similar problem. But scan-path is at the end. (config attached) All readme entries seem to be ignored. Only a readme entry in the git config of a specific repo works. My version: cgit 1.1-1 on archlinux packaged 2016-11-23 09:17 UTC MfG MonkZ Am 08.02.2017 um 18:47 schrieb David Thurstenson: > On 17-02-08 18:36:01, Lars Hjemli wrote: >> On Wed, Feb 8, 2017 at 6:01 PM, David Thurstenson <thurstyl...@gmail.com> >> wrote: >>> On my cgit instance[1], I have a few repos that have either a 'README' >>> or a 'README.md' file at the root of the repo. In my cgitrc[2] I have >>> 'readme=:README' and 'readme=:README.md' (among other things), but I >>> still have no about tab on the repo page. >> >> Try to move the 'scan-path' directive to the end of your cgitrc. >> >> From https://git.zx2c4.com/cgit/tree/cgitrc.5.txt#n392 : >> >> "Be advised that only the global settings taken before the scan-path >> directive will be applied to each repository." >> >> PS: this is a recurring question - maybe the FAQ should be updated, or >> the text in cgitrc.5? >> >> Hth, >> larsh > > That did the trick! I never considered scan-path as the source of my > issue mainly because my search was focussed on 'about' or 'readme'. > > Thanks! > ___ > CGit mailing list > CGit@lists.zx2c4.com > https://lists.zx2c4.com/mailman/listinfo/cgit > about-filter=/usr/lib/cgit/filters/about-formatting.sh cache-dynamic-ttl=0 cache-repo-ttl=0 cache-root-ttl=0 cache-size=0 cache-static-ttl=0 commit-filter=/usr/local/bin/cgit-commit-links.sh css=/cgit.css enable-commit-graph=1 enable-follow-links=1 enable-git-config=1 enable-http-clone=1 enable-index-links=1 enable-log-filecount=1 enable-log-linecount=1 enable-tree-linenumbers=1 enable_index_owner = 1 logo=/cgit.png mimetype.gif=image/gif mimetype.html=text/html mimetype.jpeg=image/jpeg mimetype.jpg=image/jpeg mimetype.ogv=video/ogg mimetype.pdf=application/pdf mimetype.png=image/png mimetype.svg=image/svg+xml nocache = 1 noplainemail=1 readme=:INSTALL readme=:INSTALL.htm readme=:INSTALL.html readme=:INSTALL.md readme=:INSTALL.mkd readme=:INSTALL.rst readme=:INSTALL.txt readme=:README readme=:README.htm readme=:README.html readme=:README.md readme=:README.mkd readme=:README.rst readme=:README.txt readme=:install readme=:install.htm readme=:install.html readme=:install.md readme=:install.mkd readme=:install.rst readme=:install.txt readme=:readme readme=:readme.htm readme=:readme.html readme=:readme.md readme=:readme.mkd readme=:readme.rst readme=:readme.txt remove-suffix=0 robots=noindex, nofollow snapshots=tar.gz tar.bz2 zip source-filter=/usr/lib/cgit/filters/syntax-highlighting.py virtual-root=/ scan-path=/var/lib/gitolite/repositories/ ___ CGit mailing list CGit@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/cgit
possible bug in config readme
Moin, i'm using cgit 1.1 and trying to configure a global list of possible readme files (see attachment), but all i can get to work are "cgit.readme" entries in git-config files. I would expect, that this list would be active until a repo config or git-config comes around to overwrite it. Regards MonkZ about-filter=/usr/lib/cgit/filters/about-formatting.sh cache-dynamic-ttl=0 cache-repo-ttl=0 cache-root-ttl=0 cache-size=0 cache-static-ttl=0 commit-filter=/usr/local/bin/cgit-commit-links.sh css=/cgit.css enable-commit-graph=1 enable-follow-links=1 enable-git-config=1 enable-http-clone=1 enable-index-links=1 enable-log-filecount=1 enable-log-linecount=1 enable-tree-linenumbers=1 enable_index_owner = 1 logo=/cgit.png mimetype.gif=image/gif mimetype.html=text/html mimetype.jpeg=image/jpeg mimetype.jpg=image/jpeg mimetype.ogv=video/ogg mimetype.pdf=application/pdf mimetype.png=image/png mimetype.svg=image/svg+xml nocache = 1 noplainemail=1 readme=:INSTALL readme=:INSTALL.htm readme=:INSTALL.html readme=:INSTALL.md readme=:INSTALL.mkd readme=:INSTALL.rst readme=:INSTALL.txt readme=:README readme=:README.htm readme=:README.html readme=:README.md readme=:README.mkd readme=:README.rst readme=:README.txt readme=:install readme=:install.htm readme=:install.html readme=:install.md readme=:install.mkd readme=:install.rst readme=:install.txt readme=:readme readme=:readme.htm readme=:readme.html readme=:readme.md readme=:readme.mkd readme=:readme.rst readme=:readme.txt remove-suffix=0 robots=noindex, nofollow snapshots=tar.gz tar.bz2 zip source-filter=/usr/lib/cgit/filters/syntax-highlighting.py virtual-root=/ scan-path=/var/lib/gitolite/repositories/ ___ CGit mailing list CGit@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/cgit
