Adam, Thank you for your response below. I have comments on three subjects.
1. Some people feel that programs should not be accepted to Debian if they aren’t unique enough or if they are too ambitious. Although I feel this is an important question for an upstream developer to ask themselves, I personally do not like to use this criteria to determine if someone else’s work should be included in Debian. Every single program we use and love would have been vetoed at some stage by the criteria, “it doesn’t do anything unique” or “it is too big of a task for you to undertake”. Using this as criteria prevents innovation. 2. Upstream willingness to support the program over time is an important criteria for inclusion in Debian. Based on what I have seen of your upstream work and what you have written below, it would appear to me that you are committed for the long haul. But to be explicit, are you planning to continue development on bashbro, and particularly provide security support, for the next several years? 3. The security concerns that John raises are legitimate questions, and I appreciate him doing so. If you subscribe to DSAs (Debian Security Advisories), it is obvious that never having a security issue is not a requirement for inclusion in Debian. However, what is a requirement is that a reasonable effort has been made to harden the software and remove obvious security vulnerabilities, along with a commitment to respond swiftly when security problems are discovered. You have addressed a number of aspects of your security design below. I feel pretty good, based on your description, that you have spent some time thinking about how to design bashbro securely. Perhaps it would be helpful to me if you could address what would happen in the following circumstances that John listed explicitly: > 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 Note that my opinion is not the final word on this subject. When I feel satisfied the package is ready for inclusion in Debian, I sponsor it, which means I attach my signature and my reputation to it. But, because it is a new package, it then goes to the FTP Masters team for review. I have found them to be very thorough. If we have done our work well, it will pass through their review without comment. The more we can do now to flesh out all these issues the more likely we will to clear the FTP Masters hurdle without problem. On Wednesday, September 4, 2024 9:52:28 PM MST Adam Danischewski wrote: > 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&exclud > eFilters=&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= -- Soren Stoutner so...@debian.org
signature.asc
Description: This is a digitally signed message part.
