I mean it is amusing, because this is never going to fly. This increase in complexity is completely unacceptable, what I see is completely amateurish, and I also see overflows, a lack of testing for edge conditions, and a lack of attention to how unveil works.
Luke Small <lukensm...@gmail.com> wrote: > You're welcome! I figured you might not want a “massive” diff to cap off your > day to > make a program that you apparently feel is secure enough, but I made good > that I got > off my ass and did something anyway. I’m surprised that you even went to the > trouble of > pledging it myself. It only took 2 or 3 days to figure out what it was doing > and change > it. I left in the fprintf()s to so that I could amuse you. > > I’m kinda surprised that you didn’t go straight for the “submit a diff. > Anything you > submit will just be rejected anyway!” > > On Wed, Jun 3, 2020 at 9:39 AM Theo de Raadt <dera...@openbsd.org> wrote: > > Thank you for the laugh. > > Luke Small <lukensm...@gmail.com> wrote: > > > I think I'm done tinkering. try these out in ftp folder. I left in some > > fprintf(ttyout,...) in main.c > > to show what is being unveiled. It resolves shortcuts in SSL_CAFILE > > and SSL_PATH variables. > > It leaves in place the functionality of the original functions, but adds > > the availability to perform > > a dry run pass to load an unveil list of potential files from which to read > > and create/write. > > The only potential bug is perhaps if in the followup unveiled pass if it > > has a problem with dns resolution or > > something, it may be unveiled and drop into a command line. I'm not sure. > > > > The diff is of the three files below vs the originals since I last updated > > the source files. > > > > -Luke > > -- > > -Luke > > -- > -Luke >
