> On Mar 22, 2017, at 4:07 PM, Elijah Johnson <ejrx7...@gmail.com> wrote: > > Hi, > > Note that this thread has branched off a bit, so my latest proposal and the > “head” of this thread can be found at > https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170320/034189.html > > > > Can you give an example of this corruption which would be exploitable in a > web server context? An example where, having caught the force-unwrap or other > precondition fatalError, that the web server would face more danger from > continued execution that it would loose by crashing? > > The optional has been triggered, the request has been stopped, and incoming > requests are going to a new process, but there are a few threads open still > finishing what they were doing - I’d like to see a good example of the danger > caused by a real “inconsistency”. Lets assume also that all objects shared > between threads are Swift objects and not “UnsafePointers”, which is a very > fair assumtion for a web server. Java even allows native access and they > don’t even crash there.
When considering security threats, we have to take the presence of an exploit as given until we prove otherwise. A precondition failure indicates a logic error somewhere in the program, and while safe Swift abstractions are intended not to lead to memory unsafety in the face of precondition failures, there's plenty of relatively young, unsafe code below the hood in the implementations of those abstractions, written by humans who make mistakes. Whatever lurking security bugs there may be, they're more likely to be exploitable if you're already in a situation where assumptions have been violated. > I’m sorry, but I completely fail to grasp the danger as being > crashing. Crashing is inconvenient. The user may have to retry their request or relaunch their app. Security breaches or data corruption are disasters that can have unbounded impact and cost—you can't undisclose sensitive data. > I’d be interested to know who these web server developers (ex. Kitura, Vapor) > are targeting without any form of crash handling and if they read these > threads. It really limits the pool of developers more so than on apps because > a single crash on the app ie equivelant to a failed request, not a crashed > web server. I realize you are not competing with Java, but I do not see yet > the compelling reason for no crash handling. > > The “actors” with thread pool and proccesses is one idea, but I think these > servers are aiming also for speed and scaleability - don’t know if they would > accept this model. I know that it does get used, and do work for a company > that uses it on their backend (just plain Java, not sep. processes). Their > front-end probably runs like a pre-fork server, but Java is so stable that > there is simply no need for that. You can use processes for fault isolation today, and that will have some cost. At Swift's current maturity level, that's really probably the only responsible isolation strategy. The goal of "actors" would be to get most of the benefits of processes through language-level isolation without paying the full cost of processes. -Joe _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
