[PATCH 1/2] ui-shared: add homepage to tabs

[Jason A. Donenfeld]

Signed-off-by: Jason A. Donenfeld 
---
 cgit.c   |  4 
 cgit.h   |  1 +
 cgitrc.5.txt | 13 -
 scan-tree.c  |  2 ++
 shared.c |  1 +
 ui-shared.c  |  5 +
 6 files changed, 21 insertions(+), 5 deletions(-)

diff --git a/cgit.c b/cgit.c
index 7f83a2d..fc482be 100644
--- a/cgit.c
+++ b/cgit.c
@@ -41,6 +41,8 @@ static void repo_config(struct cgit_repo *repo, const char 
*name, const char *va
repo->desc = xstrdup(value);
else if (!strcmp(name, "owner"))
repo->owner = xstrdup(value);
+   else if (!strcmp(name, "homepage"))
+   repo->homepage = xstrdup(value);
else if (!strcmp(name, "defbranch"))
repo->defbranch = xstrdup(value);
else if (!strcmp(name, "snapshots"))
@@ -793,6 +795,8 @@ static void print_repo(FILE *f, struct cgit_repo *repo)
fprintf(f, "repo.module-link=%s\n", repo->module_link);
if (repo->section)
fprintf(f, "repo.section=%s\n", repo->section);
+   if (repo->homepage)
+   fprintf(f, "repo.homepage=%s\n", repo->homepage);
if (repo->clone_url)
fprintf(f, "repo.clone-url=%s\n", repo->clone_url);
fprintf(f, "repo.enable-commit-graph=%d\n",
diff --git a/cgit.h b/cgit.h
index d10c799..325432b 100644
--- a/cgit.h
+++ b/cgit.h
@@ -81,6 +81,7 @@ struct cgit_repo {
char *path;
char *desc;
char *owner;
+   char *homepage;
char *defbranch;
char *module_link;
struct string_list readme;
diff --git a/cgitrc.5.txt b/cgitrc.5.txt
index 47850a8..94901bd 100644
--- a/cgitrc.5.txt
+++ b/cgitrc.5.txt
@@ -205,11 +205,11 @@ enable-git-config::
Flag which, when set to "1", will allow cgit to use git config to set
any repo specific settings. This option is used in conjunction with
"scan-path", and must be defined prior, to augment repo-specific
-   settings. The keys gitweb.owner, gitweb.category, and gitweb.description
-   will map to the cgit keys repo.owner, repo.section, and repo.desc,
-   respectively. All git config keys that begin with "cgit." will be mapped
-   to the corresponding "repo." key in cgit. Default value: "0". See also:
-   scan-path, section-from-path.
+   settings. The keys gitweb.owner, gitweb.category, gitweb.description,
+   and gitweb.homepage will map to the cgit keys repo.owner, repo.section,
+   repo.desc, and repo.homepage respectively. All git config keys that 
begin
+   with "cgit." will be mapped to the corresponding "repo." key in cgit.
+   Default value: "0". See also: scan-path, section-from-path.
 
 favicon::
Url used as link to a shortcut icon for cgit. It is suggested to use
@@ -496,6 +496,9 @@ repo.defbranch::
 repo.desc::
The value to show as repository description. Default value: none.
 
+repo.homepage::
+   The value to show as repository homepage. Default value: none.
+
 repo.email-filter::
Override the default email-filter. Default value: none. See also:
"enable-filter-overrides". See also: "FILTER API".
diff --git a/scan-tree.c b/scan-tree.c
index b5a10ff..2e87999 100644
--- a/scan-tree.c
+++ b/scan-tree.c
@@ -61,6 +61,8 @@ static int gitconfig_config(const char *key, const char 
*value, void *cb)
config_fn(repo, "desc", value);
else if (!strcmp(key, "gitweb.category"))
config_fn(repo, "section", value);
+   else if (!strcmp(key, "gitweb.homepage"))
+   config_fn(repo, "homepage", value);
else if (starts_with(key, "cgit."))
config_fn(repo, key + 5, value);
 
diff --git a/shared.c b/shared.c
index a078a27..a63633b 100644
--- a/shared.c
+++ b/shared.c
@@ -54,6 +54,7 @@ struct cgit_repo *cgit_add_repo(const char *url)
ret->path = NULL;
ret->desc = cgit_default_repo_desc;
ret->owner = NULL;
+   ret->homepage = NULL;
ret->section = ctx.cfg.section;
ret->snapshots = ctx.cfg.snapshots;
ret->enable_commit_graph = ctx.cfg.enable_commit_graph;
diff --git a/ui-shared.c b/ui-shared.c
index 03dcc08..8c2d851 100644
--- a/ui-shared.c
+++ b/ui-shared.c
@@ -997,6 +997,11 @@ void cgit_print_pageheader(void)
if (ctx.repo->max_stats)
cgit_stats_link("stats", NULL, hc("stats"),
ctx.qry.head, ctx.qry.vpath);
+   if (ctx.repo->homepage) {
+   html("homepage ➦");
+   }
html("");
html("

[PATCH 2/2] cmd: redirect empty about/ to homepage or summary

[Jason A. Donenfeld]

Signed-off-by: Jason A. Donenfeld 
---
 cmd.c | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/cmd.c b/cmd.c
index 3093c62..0375c5a 100644
--- a/cmd.c
+++ b/cmd.c
@@ -47,8 +47,17 @@ static void about_fn(void)
cgit_redirect(redirect, true);
free(currenturl);
free(redirect);
-   } else
+   } else if (ctx.repo->readme.nr)
cgit_print_repo_readme(ctx.qry.path);
+   else if (ctx.repo->homepage)
+   cgit_redirect(ctx.repo->homepage, false);
+   else {
+   char *currenturl = cgit_currenturl();
+   char *redirect = fmtalloc("%s../", currenturl);
+   cgit_redirect(redirect, false);
+   free(currenturl);
+   free(redirect);
+   }
} else
cgit_print_site_readme();
 }
-- 
2.7.1

___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit

Re: [PATCH 1/2] ui-shared: add homepage to tabs

[Jason A. Donenfeld]

Seems like a very useful feature. I'd like some feedback on ➦ though.

It'd be nice to have this:
http://fortawesome.github.io/Font-Awesome/icon/external-link/
or this:
http://www.fileformat.info/info/unicode/char/1f517/index.htm

But the former is overhead I won't accept and the latter isn't
available in all browsers.

Thoughts?
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit

Re: [PATCH 1/2] ui-shared: add homepage to tabs

[John Keeping]

On Mon, Feb 22, 2016 at 04:42:12PM +0100, Jason A. Donenfeld wrote:
> Seems like a very useful feature. I'd like some feedback on ➦ though.
> 
> It'd be nice to have this:
> http://fortawesome.github.io/Font-Awesome/icon/external-link/
> or this:
> http://www.fileformat.info/info/unicode/char/1f517/index.htm
> 
> But the former is overhead I won't accept and the latter isn't
> available in all browsers.
> 
> Thoughts?

I'm not convinced by the arrow, I wonder if we'd be better off inlining
Wikipedia's external link image [1] as base64; it's quite small and is
licensed as GPLv2.

It might be nice to move this into CSS with an "external_link" class and
use :after to apply the image which will make per-site customization
easier.


[1] https://commons.wikimedia.org/wiki/File:Icon_External_Link.png
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit

Re: [PATCH 1/2] ui-shared: add homepage to tabs

[Jason A. Donenfeld]

Hi John,

I actually started doing that initially, with the base64 src of that exact
image, but then found that it looked bad with custom CSS, since a PNG,
unlike a font, embeds the color.

But, adding it into the CSS instead makes lots of sense. Great thinking.

Jason

On Mon, Feb 22, 2016 at 6:03 PM, John Keeping  wrote:

> On Mon, Feb 22, 2016 at 04:42:12PM +0100, Jason A. Donenfeld wrote:
> > Seems like a very useful feature. I'd like some feedback on ➦
> though.
> >
> > It'd be nice to have this:
> > http://fortawesome.github.io/Font-Awesome/icon/external-link/
> > or this:
> > http://www.fileformat.info/info/unicode/char/1f517/index.htm
> >
> > But the former is overhead I won't accept and the latter isn't
> > available in all browsers.
> >
> > Thoughts?
>
> I'm not convinced by the arrow, I wonder if we'd be better off inlining
> Wikipedia's external link image [1] as base64; it's quite small and is
> licensed as GPLv2.
>
> It might be nice to move this into CSS with an "external_link" class and
> use :after to apply the image which will make per-site customization
> easier.
>
>
> [1] https://commons.wikimedia.org/wiki/File:Icon_External_Link.png
>



-- 
Jason A. Donenfeld
Deep Space Explorer
fr: +33 6 51 90 82 66
us: +1 513 476 1200
www.jasondonenfeld.com
www.zx2c4.com
zx2c4.com/keys/AB9942E6D4A4CFC3412620A749FC7012A5DE03AE.asc
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit

Re: [PATCH 1/2] ui-shared: add homepage to tabs

[Jason A. Donenfeld]

Here we go:
https://git.zx2c4.com/cgit/commit/?h=jd/zx2c4-deployment&id=e160fa1fe7efbae91ff04992df0b3464f43a4426

You can see it in action here:
https://git.zx2c4.com/password-store/
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit

Re: [PATCH] ui-plain: fix to show a repo's root directory listing in plain view

[Jason A. Donenfeld]

Merged!

https://git.zx2c4.com/cgit/commit/?id=de6098be6a65a4758ff8eac6359bd6fd30ba7bd3

Thanks.
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit

Next release will be 1.0

[Jason A. Donenfeld]

Hi guys,

We'll switch to semver. Why not? Our current versioning situation doesn't
make much sense.

That means the next release oughta be a nice one.

Thoughts?

Jason
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit

Killing plaintext git:// in favor of https:// cloning

[Jason A. Donenfeld]

Hello projects-with-mailing-lists,

Now that git.zx2c4.com runs over HTTPS, I'm considering getting rid of
the plaintext git:// endpoint for cloning.

This means:

git clone git://git.zx2c4.com/cgit
-->
git clone https://git.zx2c4.com/cgit

git clone git://git.zx2c4.com/password-store
-->
git clone https://git.zx2c4.com/password-store


Does anybody have any objections or comments?

Thanks,
Jason
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit

Re: Killing plaintext git:// in favor of https:// cloning

[Jason A. Donenfeld]

Well, uh oh speghettio!

Looks like somebody has published in paper the git:// URI:

https://books.google.fr/books?id=kJsQAwAAQBAJ&pg=PA314&lpg=PA314&dq=git://git.zx2c4.com&source=bl&ots=W6M9TlYzCY&sig=g-PY0glN2ddWygtFDLiHgbiC69I&hl=en&sa=X&redir_esc=y#v=onepage&q=git%3A%2F%2Fgit.zx2c4.com&f=false

Perhaps there's a way to write a dummy daemon that prints a message...
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit

Re: Killing plaintext git:// in favor of https:// cloning

[Ferry Huberts]

On 22/02/16 19:16, Jason A. Donenfeld wrote:

Hello projects-with-mailing-lists,

Now that git.zx2c4.com runs over HTTPS, I'm considering getting rid of
the plaintext git:// endpoint for cloning.

This means:

git clone git://git.zx2c4.com/cgit
-->
git clone https://git.zx2c4.com/cgit

git clone git://git.zx2c4.com/password-store
-->
git clone https://git.zx2c4.com/password-store


Does anybody have any objections or comments?



Yes, why?
What's the point?

The repos are public, so cloning them over https bring nothing, except 
extra overhead and server load.




Thanks,
Jason
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit



--
Ferry Huberts
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit

Re: Killing plaintext git:// in favor of https:// cloning

[Joe Anakata]

On 22/02/16 19:16, Jason A. Donenfeld wrote:

>> Now that git.zx2c4.com runs over HTTPS, I'm considering getting rid of
>> the plaintext git:// endpoint for cloning.

Ferry Huberts Proclaimed Thus: 

>Yes, why?
>What's the point?
>
>The repos are public, so cloning them over https bring nothing, except 
>extra overhead and server load.

While pretty unlikely, in theory someone could MITM a git:// clone and
send the user a hax0red branch of cgit with integrated botnet which
the user then compiles and installs on their server.

Not sure if the extra server load is worth it to defend against this
case or not.  (Also, presumably the server is using the cgit smart http
endpoint so https clone is not much additional DATA, just the ssl
handshake; but definitely additional cpu for crypto operations.)

Thanks
-Joe
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit

Re: Killing plaintext git:// in favor of https:// cloning

[Jason A. Donenfeld]

On Mon, Feb 22, 2016 at 8:18 PM, Ferry Huberts  wrote:
> Yes, why?
> What's the point?

So that the contents of the repository cannot be modified in transit.
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit

Re: Killing plaintext git:// in favor of https:// cloning

[Eclipse Webmaster (Denis Roy)]

On 22/02/16 02:50 PM, Joe Anakata wrote:

Yes, why?
What's the point?

The repos are public, so cloning them over https bring nothing, except
extra overhead and server load.

While pretty unlikely, in theory someone could MITM a git:// clone and
send the user a hax0red branch of cgit with integrated botnet which
the user then compiles and installs on their server.



Everything is possible "in theory" ... But folks really need to stop 
thinking that https is the impenetrable solution to everything.




___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit

Re: Killing plaintext git:// in favor of https:// cloning

[Ferry Huberts]

On 22/02/16 20:50, Joe Anakata wrote:


On 22/02/16 19:16, Jason A. Donenfeld wrote:


Now that git.zx2c4.com runs over HTTPS, I'm considering getting rid of
the plaintext git:// endpoint for cloning.


Ferry Huberts Proclaimed Thus:


Yes, why?
What's the point?

The repos are public, so cloning them over https bring nothing, except
extra overhead and server load.


While pretty unlikely, in theory someone could MITM a git:// clone and
send the user a hax0red branch of cgit with integrated botnet which
the user then compiles and installs on their server.




That is a pretty unlikely and sophisticated attack vector, for 
admittedly little gain. Someone with an existing clone can immediately 
see that thing are off.


It is a vector though, so if you really want to defend against it, then 
just ignore my comments ;-)



Not sure if the extra server load is worth it to defend against this
case or not.  (Also, presumably the server is using the cgit smart http
endpoint so https clone is not much additional DATA, just the ssl
handshake; but definitely additional cpu for crypto operations.)

Thanks
-Joe
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit



--
Ferry Huberts
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit

Re: Killing plaintext git:// in favor of https:// cloning

[Joe Anakata]

"Eclipse Webmaster (Denis Roy)" Proclaimed Thus: 

>Everything is possible "in theory" ... But folks really need to stop 
>thinking that https is the impenetrable solution to everything.

HTTPS is definitely not the impenetrable solution to everything, but
there's no question it makes things *harder* for an attacker.

But as everyone else points out, this is a relatively unlikely attack;
there are almost certainly easier vectors of attack.  

(Also it was mentioned this would only work for people making a fresh
clone; anyone with an existing clone would almost certainly know
something was up.)

Something to keep in mind is that the https endpoint is already up, so
anyone who is actually concerned about this sort of attack can just
use https if they would like to, even if the git:// protocol stays open.

Also there is the issue of the book reference, which is hard to
change.  Though, for this, you could just have a dummy server which
redirects people, something which is essentially:

nc -l -p 9418 -c "echo -n 002AERR please use https://foo.bar/foo.git";

Cloning from that "git server" results in:

fatal: remote error: please use https://foo.bar/foo.git

(Of course, someone could still MITM *that*.  The returns from doing
so as an attacker are vanishingly small at that point.)

Thanks
-Joe
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit

[PATCH 1/1] git: update to v2.7.2

[Christian Hesse]

From: Christian Hesse 

Update to git version v2.7.2, no changes required.

Signed-off-by: Christian Hesse 
---
 Makefile | 2 +-
 git  | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/Makefile b/Makefile
index 8bd7a0e..c01701c 100644
--- a/Makefile
+++ b/Makefile
@@ -14,7 +14,7 @@ htmldir = $(docdir)
 pdfdir = $(docdir)
 mandir = $(prefix)/share/man
 SHA1_HEADER = 
-GIT_VER = 2.7.1
+GIT_VER = 2.7.2
 GIT_URL = https://www.kernel.org/pub/software/scm/git/git-$(GIT_VER).tar.gz
 INSTALL = install
 COPYTREE = cp -r
diff --git a/git b/git
index a08595f..326e5bc 16
--- a/git
+++ b/git
@@ -1 +1 @@
-Subproject commit a08595f76159b09d57553e37a5123f1091bb13e7
+Subproject commit 326e5bc91eecf73234ead29636207bc516573e79
-- 
2.7.1

___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit

Re: Killing plaintext git:// in favor of https:// cloning

[Eric Wong]

"Jason A. Donenfeld"  wrote:
> Now that git.zx2c4.com runs over HTTPS, I'm considering getting rid of
> the plaintext git:// endpoint for cloning.

> Does anybody have any objections or comments?

I suggest keeping git:// running as automated mirrors may not be
monitored very closely or easily updated.

git already has plenty of integrity checking built-in and
getting the proper hashes for the heads/tags over a
trusted-enough medium is enough (or reading the fine code).

And as others have said, HTTPS isn't impenetrable and the
CA system is still a major problem.

Also, TLS libraries can introduce new bugs and vulnerabilities
like Heartbleed.  Quoting from http://www.postfix.org/TLS_README.html

|  By turning on TLS support in Postfix, you not only get the
|  ability to encrypt mail and to authenticate remote SMTP clients
|  or servers. You also turn on thousands and thousands of lines of
|  OpenSSL library code. Assuming that OpenSSL is written as
|  carefully as Wietse's own code, every 1000 lines introduce one
|  additional bug into Postfix.

Something to keep in mind :)
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit

Re: Killing plaintext git:// in favor of https:// cloning

[Jason A. Donenfeld]

https://git.zx2c4.com/git-daemon-dummy/about/

I just wrote this.

Will consider whether or not to deploy it.
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit

Fwd: cgit: [PATCH] timegm() compat for non-Linux and non-BSD

[Jason A. Donenfeld]

-- Forwarded message --
From: Brad Forschinger 
Date: Tue, Feb 23, 2016 at 12:27 AM
Subject: cgit: [PATCH] timegm() compat for non-Linux and non-BSD
To: ja...@zx2c4.com


Hi Jason,

I almost know that gmail will mangle the e-mail, so I'll include it as
an attachment.

Brad
From 34e1cfd7f56e20c577cebba31e8235e101f95972 Mon Sep 17 00:00:00 2001
From: Brad Forschinger 
Date: Tue, 23 Feb 2016 10:18:34 +1100
Subject: [PATCH] timegm() compat for non-Linux and non-BSD

---
 cgit.mk|  9 +
 ui-stats.c | 19 +++
 2 files changed, 28 insertions(+)

diff --git a/cgit.mk b/cgit.mk
index 1b50307..4f75264 100644
--- a/cgit.mk
+++ b/cgit.mk
@@ -65,6 +65,15 @@ ifdef HAVE_LINUX_SENDFILE
 	CGIT_CFLAGS += -DHAVE_LINUX_SENDFILE
 endif
 
+# from timegm(3): These functions are non-standard GNU extensions that
+# are also present on the BSDs. Avoid their use; see NOTES.
+ifeq ($(findstring BSD,$(uname_S)),BSD)
+	CGIT_CFLAGS += -DHAVE_TIMEGM
+endif
+ifeq ($(uname_S),Linux)
+	CGIT_CFLAGS += -DHAVE_TIMEGM
+endif
+
 CGIT_OBJ_NAMES += cgit.o
 CGIT_OBJ_NAMES += cache.o
 CGIT_OBJ_NAMES += cmd.o
diff --git a/ui-stats.c b/ui-stats.c
index 8cd9178..67b99aa 100644
--- a/ui-stats.c
+++ b/ui-stats.c
@@ -11,6 +11,25 @@ struct authorstat {
 #define DAY_SECS (60 * 60 * 24)
 #define WEEK_SECS (DAY_SECS * 7)
 
+#ifndef HAVE_TIMEGM
+time_t timegm(struct tm *tm)
+{
+	time_t ret;
+	char *tz;
+
+	tz = getenv("TZ");
+	setenv("TZ", "", 1);
+	tzset();
+	ret = mktime(tm);
+	if (tz)
+		setenv("TZ", tz, 1);
+	else
+		unsetenv("TZ");
+	tzset();
+	return ret;
+}
+#endif
+
 static void trunc_week(struct tm *tm)
 {
 	time_t t = timegm(tm);
-- 
2.4.3

___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit

Re: cgit: [PATCH] timegm() compat for non-Linux and non-BSD

[Jason A. Donenfeld]

>From 34e1cfd7f56e20c577cebba31e8235e101f95972 Mon Sep 17 00:00:00 2001
From: Brad Forschinger 
Date: Tue, 23 Feb 2016 10:18:34 +1100
Subject: [PATCH] timegm() compat for non-Linux and non-BSD

---
 cgit.mk|  9 +
 ui-stats.c | 19 +++
 2 files changed, 28 insertions(+)

diff --git a/cgit.mk b/cgit.mk
index 1b50307..4f75264 100644
--- a/cgit.mk
+++ b/cgit.mk
@@ -65,6 +65,15 @@ ifdef HAVE_LINUX_SENDFILE
  CGIT_CFLAGS += -DHAVE_LINUX_SENDFILE
 endif

+# from timegm(3): These functions are non-standard GNU extensions that
+# are also present on the BSDs. Avoid their use; see NOTES.
+ifeq ($(findstring BSD,$(uname_S)),BSD)
+ CGIT_CFLAGS += -DHAVE_TIMEGM
+endif
+ifeq ($(uname_S),Linux)
+ CGIT_CFLAGS += -DHAVE_TIMEGM
+endif
+
 CGIT_OBJ_NAMES += cgit.o
 CGIT_OBJ_NAMES += cache.o
 CGIT_OBJ_NAMES += cmd.o
diff --git a/ui-stats.c b/ui-stats.c
index 8cd9178..67b99aa 100644
--- a/ui-stats.c
+++ b/ui-stats.c
@@ -11,6 +11,25 @@ struct authorstat {
 #define DAY_SECS (60 * 60 * 24)
 #define WEEK_SECS (DAY_SECS * 7)

+#ifndef HAVE_TIMEGM
+time_t timegm(struct tm *tm)
+{
+ time_t ret;
+ char *tz;
+
+ tz = getenv("TZ");
+ setenv("TZ", "", 1);
+ tzset();
+ ret = mktime(tm);
+ if (tz)
+ setenv("TZ", tz, 1);
+ else
+ unsetenv("TZ");
+ tzset();
+ return ret;
+}
+#endif
+
 static void trunc_week(struct tm *tm)
 {
  time_t t = timegm(tm);
-- 
2.4.3
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit

Re: cgit: [PATCH] timegm() compat for non-Linux and non-BSD

[Jason A. Donenfeld]

On Tue, Feb 23, 2016 at 3:15 AM, Jason A. Donenfeld  wrote:
> Subject: [PATCH] timegm() compat for non-Linux and non-BSD

What platform, specifically, do you have in mind?
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit

Re: [PATCH 1/1] git: update to v2.7.2

[Jason A. Donenfeld]

Merged, thanks.
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit

Re: Killing plaintext git:// in favor of https:// cloning

[Jason A. Donenfeld]

On Mon, Feb 22, 2016 at 8:57 PM, Eclipse Webmaster (Denis Roy)
 wrote:
>
> Everything is possible "in theory" ... But folks really need to stop
> thinking that https is the impenetrable solution to everything.

Are you aware of some attack on TLS 1.2 that I'm not?
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit

Re: Killing plaintext git:// in favor of https:// cloning

[Jason A. Donenfeld]

On Mon, Feb 22, 2016 at 9:43 PM, Joe Anakata
 wrote:
> (Also it was mentioned this would only work for people making a fresh
> clone; anyone with an existing clone would almost certainly know
> something was up.)

No, definitely a MITM attack is feasible that would be fast
forwardable just fine for a pull onto an existing repo.

> Also there is the issue of the book reference, which is hard to
> change.  Though, for this, you could just have a dummy server which
> redirects people, something which is essentially:
>
> nc -l -p 9418 -c "echo -n 002AERR please use https://foo.bar/foo.git";

Right, this is exactly what I wound up doing, except much higher
performance using epoll:
https://git.zx2c4.com/git-daemon-dummy/about/
I haven't decided whether or not to deploy it, but the code is there.

> (Of course, someone could still MITM *that*.

Right. But the idea, anyhow, would just be to let the readers of the
book know what's up, rather than leaving them in the dark.
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit

Re: Killing plaintext git:// in favor of https:// cloning

[Jason A. Donenfeld]

On Tue, Feb 23, 2016 at 2:19 AM, Eric Wong  wrote:
> I suggest keeping git:// running as automated mirrors may not be
> monitored very closely or easily updated.

That's a good point. I'd forgotten about automated mirrors. I'll keep
logs of the git:// pulls for a month or so and see if there are any
regular pullers and also if I can track down the source IP. Perhaps
it's a manageable pool of people to switch over.

> git already has plenty of integrity checking built-in and
> getting the proper hashes for the heads/tags over a
> trusted-enough medium is enough (or reading the fine code).

No, git's built-in integrity protection really is not sufficient if
the transport is compromised.

> And as others have said, HTTPS isn't impenetrable

I'd like some specific details on this repeated claim.

> the CA system is still a major problem.

True. But there doesn't appear to be a widely deployed alternative.

> Also, TLS libraries can introduce new bugs and vulnerabilities
> like Heartbleed.

This is true, but I already require a public TLS deployment, so it's
there regardless.
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit

Build failed in Jenkins: cgit-master #20 - origin/master - 438c038

[Pelagic Jenkins (Public)]

See 

Changes:

[Jason] md2html: Do syntax highlighting too

--
[...truncated 562 lines...]
307 translated messages.
Generating catalog po/hu.msg
msgfmt --statistics --tcl po/hu.po -l hu -d po/
277 translated messages, 18 fuzzy translations, 12 untranslated messages.
Generating catalog po/es.msg
msgfmt --statistics --tcl po/es.po -l es -d po/
184 translated messages, 46 fuzzy translations, 77 untranslated messages.
Generating catalog po/sv.msg
msgfmt --statistics --tcl po/sv.po -l sv -d po/
311 translated messages.
Generating catalog po/fr.msg
msgfmt --statistics --tcl po/fr.po -l fr -d po/
263 translated messages, 27 fuzzy translations, 17 untranslated messages.
Generating catalog po/it.msg
msgfmt --statistics --tcl po/it.po -l it -d po/
274 translated messages, 17 fuzzy translations, 16 untranslated messages.
Generating catalog po/ja.msg
msgfmt --statistics --tcl po/ja.po -l ja -d po/
311 translated messages.
Generating catalog po/pt_br.msg
msgfmt --statistics --tcl po/pt_br.po -l pt_br -d po/
279 translated messages, 16 fuzzy translations, 12 untranslated messages.
Generating catalog po/de.msg
msgfmt --statistics --tcl po/de.po -l de -d po/
278 translated messages, 17 fuzzy translations, 12 untranslated messages.
SUBDIR perl
"/usr/bin/perl" -pe "s<\Q++LOCALEDIR++\E>" 
blib/lib/Git/SVN/Memoize/YAML.pm
"/usr/bin/perl" -pe "s<\Q++LOCALEDIR++\E>" 
blib/lib/Git.pm
"/usr/bin/perl" -pe "s<\Q++LOCALEDIR++\E>" 
blib/lib/Git/SVN/Ra.pm
"/usr/bin/perl" -pe "s<\Q++LOCALEDIR++\E>" 
blib/lib/Git/SVN/Editor.pm
"/usr/bin/perl" -pe "s<\Q++LOCALEDIR++\E>" 
blib/lib/Git/SVN/Prompt.pm
"/usr/bin/perl" -pe "s<\Q++LOCALEDIR++\E>" 
blib/lib/Git/SVN/Utils.pm
"/usr/bin/perl" -pe "s<\Q++LOCALEDIR++\E>" 
blib/lib/Git/SVN.pm
"/usr/bin/perl" -pe "s<\Q++LOCALEDIR++\E>" 
blib/lib/Git/SVN/Migration.pm
"/usr/bin/perl" -pe "s<\Q++LOCALEDIR++\E>" 
blib/lib/Git/I18N.pm
"/usr/bin/perl" -pe "s<\Q++LOCALEDIR++\E>" 
blib/lib/Git/SVN/Fetcher.pm
"/usr/bin/perl" -pe "s<\Q++LOCALEDIR++\E>" 
blib/lib/Git/IndexInfo.pm
"/usr/bin/perl" -pe "s<\Q++LOCALEDIR++\E>" 
blib/lib/Git/SVN/GlobSpec.pm
"/usr/bin/perl" -pe "s<\Q++LOCALEDIR++\E>" 
blib/lib/Git/SVN/Log.pm
Manifying 8 pod documents
SUBDIR templates
MSGFMT po/build/locale/pt_PT/LC_MESSAGES/git.mo
306 translated messages, 687 untranslated messages.
MSGFMT po/build/locale/ko/LC_MESSAGES/git.mo
2477 translated messages.
MSGFMT po/build/locale/vi/LC_MESSAGES/git.mo
2477 translated messages.
MSGFMT po/build/locale/is/LC_MESSAGES/git.mo
14 translated messages.
MSGFMT po/build/locale/ca/LC_MESSAGES/git.mo
2477 translated messages.
MSGFMT po/build/locale/ru/LC_MESSAGES/git.mo
2477 translated messages.
MSGFMT po/build/locale/bg/LC_MESSAGES/git.mo
2477 translated messages.
MSGFMT po/build/locale/sv/LC_MESSAGES/git.mo
2477 translated messages.
MSGFMT po/build/locale/fr/LC_MESSAGES/git.mo
2477 translated messages.
MSGFMT po/build/locale/it/LC_MESSAGES/git.mo
716 translated messages, 350 untranslated messages.
MSGFMT po/build/locale/de/LC_MESSAGES/git.mo
2477 translated messages.
MSGFMT po/build/locale/zh_CN/LC_MESSAGES/git.mo
2477 translated messages.
CC test-chmtime.o
LINK test-chmtime
CC test-ctype.o
LINK test-ctype
CC test-config.o
LINK test-config
CC test-date.o
LINK test-date
CC test-delta.o
LINK test-delta
CC test-dump-cache-tree.o
LINK test-dump-cache-tree
CC test-dump-split-index.o
LINK test-dump-split-index
CC test-dump-untracked-cache.o
LINK test-dump-untracked-cache
CC test-genrandom.o
LINK test-genrandom
CC test-hashmap.o
LINK test-hashmap
CC test-index-version.o
LINK test-index-version
CC test-line-buffer.o
LINK test-line-buffer
CC test-match-trees.o
LINK test-match-trees
CC test-mergesort.o
LINK test-mergesort
CC test-mktemp.o
LINK test-mktemp
CC test-parse-options.o
LINK test-parse-options
CC test-path-utils.o
LINK test-path-utils
CC test-prio-queue.o
LINK test-prio-queue
CC test-read-cache.o
LINK test-read-cache
CC test-regex.o
LINK test-regex
CC test-revision-walking.o
LINK test-revision-walking
CC test-run-command.o
LINK test-run-command
CC test-scrap-cache-tree.o
LINK test-scrap-cache-tree
CC test-sha1.o
LINK test-sha1
CC test-sha1-array.o
LINK test-sha1-array
CC test-sigchain.o
LINK test-sigchain
CC test-string-list.o
LINK test-string-list
CC test-submodule-config.o
LINK test-submodule-config
CC test-subprocess.o
LINK test-subprocess
CC test-svn-fe.o
LINK test-svn-fe
CC test-urlmatch-normalization.o
LINK test-urlmatch-normalization
CC test-wildmatch.o
LINK test-wildmatch
GEN bin-wrappers/git
GEN bin-wrappers/git-upload-pack
GEN bin-wrappers/git-receive-pack
GEN bin-w

Re: Killing plaintext git:// in favor of https:// cloning

[Eric Wong]

"Jason A. Donenfeld"  wrote:
> On Tue, Feb 23, 2016 at 2:19 AM, Eric Wong  wrote:
> > git already has plenty of integrity checking built-in and
> > getting the proper hashes for the heads/tags over a
> > trusted-enough medium is enough (or reading the fine code).
> 
> No, git's built-in integrity protection really is not sufficient if
> the transport is compromised.

git commits, tags, and request-pull-formatted emails (with
unabbreviated commit IDs) may all be signed with GPG.

Once those are verified, "git fsck" results can be trusted.

> > And as others have said, HTTPS isn't impenetrable
> 
> I'd like some specific details on this repeated claim.

The known problem would be CAs being compromised.
I've also heard of MITM stripping proxies; but don't know
much about them.

> > the CA system is still a major problem.
> 
> True. But there doesn't appear to be a widely deployed alternative.

GPG-signed tags/commits/emails.  Probably not as widely deployed
as TLS CAs, but probably sufficient in Free Software circles.

> > Also, TLS libraries can introduce new bugs and vulnerabilities
> > like Heartbleed.
> 
> This is true, but I already require a public TLS deployment, so it's
> there regardless.

Vulnerabilities may affect clients, too (for example, the recent
OpenSSH roaming vulnerability).  IMHO, users should be given a
choice of which poison to pick.



Disclaimer: Personally, I don't GPG sign anything, myself,
either.  For selfish reasons, I do not want people to trust me
or my signature and would prefer they read and scrutinize
what little I write.  And we can't rule out undiscovered
vulnerabilties affecting GPG, either.
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit

Re: [PATCH 1/2] ui-shared: add homepage to tabs

[Peter Colberg]

Hi Jason,

Thank you for this patch, this is indeed a very useful feature.

Would you reconsider opening the homepage link in the current tab
by default? This way visitors have the option to open the homepage
in new tab if they like (e.g., using middle-click), but they are not
forced to do so.

Regards,
Peter
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit