From: Rich Felker <dalias@libc.org>
To: musl@lists.openwall.com
Subject: Re: Supporting git access via smart HTTPS protocol for musl-libc
Date: Tue, 26 Mar 2019 11:04:30 -0400 [thread overview]
Message-ID: <20190326150430.GY23599@brightrain.aerifal.cx> (raw)
In-Reply-To: <20190326100245.GA1900@localhost>
On Tue, Mar 26, 2019 at 03:32:46PM +0530, vlse wrote:
> On Mon, Mar 25, 2019 at 10:59:37PM -0400, Rich Felker wrote:
> > On Tue, Mar 26, 2019 at 07:24:35AM +0530, vlse wrote:
> > > Hi,
> > >
> > > On Mon, Mar 25, 2019 at 09:37:06PM -0400, Rich Felker wrote:
> > > > On Mon, Mar 25, 2019 at 08:17:26PM -0500, A. Wilcox wrote:
> > > > > On 03/25/19 20:09, vlse wrote:
> > > > > > Hello,
> > > > > >
> > > > > > But for internet git access, either ssh or https smart protocol use
> > > > > > is necessary to prevent man in the middle attack.
> > > > >
> > > >
> > > > The request is reasonable. HTTPS is *not* "trivial to MITM", and
> > > > essentially impossible to do so without detection and a trail of
> > > > you can also verify authenticity of a git repo via "git fsck" and a
> > > > known good source of the commit hash (e.g. cgit over https).
> > > >
> > >
> > > Yes. cgit over https. We need a secure start first.
> > >
> > > > > > Please consider giving secure git access. Also smart http/s protocol
> > > > > > is way better than dumb protocol. It avoids downloading too much data
> > > > > > again and also shows progress and stats.
> > > > >
> > > >
> > > > Of course the git transport won't be taken away. I'd like to add https
> > > > support, but I'm not sure how to do it without a nasty bloated httpd
> > > > that would increase server resource requirements by 1-2 orders of
> > > > magnitude. If anyone knows a way to hook up thttpd to it, I'll give it
> > > > a try.
> > >
> > > Nginx is bloat free I think. But perhaps not in comparison to thttpd.
> > > I will look how to support cgit http/s with thttpd using a hook.
> > >
> > > At skarnet.org, the author is using busybox httpd with cgi support and
> > > cgit cgi hooks to give http/s git access.
> >
> > OK, that sounds promising. If it can be done with cgi, it should be
> > easy to setup, assuming the git client is forgiving of thttpd's
> > slightly non-conforming cgi behavior regarding headers.
> >
> > Rich
>
> Hi,
>
> On further enquiry I found that the latest cgit only supports dumb http protocol
> for cloning or fetch. But it has option to disable the http/s cloning support,
> so that another program can do it. Sorry, I was on the impression that skarnet was
> supporting git http/s smart protocol by using cgit itself.
>
> So we have to setup the git-http-backend provided with git-scm to work with web
> server cgi setup. Again the examples given at upstream site is with apache.
As long as it's cgi and not sensitive to thttpd cgi conformance
issues, it should work.
> So I am thinking of trying setting up thttpd with git-scm for support of http/s smart
> protocol locally in my linux machine.
>
> So I want to know the
> Source of thttpd your are running on git.musl-libc.org
> Version of thttpd
>
> Latest upstream version: https://acme.com/software/thttpd/thttpd-2.29.tar.gz
It's the version in Alpine Linux which also has some significant bug
fixes on top of that.
> Also I find you are providing https version of git.musl-libc.org site.
> thttpd does not supports https. Are you using stunnel for it?
I'm presently using haproxy's TLS-layer (vs HTTPS-layer) proxying,
because stunnel suggers from a 2.5-decades-old wrong handling of TCP
connection closing that makes it unusable, and because haproxy is what
I knew at the time. I think openssl s_server could handle it too, but
might not support SNI (?). What I'd really prefer is a non-broken
stunnel workalike using BearSSL as the backend, since BearSSL is the
only non-awful TLS implementation. If anyone wants to work on
something like that I'd be happy to test and eventually dogfood it on
musl site.
Rich
next prev parent reply other threads:[~2019-03-26 15:04 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20190324103306.GB1830@localhost>
[not found] ` <20190326003411.GC1872@localhost>
2019-03-26 1:09 ` vlse
2019-03-26 1:17 ` A. Wilcox
2019-03-26 1:37 ` Rich Felker
2019-03-26 1:54 ` vlse
2019-03-26 2:59 ` Rich Felker
2019-03-26 10:02 ` vlse
2019-03-26 10:36 ` Laurent Bercot
2019-03-26 15:04 ` Rich Felker [this message]
2019-03-26 15:09 ` Drew DeVault
2019-03-26 15:13 ` Rich Felker
2019-03-26 15:43 ` Drew DeVault
2019-03-26 15:47 ` Rich Felker
2019-03-26 15:57 ` Drew DeVault
2019-03-26 17:57 ` Rich Felker
2019-03-26 20:32 ` A. Wilcox
2019-03-26 20:39 ` Assaf Gordon
2019-03-26 22:02 ` Rich Felker
2019-03-26 22:32 ` Assaf Gordon
2019-03-26 23:58 ` Rich Felker
2019-03-27 0:15 ` Rich Felker
2019-03-27 5:39 ` vlse
2019-03-27 17:26 ` Assaf Gordon
2019-03-27 17:41 ` Assaf Gordon
2019-04-03 6:42 ` vlse
2019-03-26 10:19 ` Jens Gustedt
2019-03-26 10:30 ` vlse
2019-03-26 14:59 ` Rich Felker
2019-03-26 1:43 ` vlse
2019-03-26 2:29 ` A. Wilcox
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190326150430.GY23599@brightrain.aerifal.cx \
--to=dalias@libc.org \
--cc=musl@lists.openwall.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).