DeVault: Announcing the Hare programming language [LWN.net]

DeVault: Announcing the Hare programming language

Posted May 2, 2022 16:56 UTC (Mon) by dkg (subscriber, #55359)
In reply to: DeVault: Announcing the Hare programming language by ddevault
Parent article: DeVault: Announcing the Hare programming language

Drew, the feedback you're getting here is good feedback. You'd do the hare project a favor by listening instead of explaining why you're right and they're wrong.

I agree that opportunistic security can useful. But there are circumstances where the developer needs a guarantee, not opportunism. If Hare had an explicit method for requiring secure storage of keys during compilation, which would fail if the underlying OS doesn't offer support, then a developer who wants a strong security guarantee can have it, and a developer who is happy with the opportunistic approach could have it too.

And, some future static analyzer could look for instances of opportunistic use in systems that really need to offer stronger guarantees by seeing which interface was selected.

You're introducing a programming language to an interested potential user base here. Why sabotage the introduction by defensively rejecting useful feedback?

to post comments

DeVault: Announcing the Hare programming language

Posted May 2, 2022 16:59 UTC (Mon) by ddevault (subscriber, #99589) [Link] (6 responses)

I am actually somewhat open to the idea of extending the crypto::keystore interface to support mandatory security, though I think that some commenters are failing to understand it's design scope - things like YubiKey integrations fall well outside of that scope. I am not, however, particularly receptive of feedback from Rust cultists who, in this very thread, have suggested that I should be criminally prosecuted for use-after-free bugs found in downstream Hare programs.

DeVault: Announcing the Hare programming language

Posted May 2, 2022 18:22 UTC (Mon) by wtarreau (subscriber, #51152) [Link] (5 responses)

The point to keep in mind is that the vast majority of code written in modern languages is copy-pasted from stackoverflow or even probably github copilot because these languages are so painful and stubborn that when you don't know how to express something that sounds simple and the compiler refuses, you have to attack it another side and at some point you run out of ideas. And *that* is exactly the problem: users getting used to blindly copy-pasting code before thinking rarely read the doc. In certain programs it's so obvious that the function doesn't even do what its name suggests, or it fails to produce correct outputs for some special values. If your crypto lib relies only on the doc, there will be failures in field, in either direction (too strict or too lose). Instead, pass an argument so that the user explicitly expresses their intent, e.g. opportunistic or mandatory. This way if they fail after copy-pasting, well, there's hardly anything more that can be done to save them from seeking a totally different job that doesn't involve a keyboard (nor a mouse).

DeVault: Announcing the Hare programming language

Posted May 2, 2022 18:28 UTC (Mon) by ddevault (subscriber, #99589) [Link] (3 responses)

Accommodating negligent programmers are a use-case we have deliberately decided to eschew. A Rust programmer could equally come up with severely flawed code copy-pasting from StackOverflow, compilers cannot completely solve human stupidity.

Even so, we do not rely entirely on the docs. Again, crypto::keystore is just a small part of a larger secure system, and with defense in depth its failure is unlikely to be an issue. Using crypto::keystore on a system without secure kernel key management does not actually introduce a security bug - it just gives an opportunity for exploitation if you find *another* bug which allows you to read arbitrary memory from the process (the likelihood of which is prevented, again, defense in depth, by things like bounds-checked slices). Our other cryptographic APIs are also designed to make errors as unlikely as possible, such as via mandatory error handling and automatic zeroing of caller-provided private data.

DeVault: Announcing the Hare programming language

Posted May 3, 2022 10:26 UTC (Tue) by peter-b (guest, #66996) [Link] (2 responses)

> Accommodating negligent programmers are a use-case we have deliberately decided to eschew.

Aww, shucks. As a programmer who sometimes writes less than perfect code, it sounds like Hare is not for me.

DeVault: Announcing the Hare programming language

Posted May 3, 2022 10:27 UTC (Tue) by ddevault (subscriber, #99589) [Link]

There's a difference between negligence and simply writing poor code. I don't think this is worth writing Hare off over.

DeVault: Announcing the Hare programming language

Posted May 4, 2022 4:01 UTC (Wed) by timrichardson (subscriber, #72836) [Link]

That is so out of context it's not funny.

DeVault: Announcing the Hare programming language

Posted May 2, 2022 19:48 UTC (Mon) by mathstuf (subscriber, #69389) [Link]

> The point to keep in mind is that the vast majority of code written in modern languages is copy-pasted from stackoverflow or even probably github copilot

Interesting take. Any evidence for "vast majority of code"?

> because these languages are so painful and stubborn that when you don't know how to express something that sounds simple and the compiler refuses, you have to attack it another side and at some point you run out of ideas.

Ah, yes, because I enjoy having to figure out what data is tracked by which mutex manually (and somehow communicating this to everyone else that works in the vicinity) instead of the compiler saying "uh, hey, did you forget to consider threads here?". Yes, much better when I have to pick up someone else's debugging state to figure out what went wrong. Repeat for uninitialized data, memory management miscommunications, single-threaded code being improperly used from multiple threads[1], etc. </s>

If you're working in tricky areas, expect tricky code. I'd rather someone convince the compiler that they got it right instead of expecting anyone else coming along and fixing warnings or whatever tripping over those 3 lines that took an hour to get right because threads are hard and the comment was ignored by `clang-tidy -fix` and a rubber stamp review.

[1] I agree with you: docs are not enough, you need something more. Rust's `Sync` trait seems to do well enough.