Does this language have some kind of assessment for working in a classified environment? I am trying to determine the eligeability and I have not been able to find anything as of yet. I see memory safe languages are recommended, but Julia is not named in any of the CISA/NSA/FBI lists of approved languages. Thanks!
Most likely it does not have this kind of assessment. Try to get it assessed. But I have no idea who is usually doing such an assessment, and who pays for it.
No. NIAP certifies commercial IT products, not programming languages used to make them. There is no list of American government-approved languages. You’re talking about a recent cybersecurity recommendation to shift to memory-safe languages, which:
- cannot address many security issues. For just one example, Python and Ruby are explicitly named as memory-safe, and those have
evalor similar functions that allow easy source code injection, no memory vulnerabilities needed. Julia is in the same boat. - have exceptions to eliminate redundant safety checks or implement safe operations in the first place. Notably, Rust strictly delineates this on the language-level with
unsafe. Julia has plenty of ways to opt out of default memory safety, like@inbounds. - vary wildly in memory safety features. For example, eliminating data races could be anywhere from guaranteed to opt-out to opt-in. Julia is in the latter half of that spectrum.
- aren’t mandated. Notoriously memory-unsafe languages like C and C++ are still allowed, especially as dependencies for more convenient memory-safe languages including Julia. Porting everything is explicitly discouraged on occasion.
There’s no replacement for static analysis and tests. Languages just vary what needs to be verified and how often. Memory safety features are only one broad factor and can be outweighed by the availability of security assessment tooling.
I think the information you are looking for would come from JuliaHub (the company) since they would need to have the certifications to work with government agencies. I imagine they have some assessments just based on the groups listed on the JuliaHub customer page. Poking around the JuliaHub website, or a short email to them, would probably answer most of your questions.
Thank you, I will try there!
Julia is arguably as memory-safe, or more, than Python (or most languages, likely Ruby too), assuming you run as:
julia --check-bounds=yes
[If you don’t do that, it’s still more memory safe than C or C++. Just you trust the programmer to not opt out of the safety for speed, which is done selectivity in Julia, unlike C or C++, sort of more like Rust.]
Which gives same default as Python an Java etc.
Python relies much more on calling fast code another languages, e.g. unsafe language like C. That’s also possible in Julia with e.g. ccall keyword (and happens with _jll dependencies). Even memory-safe languages like Rust allow that in unsafe regions.
When you call other languages (in Julia with ccall or indirectly do that, with dependency code, usually _jll), e.g in C language, then you rely on that code, i.e. it’s no more safe than that (trusted, but potentially buggy) code.
I would find this a very ambitious position to defend, and I would not recommend advertising the language this way.
Why though? Maybe the more part is too ambitious, but what about saying it is as memory-safe as Python?
because I think it is much easier to encounter unsafe memory access in julia than it is in python.
A non-default flag specifically for ignoring @inbounds has no equivalents in Python or Ruby, so the comparison is more of an opinion. A Pythonista could just as easily use the same facts to argue that base Python doesn’t let you shoot yourself in the foot with @inbounds, that the unsafe stuff is in other languages where it belongs (two-language solution).