Git Daemon Dummy: 301 Redirects for git:// to https://

Git Daemon Dummy: 301 Redirects for git:// to https://

[Jason A. Donenfeld]

Hi folks,

In case anyone else finds this useful, I wrote this:

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

It's an epoll-based responder for git:// that simply returns an error
telling users of a new URI. The purpose is to phase out git-daemon in
favor of more secure TLS/HTTPS endpoints. With HTTPS certificates now
being free, seems like this could be useful.

My personal motivation is that I'd like to just totally kill the
git-daemon service, but somebody hard coded a URI of mine into a real
printed textbook [1], so I don't want it to go stale suddenly. So, I
need some way of informing users of the new URI.

Let me know what you think.

Jason



[1] 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

Re: Git Daemon Dummy: 301 Redirects for git:// to https://

[Jeff King]

On Tue, Feb 23, 2016 at 03:32:02AM +0100, Jason A. Donenfeld wrote:

> In case anyone else finds this useful, I wrote this:
> 
> https://git.zx2c4.com/git-daemon-dummy/about/
> 
> It's an epoll-based responder for git:// that simply returns an error
> telling users of a new URI.

Neat.

> The purpose is to phase out git-daemon in
> favor of more secure TLS/HTTPS endpoints. With HTTPS certificates now
> being free, seems like this could be useful.

Yeah, the existence of HTTPS (and the fact that the same URL can be both
anonymous and authenticated) is nice. Unfortunately, git-over-https is
not as efficient as the other protocols, because it's not asynchronously
bi-directional. It would probably be relatively simple to make a
"gits://" protocol, but I think it would be more interesting still if we
could do git-over-websockets, to get the ubiquity benefits of HTTP.

I looked into it once, but was unable to find any reasonably sized
explanation of how to implement either the server or client side of
websockets. :)

> My personal motivation is that I'd like to just totally kill the
> git-daemon service, but somebody hard coded a URI of mine into a real
> printed textbook [1], so I don't want it to go stale suddenly. So, I
> need some way of informing users of the new URI.

Darn printed books. I thought the Ministry of Truth was supposed to take
care of keeping our facts up to date.

-Peff

Re: Git Daemon Dummy: 301 Redirects for git:// to https://

[John Keeping]

On Tue, Feb 23, 2016 at 03:32:02AM +0100, Jason A. Donenfeld wrote:
> In case anyone else finds this useful, I wrote this:
> 
> https://git.zx2c4.com/git-daemon-dummy/about/
> 
> It's an epoll-based responder for git:// that simply returns an error
> telling users of a new URI. The purpose is to phase out git-daemon in
> favor of more secure TLS/HTTPS endpoints. With HTTPS certificates now
> being free, seems like this could be useful.
> 
> My personal motivation is that I'd like to just totally kill the
> git-daemon service, but somebody hard coded a URI of mine into a real
> printed textbook [1], so I don't want it to go stale suddenly. So, I
> need some way of informing users of the new URI.
> 
> Let me know what you think.

There's no license specified in the repo, it just says "All rights
reserved" in the .c file.  I'm sure you intend it to be open source, but
it isn't unless a license is specified.

Re: Git Daemon Dummy: 301 Redirects for git:// to https://

[Duy Nguyen]

On Tue, Feb 23, 2016 at 1:15 PM, Jeff King <peff@peff.net> wrote:
> I looked into it once, but was unable to find any reasonably sized
> explanation of how to implement either the server or client side of
> websockets. :)

Wikipedia explained handshake in four paragraphs. Then you only have
to chew about ten pages of RFC6455, from page 27 to master data frames
(and we probably just need binary frames for pkt-line, or fragmented
when sending the pack). Come on, give us git+ws:// :D

PS. Too bad I couldn't find any minimal library that just deals with
websocket data frame handling. I suppose curl can deal with handshake
just fine.
-- 
Duy

Re: Git Daemon Dummy: 301 Redirects for git:// to https://

[Jason A. Donenfeld]

On Tue, Feb 23, 2016 at 11:51 AM, John Keeping <john@keeping.me.uk> wrote:
> On Tue, Feb 23, 2016 at 03:32:02AM +0100, Jason A. Donenfeld wrote:
> There's no license specified in the repo, it just says "All rights
> reserved" in the .c file.  I'm sure you intend it to be open source, but
> it isn't unless a license is specified.

https://git.zx2c4.com/git-daemon-dummy/commit/?id=a7ebbf5ab63cb2e95c38a58197cd2805a2deb56f

There you go.

Re: Git Daemon Dummy: 301 Redirects for git:// to https://

[Jason A. Donenfeld]

On Tue, Feb 23, 2016 at 7:15 AM, Jeff King <peff@peff.net> wrote:
>
> Yeah, the existence of HTTPS (and the fact that the same URL can be both
> anonymous and authenticated) is nice. Unfortunately, git-over-https is
> not as efficient as the other protocols, because it's not asynchronously
> bi-directional. It would probably be relatively simple to make a
> "gits://" protocol, but I think it would be more interesting still if we
> could do git-over-websockets, to get the ubiquity benefits of HTTP.

That's interesting. I didn't realize that even the smart protocol was
not as efficient as HTTP, but that makes sense. git+ws:// would indeed
be quite nice!

> Darn printed books. I thought the Ministry of Truth was supposed to take
> care of keeping our facts up to date.

:-P

Re: Git Daemon Dummy: 301 Redirects for git:// to https://

[Jason A. Donenfeld]

On Tue, Feb 23, 2016 at 4:11 PM, Jason A. Donenfeld <Jason@zx2c4.com> wrote:
> That's interesting. I didn't realize that even the smart protocol was
> not as efficient as HTTP

Can't type today. *as efficient as git://