
Browsing a Remote Git Repository - striking
https://begriffs.com/posts/2019-02-21-browsing-remote-git.html
======
newnewpdro
Fun project to hack on, but strikes me as kind of pointless beyond the
experience/academic value of making it.

There are already a number of read-only FUSE-git bridges, and we already have
production-ready FTP daemons galore if that's the protocol you prefer.

If you don't like the existing FUSE-git bridges make one of those instead.
It's more composable; you could also point apache at the read-only FUSE mount
for example.

You're unnecessarily tightly-coupling libgit2 and the FTP protocol, and
probably creating a bunch of bugs (potentially dangerous RCE ones being a
network service) in the process.

------
mikepurvis
I would love to have some kind of protocol standardized for this. Having done
some work on build/packaging tooling for the ROS ecosystem, there are a bunch
of cases where we we need to access a metadata file (for dependency
resolution) or grab a tarball from a remote repo and end up having to have
multiple implementations to handle the slight differences between Github,
Gitlab, and Bitbucket, plus a fallback option that actually does a local
clone, see:

[https://github.com/ros-
infrastructure/rosdistro/tree/master/...](https://github.com/ros-
infrastructure/rosdistro/tree/master/src/rosdistro/manifest_provider)

[https://github.com/ros-
infrastructure/rosinstall_generator/b...](https://github.com/ros-
infrastructure/rosinstall_generator/blob/master/src/rosinstall_generator/distro.py#L144)

~~~
gmueckl
I have hit similar problems multiple times in the past. So I'd be happy if
there was a standard git server that is worth its name. SVN did that part
right by using WebDAV, so any HTTP client is enough to grab a the contents of
a file from there. It is a shame that git doesn't have anything sinilar out of
the box almost 20 years later. Even hg has an embedded http that can provide
this.

------
lugg
But why?

I feel like something went wrong a few steps ago if you find yourself needing
this.

Happy to be enlightened otherwise?

I find it hard to criticize these sorts of projects. I think people should be
questioned about strange ideas but over the internet it's hard to convey tone
and hard to explain that I still want to encourage them to continue work on
the weird, strange and unique.

~~~
gwn7
I think you are a bit quick to judge to declare this as "strange" and "weird".

What I find strange for myself is the requirement of having a git web
interface installed on the server and the need to use a web browser just to
analyze a few parts of a remote repository.

Sure, it works, looks great, and there already are mainstream solutions
available; but, a web interface certainly is overkill if all you want is to
display some remote files.

I'm definitely not saying that web interfaces are wrong, but for people like
me, simpler alternatives are very welcome, and I feel that FTP is a perfect
fit for this. Git repositories are file trees after all and a "file transfer
protocol" sounds like a better fit for this task than a "hypertext transfer
protocol".

Apart from simplicity, this approach would have better composability (with
external tools) as well, as the author put it:

> However these interfaces are fairly rigid, and don’t connect well with
> external tools.

Looking for simpler solutions to do things that we do everyday is never
"strange" in my eyes.

~~~
tptacek
FTP needs to die, immediately. It's an archaic protocol built around the
limitations of early-1980s systems. In addition to the (by modern standards)
insane protocol "feature" of having server responses be human-readable (and
not machine-parseable) text, there's the _batshit crazy_ mechanism of control
and data connections it uses, which, in addition to having caused something
like 2 decades of security problems, also makes it a nightmare to provision in
modern networks --- and for nothing, for no benefit at all.

If in 2019 a developer built a file transfer system with the same service
model as FTP, using the same design, you'd dismiss them for incompetence.

There is nothing FTP does that HTTP can't already do. The normal response to
that is that there's no _standard_ set of HTTP endpoints that delivers the
file-upload capability that FTP exposes by default. But then, FTP doesn't even
have a "standard" directory listing.

If we didn't have HTTP file upload, SFTP would be a reasonable thing to want.
But we do, and SFTP shares with FTP the property of essentially being a
restricted-purpose shell (with an attendant user authentication model), which,
again, is of basically no benefit in modern systems.

Death to FTP.

~~~
begriffs
You have strong opinions about this, which makes me think maybe you can tell
me details I didn't know about FTP.

> It's an archaic protocol built around the limitations of early-1980s
> systems.

What were the limitations, and how did they shape the protocol?

> protocol "feature" of having server responses be human-readable (and not
> machine-parseable)

The responses are successfully parsed by quite a few clients, no? The fact
that I as a person can easily read the output would seem in and of itself to
be a positive quality.

> control and data connections ... caused something like 2 decades of security
> problems, also makes it a nightmare to provision in modern networks

I know little about configuring network security, can you tell me more here?
The idea is that in passive mode the server has to pick and listen on a bunch
of random ports and so the firewall can't unconditionally block them?

Also you mention "modern networks" \-- did it used to be easier to provision
networks in the past and something has changed recently?

~~~
tptacek
Someone else on HN probably has firsthand experience with the systems that
birthed FTP, and I will be speculating a bit. But here's an example, and it's
an interesting one because it infects TCP to this day: presumably because
systems at the time didn't have workable socket multiplexing, FTP (and TCP)
supports an "URGent pointer" that allows one TCP to flag another that
important command-and-control data needs to be read during a file transfer ---
this despite the fact that FTP is already (pointlessly) allocating an
additional socket connection for each data transfer. The URG wart lives on in
TCP to this day, unused by any modern protocol.

FTP LIST responses are "successfully parsed" by predicting that servers will
return a circa-1991 ftpd "ls" listing. Which means that to be parsed by those
clients, you need to be bug-compatible with those servers. That was the point
DJB was making with his (parsable) publicfile output.

For a good starting point on FTP's security design, read up on [FTP bounce
attacks]. But the key thing to remember is: this design is pointless. There is
no reason for a file transfer protocol to be allocating new connections like
this.

------
joseph8th
This would be really nice in conjunction with Emacs' tramp-mode. I find it
annoying using the browser to navigate remote code.

I'm curious to try this out!

------
funkaster
this is really nice! congrats to the author! another frontend that could be
interesting: fuse.

------
telotortium
Is there a generic Git client like gitk or qgit that I can just point to a
remote Git URL, like so: `git-client
[https://github.com/user/repo`](https://github.com/user/repo`)?

~~~
saagarjha
Most likely it's just going to clone the thing anyways, so just cd into /tmp
and download it there and open it?

~~~
telotortium
Well, yes, that will work, but many larger Git repos take many minutes to
download, not to mention the fact that you now have random repos scattered
around your system.

~~~
alaaibrahim
If you are only interested in what HEAD has, you can use `--depth 1` with
clone

~~~
telotortium
Yeah, it might just be best to use a script to run `git clone --depth=1` into
a temporary directory and run the Git GUI on that checkout. I think I'll try
writing that up.

------
ken
I don't know much about the <video> tag, but in Safari I just see a very fuzzy
screenshot, leaking off the right edge of the page. Clicking it does nothing,
either.

~~~
begriffs
(Author here)

Thanks for reporting this. It looks ok for me in Safari 12.0.3, what version
are you on?

The bulk of the work is done by Video.js 5.0.2. Perhaps your browser or
plugins are blocking the script?

Can you send me an email with a screenshot? I do try to make the videos work
on every browser if possible.

~~~
ken
Safari 12.0.2 here. Turned off "uBlock Origin" and it still fails. The console
shows "Can't find variable: videojs".

I'll send you an email with a screenshot of the whole thing.

------
gwn7
stagit-gopher can be an alternative too. Lighter than HTML over HTTP, richer
than FTP.

Example (Gopher link):

gopher://bitreich.org/1/scm/stagit-gopher/log.gph

------
arjun27
Looks neat! What happens if you make edits to the files?

~~~
gwn7
It should return an error message indicating that the files are read-only,
obviously.. :)

~~~
begriffs
Yeah, in this server's case it would respond "502 Unimplemented"

------
notaboutdave
How is this browsing a "remote" git repository? In the example he clones the
remote to a local bare repo first. Am I missing something?

~~~
begriffs
In a real scenario gitftp would be run remotely. If you're hosting your own
git server then you could host the ftp interface too. It won't work with e.g.
Github.

------
black-tea
Why not just allow ssh access? That's what you get by default if you set up
remotes without any special Web front end.

------
nicklaf
9p: What The Whole World Wants!

------
xvector
I would be much more comfortable with using this if it was written in Go or
Rust. Why are we still writing C programs to expose sensitive information when
much safer languages exist to handle these?

~~~
begriffs
Author here. I did aim to write the code carefully, for instance doing bounded
reads like `fgets(cmd, CLIENT_BUFSZ, conn)` to prevent overflowing my buffer.
Also ran the program in Valgrind and exercised different code paths to detect
memory leaks and management errors such as use-after-free or double-freeing.
Because libgit2 and its memory conventions were new to me, I did actually make
mistakes and Valgrind helped me find them. The fix for those mistakes is in
commit 59bb39b if you're curious to check it out.

Writing in C requires care, but the modern day "rewrite it in rust" crusade
does feel overblown. C programs are nice -- small and fast.

Anyway, I don't mean to be cocky. A code review is welcome, I'd be curious if
I did indeed overlook a security issue.

