I'm sure you mean negative externalities that your customers aren't equipped to appropriately price.
tl;dr nearly all of Rust is geared towards trying to solve problems I am not interested in, but it isn’t really the ‘borrow checker’ area that I personally find most off putting.
1. Don't assume that packages come from Github. Or from any specific URL, for that matter. Or that they're managed in Git. Make it controllable with a config file, and ship a default config file. Let a project-specific config file override a site-wide one.
2. Make sure packages can come from multiple sources.
3. Make it possible to use packages from the local filesystem. Support relative paths.
4. Don't try to do network access unless I specifically ask for a fetch/download/update/etc. I want to be able to extract a few source tarballs somewhere, and then run a build that doesn't require me to be online.
5. Have a good story for working with non-Zig libraries. Like if I want to make a FUSE filesystem or something, it probably depends on having libfuse and libfuse-dev installed from my distro package manager. Zig's package manager doesn't need to interact with apt-get or whatever, but it would be great if it knew how to find local headers and libraries.
6. Include a way for me to generate a source-tarball that bundles the sources for all of my program's dependencies, so that I can archive it and reproduce a build later even if the upstream sources go away.
7. Include a license tracking/reporting mechanism, so that I know the licenses of all software I've pulled in as a dependency (whether directly or indirectly). I don't want a situation where I have some dependency that has another dependency on another dependency, and 3 levels down there's something that's got a license I can't ship. The Yocto project did this in a very smart way, and it's a good model to copy.
8. Have a way to express build-time dependencies and run-time dependencies. Those aren't necessarily the same thing, and might not even target the same platform.
First, I am of the opinion that any centralized package management inevitably leads to heavy reliance on those packages. The comments of ‘there is a crate for that’ or ‘just look on NPM’ or ‘it’s on PIP’ are often the first answers anyone gives to people looking to write code to do a certain thing. That leads to towers of imports and dependencies. I am fundamentally opposed to not writing the simplest and most specific code for any given problem. Package management is a type of institutional environment directly opposed to that fundamental opinion. I am not interested in generic, allegedly re-usable, solutions, I want the most simplistic/direct solution/implementation I can code. Now sometimes that solution is a library and sometimes that library is complex, but that is a decision that is made purposefully and with the knowledge that the dependency MUST be managed as though the code was written by you. I think the package management paradigm being used/targeted by most modern languages assume that by using a dependency means I am outsourcing a potion of my code to others and that I am willing and able to change my code according to what changes with the dependency. I tend to only use direct source dependencies that I can make completely local and that code just becomes part of my program, and yes that means there are no updates to that code I do not make myself. An update of the dependency itself will only be included after reviewing the update as though it were a new dependency, i.e. purposefully and by me, not whenever the vendor wants and not whatever the vendor chooses.
I am aware that there is no requirement to use package management to incur what I find are negatives, but I truly believe that the environment and common usage patterns push development practice towards the type of coding practices I dislike.
Second, for work purposes, I can not use any code I can not warranty as fit for purpose and conforming to terms of a given contract. This means that any code which has a ‘no warranty’ statement in the license (which is almost all library code in every language regardless of distribution mechanism) I can only use once I have reviewed enough of it and am confident enough in it that I can put specific functional guarantees in place regarding specific performance of contract terms. Package management systems, and their accompanying practices, are not particularly appealing when the package management strategy seeks to continually push updates and continually seeks to stack reliance on large dependency trees. I am often better off designing and programming something myself that attempting to review to an acceptable degree a tangled mess of dependency.
I find that, while often an explicit non-goal for most programming languages, I would best be served by explicitly bare source code libraries, which are stored and compiled locally, and are incorporated into a project purposefully and in the same manner as files authored by me. Again, I am aware my requirements are not industry standard and my opinions are not mainstream, but there ya go.
This in fact _hurts_ maintainability as you need to manage this heavy, recursive dependency tree. Ultimately it's not hackable. You can't just change that function to print a warning, rather you have to edit an entire library and work through it's taxonomy.
I'd note that Python is much better than others you list at this. Idiomatic python tends to be "batteries included" and shouldn't use too many dependencies other than those that are crucial to the project (ex Numpy). It's probably also because Python's package management story isn't as polished as others.
You want the rural living version of programming languages. Package management is a dense urban core.
Great that your customers are on the safe side.
Ironically enough this is the one class of bugs that Rust would not have prevented out of the box since the language defines integers to be wrapping and you need to manually opt into runtime checks.
The exploit:
https://secret.club/2021/04/20/source-engine-rce-invite.html
Wrapping in Rust:
https://huonw.github.io/blog/2016/04/myths-and-legends-about...
https://scattered-thoughts.net/writing/how-safe-is-zig/
I hope that explains how inappropriate is the tone of your comment.
The equivalent underflow mistake in Rust probably panics. However the RCON trick at the heart of Steam which is powering this lets you run any command as the victim if they accept your "invite" so crashing their game is almost certainly already an option without the underflow.
What is the solution for use-after-free on Zig today, that isn't just like using Purify?
In other words, if you mean that use-after-free is handled in Zig in a manner that's very different from how it's handled in either Java or Rust and more similar to the general approach of how it's handled by various tools for C, then that's correct. If you mean that that general approach is just as (in)effective in Zig as it is in C, then that is incorrect. Because Zig is fundamentally more precise than C, analyses of Zig, even if they are conceptually similar to those done for C, can be more precise and effective.
Without pointer arithmetic, unsafe casts (Zig is much easier to write without such casts than C, at least), unsafe unions, and unknown buffer sizes, the set of pointers in a Zig program can be well-defined, as pointers can come into being only in very specific ways (they have a simple provenance). Because the set of pointers is well defined, it can be precisely tracked and analysed. This means that 1. pointers can be traced even with arena allocators or perhaps even other kinds of pools (provided they cooperate with the tool) and 2. dangling pointers can be detected even without being dereferenced. This is simply not something that analysers for C or C++ can do (at least not nearly as easily).
The way to think about it is that in Zig, when an object (including an allocator) is deallocated, you can invalidate the full set of pointers pointing to it, and that set it the only way of generating more pointers into it. That's not the case in C or C++. For one, pointers aren't well defined (unions); for another, a valid pointer could be used to create an invalid one.
So while the general approach -- of dynamic and static analysis, as opposed those of Java or Rust -- is in the same broad category of tools for C or C++, their effectiveness, due to Zig's properties, is significantly increased, and that their entire cost/benefit is different. I.e. it could find more bugs for a lower price, so much so that the approach, while underwhelming when applied to C or C++, could well compare favourably with others when applied to Zig.
(A GC -- whether tracing or ref-counting -- might well be adopted for Zig's comptime, but that's a whole other matter)
I'm highly skeptical that there won't be too many false positives with such a tool. Systems programmers routinely create temporary dangling pointers and let the values go dead without dereferencing those pointers. It happens most every time you call free, in fact.
I also see no reason why you couldn't create such a thing for C and C++. In fact, it exists: the Boehm GC can operate in such a checking mode. The fact that everyone uses ASan instead is a strong indicator that ASan is in fact a better approach.
Finally, precise tracing GC stack/register maps are a lot of work, especially in LLVM which has poor support for them. (I heavily looked into this for Rust.) Without a serious effort (and it is a lot of work) to generate them for Zig I have to consider it vaporware.
I'm not advocating for a specific algorithm. I merely used a hypothetical one to demonstrate that there is, indeed, a fundamental difference between Zig and C/C++, even when it comes to UAF.
> I also see no reason why you couldn't create such a thing for C and C++.
Because in C and C++ there is no precise set of pointers, and bad pointers can be created from good ones.
> In fact, it exists: the Boehm GC can operate in such a checking mode.
Which would not work effectively for the reasons I mentioned.
> The fact that everyone uses ASan instead is a strong indicator that ASan is in fact a better approach. ... I have to consider it vaporware.
So from your asserted premise that Zig is no different from C in this regard you conclude that what doesn't work well for C must not work well for Zig and use that conclusion as further evidence of your premise? Your premise is exactly what I contest. Zig is fundamentally different because pointers are known and you cannot manufacture bad pointers from good ones. To demonstrate that difference I sketched a hypothetical algorithm that could work well in Zig but not in C. To point out that my hypothetical example is "vapourware" completely misses the point.
You could try to argue that the fact that pointers in Zig are well-defined and can be created only in carefully controlled ways -- and so are fundamentally different from pointers in C -- cannot be effectively exploited, but I don't think that's an easy argument to make.
--------
(> especially in LLVM
Even if we were to talk about specific tools, there is absolutely no need to base them on LLVM. Zig is specifically designed so that backends are easy to write, and an analysis tool need not use the same backend used by the compiler for production code; in fact, switching backends is meant to be commonplace in Zig development, and it is expected that different ones will be used for development and production)
Zig does seem to have some properties that make precise pointer identification possible. But the right conclusion to draw from this is that Zig should use a tracing garbage collector. It's well-known how to use the pointer provenance properties you're talking about to achieve UAF protection: just implement a GC! Trying to get by with things like quarantining memory forever is not going to work in production, and the reasons why Zig programs will supposedly not be vulnerable to UAF problems are unconvincing. It is going to want a GC eventually.
I've repeated several times that I was merely demonstrating why Zig and C are fundamentally different when it comes to pointers. You're trying to poke holes at a straw man, and worse, you're doing that while drawing on the very premise which I'm refuting, i.e. that Zig programs and C programs are essentially the same. You could just as likely have assumed that Zig programs behave more like Rust programs (or Go programs), and at the time of deallocation there is just one pointer to the object, and voila, zero false positives.
I am not saying that a Zig program should behave like a Rust/Go/Java program, just that your arguments are begging the question. You start with the assumption that Zig and C are essentially the same and then use the resulting conclusions to shore up that very assumption. But Zig programs are about as different from C as they are from Rust.
You insist that if you're not Java or Rust then you must be C. Zig is so revolutionary precisely because it works like none of those. Now, I don't know if Zig's revolutionary design is revolutionarily good. It's far too early to tell. But basing your criticism on a false premise completely misses the mark.
Of course, it's okay to be skeptical of a new idea, just as I'm skeptical that a type-level shrine for accidental complexity is the way to go.
> But the right conclusion to draw from this is that Zig should use a tracing garbage collector.
I disagree, but that's a whole other discussion. But since you seem to claim that such a thing could exist and effectively work for Zig and not for C, it seems you accept both of my points: 1. that pointers in both languages are fundamentally different, and 2. that this can be exploited for analyses that are completely different in their effectiveness than those feasible for C or C++.
That’s the case in production mode. Your link says that checks are added for overflow in debug mode. Presumably that also includes underflow.
This is why Zig maintains these checks in ReleaseSafe mode and gives you wrapping operators (+%=, etc) when that's what you want.
[profile.ReleaseSafe] overflow-checks = true
And of course Rust has both Wrapping types and wrapping versions of each integer operation if you want those, although I think we can be confident that the sort of person who is shipping release builds with overflow checking isn't thinking far enough ahead to have decided what should actually happen when their variabes under/overflow so giving them the option is redundant.
Given that the problem here is they're Wrangling Untrusted File Formats and, unsurprisingly, they failed to do so Safely, they likely should have used WUFFS rather than Rust, or Zig, or any general purpose language.
So you’re saying that I was correct. Good to know.
https://www.bleepingcomputer.com/news/security/cs-go-valve-s...
Rust is trying to solve problems we don't have. Jai is too closed.