Adam, Thank you for going into detail on these. I find your analysis and examples to be persuasive.
As I mentioned in a previous email, I think it would be easier to maintain the Debian package if the packaging repository were converted to the gbp format. However, doing so is not a requirement for me to sponsor your package. Please let me know if you would like me to build from your current repository or if you would like me to wait because you are planning to use gbp. Either way, there are a few additional checks I do after I build the package myself. Mostly along the lines of personally verifying the checks Mentors and Phil have already done. Assuming I don’t see any problems I would feel comfortable sponsoring the package. (And if I do see anything, it is usually easy to address.) On Friday, September 6, 2024 11:10:26 PM MST Adam Danischewski wrote: > Hi Soren, > > Thanks for helping, here are my responses to your questions: > > 1) More unique features are definitely on the horizon with Bashbro, I > mentioned some in response to John's comments but > there are others like colorized highlighting of files based on > extension/type and an updated UI. > > 2) Yes! I plan to continue supporting Bashbro for the foreseeable future, > 5+ years. > > 3) I have been considering security concerns along the way. The code wasn't > originally intended for enterprise production use, > but I haven't found any security holes. The options handling is fairly > robust - that's probably the main vector of concern, the shell > variables in the code are scope restricted. I think John may have > glanced over the code quick and formulated his queries based on > his past coding experiences and not the actual code, but his concerns > aren't completely unrealistic. > > See my answers (*<<+Ad>>*) to the specific scenarios below: > > Here is an image of my test data: https://ibb.co/L9fvYKR > > > 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 '-' > > *<<+Ad>> Filenames starting with and/or containing dashes are handled, I > retested to make sure. * > > > - Beginning with "of=" > > *<<+Ad>> Filenames starting with of= are handled, I retested to make sure. > (Guess he noticed I'm using dd)* > > > - Contains '+', '?', ' ', or '&' > > *<<+Ad>> Filenames containing '+', '?', ' ', or '&' are handled, I > retested to make sure.* > > > - Containing %0D, %0A, %00, > > *<<+Ad>> These work if encoded but are not supported if not encoded at > present, null bytes can't be in filenames so that's moot. * > *Line feeds can be in filenames but will break things that read line by > line. It's not a common scenario, it will not make a security * > *hole but it won't function properly - the code will see two files although > only one is there and if you try to access it it will not find the * > *imaginary file. * > > %20, %FF, or their unencoded versions > > *<<+Ad>> Filenames %20, %FF work properly coded or unencoded. * > > > - Is 1GB long (what does "read" do with that?) > > *<<+Ad>> Not sure what he was getting at, read supports reading 1GB+ files, > there is a limit on line length though at 4096. * > *I haven't seen any security vectors related to read along these lines. * > > > - Has headers that are 1GB long > > *<<+Ad>> This goes to the previous, the code uses read. * > > > - Contains ANSI terminal-manipulation sequences > > *<<+Ad>> They aren't stripped, if they are part of the filename (perhaps by > accident) then Bashbro will allow the user to access/display them. * > * Not a security concern. * > > > - Contains a byte sequence that isn't valid UTF-8 while run in a UTF-8 > > *<<+Ad>> The encoding for links is actually handled by the browser in the > current version of Bashbro, so if the browser doesn't care (and it * > *might not) - in that case it would probably simply encode the filename in > hex and pass it out as a link for Bashbro. The user would then be * > *able **to access the file although **it's not valid UTF-8. Probably not a > security concern. * -- Soren Stoutner so...@debian.org
signature.asc
Description: This is a digitally signed message part.
