Let's say hypothetically that it's a bad strategy to give your employee a C compiler and tell them to write code. Now, if you instead gave your employee a C compiler and told them to write code with vigilance and discipline, is that somehow now a good strategy? I don't think "Lack of vigilance and discipline" is a correct or incorrect diagnosis. I think it's a useless diagnosis.
> "It is all but impossible to keep track of what you depend on, and how safe it all is"
I think this space is ripe for exploration. Imagine a world where you could depend on your choice of JSON parser. One such JSON parser is allowed to perform arbitrary IO, and another is disallowed from doing so - at a language level. Would you ever pick the first over the second? Being able to distinguish one from the other would go a long way towards feeling safe about dependencies. From a safety perspective, it wouldn't even matter how much extra transitive crap the parser pulls in. If someone hijacks the 'isEven' package, what's the worst that could happen? Go into an infinite loop or return the wrong value? Both of these would be immediately flagged by the most casual level of tests, and be far preferable than abitrary code execution.
> I think this space is ripe for exploration. Imagine a world where you could depend on your choice of JSON parser. One such JSON parser is allowed to perform arbitrary IO, and another is disallowed from doing so - at a language level.
Obligatory remark that we used to have this as a real worked-out feature, with Java's SecurityManager. The newer WASM Component Model is supposed to be going in much the same direction.
Sandboxed is better than unsandboxed, but don't mistake it for being secure. A sandboxed JSON parser can still lie to you about what's been parsed. It can exfiltrate data by copying secrets to other JSON fields that your application makes publicly visible, e.g. your config file may have DB access secret and also a name to use in From in emails. It can mess with your API calls, and make some /change-password call use attacker's password, etc.
You seem to have a very narrow understanding of the utility of language purity and effects systems.
Yes, the parser can lie to you. But the actual lying can only depend on the code you are parsing. No it can't just exfiltrate data by copying it into other messages.
I've said fields, not messages. It can exfiltrate data by copying it between fields of the single message it parses.
Imagine a server calling some API and getting `{"secret":"hunter2"}` response that isn't supposed to be displayed to the user, and an evil parser pretending the message was `{"error":{"user_visible_message":"hunter2"}}` instead, which the server chooses to display.
I'm trying to puzzle this one out a bit. Who are the good and bad actors in this threat model?
I wrote a server:
myServer = do
fetched : Bytes <- fetchFromExternalApi
let parsed : SecretResponse = jsonParse fetched
return parsed
This code is all mine except for the jsonParse which i imported from a nefarious library. If jsonParse returns a SecretResponse, then the code will compile. If jsonParse returns an ErrorResponse, it won't compile.
In more mature implementations a simple "doesn't parse" doesn't cut it. You may want to get specific error codes to know if you should retry the request, or blame the user for bad inputs, or raise an alarm because the API changed its schema unexpectedly. You'll also want to report something helpful to the end users, so they can understand the issue or at least have something useful to forward to your tech support, so you don't just get "the app is borken!! don't parse!!11".
JSON APIs often have a concept of an envelope that gives them a standard way to report errors and do pagination, so the message would have been parsed as some Envelope<SecretResponse>, or reparsed as an ErrorResponse if it didn't parse as the expected kind.
JSON is used in lots of places where lying about the content could cause trouble, and this is just one hypothetical example. I just want to bring attention to the class of attacks where a malicious dependency can lie through its normal API, and may have opportunity to turn its caller into a Confused Deputy instead of having to break out of the sandbox itself.
I like this take, I think it's more of a red flag that vigilance and discipline is a necessity. There must be strategies that minimise this.
To take HN's fave example Rust: it has a type system that removes "viligance and dicipline" as a requirement for memory management. We don't need as much care if we can codify checks and standards that make bad practices (null pointers etc) impossible.
I work mostly in Python, and even using neat tools like Vulture, dead code elimination is a mostly manual, care-requiring task. I wonder if there's a neat way to bring down excess code- I don't have any new ideas though.
I'll grant you that, but I would argue that 'unsafe' is the exception, definitely not the rule. The fact that there's a required keyword sort of gets at what I was driving at.
I find it hard to believe that vigilance can be opted out of, unless—sarcastically speaking—you leave the company before the lack of vigilance becomes a problem.
I somewhat agree with your take but that "free lunch" is paid by a disciplined use of lifetimes, somewhat contradicting the claim of "removing vigilance and discipline by using Rust's type system/borrow checker". In my worldview, type systems are in fact a compiler-enforced discipline, but I see how productivity can be boosted once problem areas become more visible / less implicit. Problems don't really disappear, they only become easier to scan through.
Does the quality of the paint and canvas prevent a poor painter from applying 30 coats? No, and it's probably the same with programming languages. Adding a low wall in the driveway won't change anything.
Of course just mentioning the diagnosis will not fix the problem. That doesn't mean the diagnosis is useless. But using the diagnosis might take more effort than just telling engineers to fix it.
Same with a medical diagnosis. You don't expect to fix the issue by just mentioning the diagnosis to the patient and saying "fix it".
> Same with a medical diagnosis. You don't expect to fix the issue by just mentioning the diagnosis to the patient and saying "fix it".
That's what this is though. The slide deck author is the establishment - the person with the influence to effect change - telling the developers to just "do it better".
It sounds obvious when you say it but once you start looking out for it it's amazing how many people try to skip it.
Certainly further analysis of your local problem is called for but I think it's a bit silly to expect a slide deck on the internet to identify your specific problems and then provide you with specific solutions for your situation that are useful for you.
"A lack of vigilance and discipline" is a good diagnosis, and "write code with vigilance and discipline" is good advice.
Now, of course that does not spell a plan that you can blindly follow step by step, and that's good! It forces you to think about what this means for you and your team and to come up with strategies and processes that will fit your needs. This should not be too difficult for people in the field.
It might sound basic or obvious, but actually most commercially projects I have been involved with lacked both. It takes a firm leader to instil and maintain both.
I agree that the presentation is lax on solutions, but I think it is valid to say that lack of vigilance will not help us get out of this mess. Of course, telling developers to just try harder is never the solution - but part of the solution is make developers aware of another aspect of their work that has to be taken into account. This has to be resolved culturally first.
Pike laments the lack of sleekness, complaining about bloat and scolds us for not having terminal NIH syndrome, and in general recommends thoughts and prayers.
Which is a bit tone deaf coming from somebody who unleashed yet another bloat generator (optimized for delivering - uh, excuse my french - "shareholder value") on the world, and fails completely to reflect on his own contribution to the problem.
Let's say hypothetically that it's a bad strategy to give your employee a C compiler and tell them to write code. Now, if you instead gave your employee a C compiler and told them to write code with vigilance and discipline, is that somehow now a good strategy? I don't think "Lack of vigilance and discipline" is a correct or incorrect diagnosis. I think it's a useless diagnosis.
> "It is all but impossible to keep track of what you depend on, and how safe it all is"
I think this space is ripe for exploration. Imagine a world where you could depend on your choice of JSON parser. One such JSON parser is allowed to perform arbitrary IO, and another is disallowed from doing so - at a language level. Would you ever pick the first over the second? Being able to distinguish one from the other would go a long way towards feeling safe about dependencies. From a safety perspective, it wouldn't even matter how much extra transitive crap the parser pulls in. If someone hijacks the 'isEven' package, what's the worst that could happen? Go into an infinite loop or return the wrong value? Both of these would be immediately flagged by the most casual level of tests, and be far preferable than abitrary code execution.