Here is my response to John: Thanks for the thoughtful and quick response.
It looks like python -m http.server does cover most of what Bashbro has to offer at the moment. But there is a big update on the way, adding more functionality and I will look at your security concerns. Some of the features are a way to filter (include/exclude) files shown, by file extension and regex fragment, shows the fs and how full it is on the directory displayed and will have an m3u view option that will allow filter configured page be copy/pasted via url into a streaming media player (e.g. vlc). Also the HTTP protocol handling will be updated. Here is a link to an image of the prototype, it's roughed in not the final appearance. The pie chart is written dynamically via javascript/canvas showing how much space is left on the filesystem. https://ibb.co/sbbMnLH So for instance, you might launch VLC (ctl+n) and paste something like: http://localhost:5544/media/media_clips/?m3u=true&filter_type=ALL_FILES&excludeFilters=&includeFilters=mp4 Note: Bashbro has the ability to jail to a directory or a single file which I'm not sure python does at present, which isn't I guess a huge bit of functionality but it can be useful if/when you want to share a single file. As for how the url encoding works, at present it relies on the browser. I plan on implementing RFC 3986 - I have recently written a few fast urlencoders recently and the awk version is practically as fast as my optimized C version (the awk version will be included in the future version of Bashbro) - you can find them on my blog if you're interested: https://scriptsandoneliners.blogspot.com/ For / support: Have you tried creating a file with a / in it? It's not possible afaik. But I'll probably try to cover those edge cases anyway where possible - newlines and /'s although legal tend to break a lot of things kind of like null characters in C strings. Anyway, thanks again for the consideration, +Ad On Wed, Sep 4, 2024 at 10:51 PM Soren Stoutner <so...@debian.org> wrote: > John, > > Those are some good comments. Thanks. > > On Wednesday, September 4, 2024 6:35:33 PM MST John Goerzen wrote: > > Hello, > > > > Adam recently contacted me as a random DD, as he was interested in > > getting Bashbro into Debian. As a courtesy to the others that have > > visited with him about it, here is an excerpt of my response. > > > > Hi Adam, > > > > That's a pretty neat concept! I'm impressed - HTTP serving in bash. It > > wouldn't have occurred to me. A neat idea! And, I'm glad that you're > > interested in Debian! > > > > When considering adding a package to Debian, we remember that adding a > > package is expensive. That is, it requires infrastructure resources, > > human time (reviewing uploads, etc), bandwidth, disk space, etc. It > > also implies commitments for future humans: security team, etc. > > > > So there are some broad criteria we look at when considering adding a > > package: > > > > 1) Does it duplicate existing functionality? If so, is it sufficiently > > different/better to justify inclusion anyhow? > > > > 2) Is it likely to be actively maintained for the extended lifetime of a > > release (several years)? > > > > 3) Is it of high quality? > > > > Debian already contains this kind of functionality in the default > > install (run python -m http.server 9000, for instance; see > > https://docs.python.org/3/library/http.server.html#http-server-security > > ). There are also numerous other minimal HTTP servers in Debian > > already. So the question is: is this sufficiently better to justify the > > effort? > > > > The main thing I'm concerned about here is security. Writing HTTP code > > is notoriously difficult and I'm sure there have been thousands of CVEs > > over the years related to it. So off the bat, writing one's own > > HTTP-parsing code implies a base-level risk. > > > > I note you have made a solid effort to use good shell quoting > > practices -- excellent. Remember that on most Linux filesystems, every > > 8-bit character except 0x00 and '/' is valid in a filename. So, > > consider what would happen if you had to deal with a filename or a > > request: > > > > - Beginning with '-' > > - Beginning with "of=" > > - Contains '+', '?', ' ', or '&' > > - Containing %0D, %0A, %00, %20, %FF, or their unencoded versions > > - Is 1GB long (what does "read" do with that?) > > - Has headers that are 1GB long > > - Contains ANSI terminal-manipulation sequences > > - Contains a byte sequence that isn't valid UTF-8 while run in a UTF-8 > locale > > > > Just to pass on examples here... > > > > '+' should expand to a space, but urldecode() doesn't. > > > > Calling dd with of=blah would overwrite blah. > > > > The behavior of file could be significantly altered by a request > > beginning with '-'. > > > > I'm not really sure what an embedded NULL character would do. > > > > In short, it is extremely difficult to write a shell script that is > > robust against untrusted input, and I can immediately spot some > > potential issues here. Log/verbose output may additionally scramble the > > user's terminal or otherwise conceal malicious attempts. > > > > Besides that, it has some important missing functionality. Most > > importantly, because it doesn't support HTTP/1.1, it doesn't support > > ranged requests (resumption) or a way for the client to know > > affirmatively if it got the entire file. Of course, it is also quite > > inefficient but that may not matter too much for the intended use case. > > > > So, as an example program, this is fantastic. As something that Debian > > as a project would like to support users actually using, is has some > > notable drawbacks against the minimal option already included in Debian
