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

DeVault: Announcing the Hare programming language

Posted May 2, 2022 9:35 UTC (Mon) by ddevault (subscriber, #99589)
In reply to: DeVault: Announcing the Hare programming language by mjg59
Parent article: DeVault: Announcing the Hare programming language

I don't think you understand the value-add this module aims to provide: it gets the keys out of your memory space. A TPM or Yubikeys may address this somewhat, but in an opinionated and complex way with out of band requirements. The purpose of this module is simply to provide an abstraction over Linux keyctl and future OS interfaces like it, nothing more.

to post comments

DeVault: Announcing the Hare programming language

Posted May 2, 2022 9:42 UTC (Mon) by mjg59 (subscriber, #23239) [Link] (42 responses)

Except it doesn't, if you run it on anything other than Linux it just puts your keys in the heap. If the value proposition of the module is that it gets keys out of your memory space, then it doesn't work as advertised. If I'm developing an app that wants to guarantee that keys aren't in userspace memory, then right now doing this in Hare means I need to know implementation details of the stdlib and refuse to run if I'm on anything other than Linux. If FreeBSD adds equivalent functionality and Hare adapts that, I need to update my app. This seems extremely obviously broken, and the moment you find one broken thing in a crypto library it's legitimate to start asking whether anything else is done properly.

DeVault: Announcing the Hare programming language

Posted May 2, 2022 9:49 UTC (Mon) by ddevault (subscriber, #99589) [Link] (41 responses)

Again, it's opportunistic. It's not broken. It just does not do what you want it to do.

DeVault: Announcing the Hare programming language

Posted May 2, 2022 9:52 UTC (Mon) by mjg59 (subscriber, #23239) [Link] (19 responses)

Me: "Please store this key securely"
Your library: puts it on the heap if I'm on any kernel other than Linux

Look if you can't understand that this is a thing that will happen in the real world and that people will potentially suffer as a result you shouldn't be writing a crypto library. The absolute best thing you could do right now is move the entire crypto directory out of your stdlib until it's fully reviewed by people who understand not only cryptography but also threat modelling.

DeVault: Announcing the Hare programming language

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

I feel no further need to engage with you here.

DeVault: Announcing the Hare programming language

Posted May 2, 2022 9:59 UTC (Mon) by mjg59 (subscriber, #23239) [Link] (3 responses)

Look it feels pretty obvious that shipping a crypto library that falls back to being insecure without any indication to the app in question is not a good design and I am extremely confused why you're being defensive about this rather than talking about ways you could add assertions that apps could opt out of or something along those lines

DeVault: Announcing the Hare programming language

Posted May 2, 2022 18:12 UTC (Mon) by bluss (guest, #47454) [Link] (2 responses)

It's literally the guy's hobby language, why go at him as if this is some twitter thread? I'm here for the hacking spirit and enjoying a good home-grown work, with faults and all.

DeVault: Announcing the Hare programming language

Posted May 2, 2022 19:00 UTC (Mon) by Natanael_L (guest, #158286) [Link]

The problem with doing that in the security field is that people who know less about security than the person who wrote the code will absolutely use it insecurely and never realize it, because most security failures are silent failures.

If you're doing it as a hobby, it should be your obligation to advertise it as NOT being secure enough for deployment for anything handling sensitive information.

DeVault: Announcing the Hare programming language

Posted May 4, 2022 15:46 UTC (Wed) by Ashton (guest, #158330) [Link]

I’ve always disliked this interpretation of how language creators and other programmers interact. Yes, Drew made this language on his own as a “hobby” (although I think this drastically understated how hard it is to make a language work well), but he’s also trying to convince us to use it. Unless if Drew is happy with only his projects using Hare, which I doubt is the case, how regular programmers will interact with the language and the standard lib matters a lot.

DeVault: Announcing the Hare programming language

Posted May 2, 2022 13:14 UTC (Mon) by ncm (guest, #165) [Link] (11 responses)

Someone who does not feel intensely motivated to learn from mjg59's freely offered expertise has no legitimate claim on anyone's attention.

DeVault: Announcing the Hare programming language

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

Oh good, hero worship.

DeVault: Announcing the Hare programming language

Posted May 2, 2022 17:02 UTC (Mon) by Lionel_Debroux (subscriber, #30014) [Link] (4 responses)

Hey SirCmpwn... You've done a number of interesting, thought-provoking and/or even useful things since your beginnings in the TI graphing calculators community a decade ago or so; however, you can and should do better than digging holes: mjg59's not wrong, you know it, and you have little to gain by opposing him that way ;)

DeVault: Announcing the Hare programming language

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

Do me the favor of taking my comments at face value. I earnestly disagree with mjg59's position, and what's more, with the way they presented it. I don't particularly enjoy arguing with people who are calling for me to be criminally prosecuted for designing a programming language that does not align with their sensibilities.

DeVault: Announcing the Hare programming language

Posted May 3, 2022 10:31 UTC (Tue) by nix (subscriber, #2304) [Link] (1 responses)

> I earnestly disagree with mjg59's position

You think "silently fails insecure if conditions not advertised outside the source tree happen to be true and no way to pick an alternative, but advertised as being extra-secure" is a good thing, really?

Meanwhile, supporting key storage in YubiKeys would fix this problem by being portable to arbitrary operating systems, plus it has relatively low cost for keys capable of such things, is *literally trivial* to implement because Yubico provide not only libraries in multiple languages but an actual written spec, and should be pretty easy to make work on any device capable of USB communication -- but you arbitrarily declare it as out of scope Or if not YubiKeys, how about one of the countless other devices, most free hardware, with the same capabilities? Or how about at least not claiming the library is secure when it's not? There are *so many* ways to get out of this hole ever so easily, but instead you're literally simply refusing to engage or fix this obvious problem in any of the dozen-plus ways available to you or even acknowledge that it is a problem... because you don't like Matthew's tone. This really does not fill me with enthusiasm for your new language at all.

DeVault: Announcing the Hare programming language

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

It is not automatically insecure on other systems. Like I've explained in other comments, this is one part of a system which provides defense in depth, and the lack of a kernel-provided key store does not create any vulnerabilities in your application on its own. What's more, it was never advertised as "extra-secure", in fact, it's advertised as quite the opposite, with clear documentation explaining its limitations, a disclaimer that it has not been audited, and emphasis given on the importance of good cryptography as it pertains to the life and security of your users.

Again, the YubiKey suggestion lacks an understanding of the scope of this module and of the standard library in general.

DeVault: Announcing the Hare programming language

Posted May 4, 2022 15:46 UTC (Wed) by Ashton (guest, #158330) [Link]

You don’t have to keep engaging with mjg59 if you don’t want to, but belittling people who agree with them as mere hero worshipers is beyond the pale. Remember that in asking us to use your language, you’re asking us to also trust you in your stewardship of that language and how you’ll respond to our concerns and needs as the maintainer. Seeing you attack people so aggressively out of the gate is not a confidence boosting start.

DeVault: Announcing the Hare programming language

Posted May 2, 2022 18:40 UTC (Mon) by Wol (subscriber, #4433) [Link] (1 responses)

If you want to be a devil that's your problem.

Telling a well known expert he's clueless is going to get pretty much everyone here writing you off as not worth paying any attention to. (I'd pretty much done that already, but this really does hammer the point home!).

Cheers,
Wol

DeVault: Announcing the Hare programming language

Posted May 2, 2022 19:42 UTC (Mon) by corbet (editor, #1) [Link]

...and this kind of comment really doesn't help the situation either. Please can we try to calm things down a bit?

DeVault: Announcing the Hare programming language

Posted May 3, 2022 4:43 UTC (Tue) by rsidd (subscriber, #2582) [Link] (2 responses)

I don't think such comments, or your defensive reaction to mjg59's security concerns in general, will persuade people to try out Hare. You are very smart, but so are other people, and they may have expertise you don't (mjg59's crypto contributions speak for themselves).

DeVault: Announcing the Hare programming language

Posted May 3, 2022 5:04 UTC (Tue) by mjg59 (subscriber, #23239) [Link] (1 responses)

Oh, to be clear, I am not qualified to do cryptography - I have opinions in the broader security space and how cryptography applies to that, but on the crypto side I am not someone you should pay attention to.

DeVault: Announcing the Hare programming language

Posted May 3, 2022 7:00 UTC (Tue) by rsidd (subscriber, #2582) [Link]

I guess I meant applied crypto -- ie, your work on secureboot in particular -- not crypto algorithms!

DeVault: Announcing the Hare programming language

Posted May 6, 2022 15:17 UTC (Fri) by daniel.glasser (guest, #97146) [Link] (1 responses)

If there is no underlying secure key storage mechanism on a system, then no amount of abstraction in the library will be able to provide one. Even for a given hardware architecture and OS, there may be differently provisioned systems. If an application requires hard security beyond the best effort that the standard interfaces provided by Hare, or any other language, that application should not use the built-in tools and instead use an alternative that enforces the dependency on an underlying facility provided by an OS or hardware.

Secure key management can be difficult and not at all portable in my experience. Hare, and its libraries, are fairly new. No doubt, given enough exposure, there will be improvements as those libraries evolve.

DeVault: Announcing the Hare programming language

Posted May 6, 2022 16:55 UTC (Fri) by farnz (subscriber, #17727) [Link]

If there's no underlying secure key storage mechanism, why provide a "secure key storage" library on that platform? If you're going to provide one that's best effort, why not provide a mechanism for the programmer to confirm that it's not using the heap, but instead using a secure storage location?

And note that the core problem is not so much that the library as it exists now is problematic (after all, Hare has not yet been ported to a non-Linux platform), as the attitude underlying it that the programmer can't be trusted to do the right thing if the library tells the programmer what the true state is. That's not a good look for a language whose claimed USP is that it "trusts the programmer" - if the programmer can be trusted, a simple "bool is_secure_storage()" would be enough.

DeVault: Announcing the Hare programming language

Posted May 2, 2022 13:14 UTC (Mon) by HelloWorld (guest, #56129) [Link] (10 responses)

> Again, it's opportunistic. It's not broken.
In a security context, being opportunistic is broken.

DeVault: Announcing the Hare programming language

Posted May 2, 2022 13:19 UTC (Mon) by ddevault (subscriber, #99589) [Link] (9 responses)

That's not how this works. Opportunistic improvements are part of defense in depth. It improves security to use this module, but it is not *necessary* for security to use this module.

DeVault: Announcing the Hare programming language

Posted May 2, 2022 14:54 UTC (Mon) by farnz (subscriber, #17727) [Link]

So how do I conditionally compile Hare such that if a secure keystore isn't available, my code refuses to compile? This module isn't that, because it works cross-platform, even if there is no secure keystore available.

In effect, it's opportunistically downgrading my code if I move from a platform like Linux with a secure keystore to one without, and long experience shows that opportunistic downgrades are a really bad thing for security. An opportunistic upgrade would be if you (e.g.) detected use of the bytes::zero secure zeroing operation, and upgraded from "normal" storage to a secure keystore.

What I, as a developer doing my best to not add too many more security bugs to the world, is for my code to actively alert the next developer (which might even be me a few years later) if they are making decisions that contradict things my code assumes is true. This particular module does exactly the opposite - if I make decisions that are true assuming the keystore is secure (which is testably true on Linux), and then someone uses my code on FreeBSD (where it's not true in this version of the code), then the user who switches to FreeBSD has introduced flaws I wasn't expecting to have to handle.

DeVault: Announcing the Hare programming language

Posted May 3, 2022 10:36 UTC (Tue) by nix (subscriber, #2304) [Link] (7 responses)

The problem with opportunistic improvements in security, as we've seen with SSL over the years, is that as soon as an attacker gets involved it becomes clear that these are really *reductions* in security because an attacker can either force the selection of the least secure option or focus only on those for whom the opportunistic improvement did not kick in (thus reducing the overall security of the library to its least secure set of features).

Now maybe you're saying most people will never be attacked so there's no point worrying about this -- but in that case why encrypt anything at all? The whole point of encrypting things is to stop attackers from reading them! Maybe you think that most attackers won't be sufficiently dedicated... but it only takes one attacker to write a tool to do whatever thing you think is difficult and suddenly it's easy and every script kiddie is doing it.

DeVault: Announcing the Hare programming language

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

I am familiar with the downgrade attacks that you are referring to, and they do not apply here. I would be very impressed if a man in the middle was able to force a victim into installing BSD instead of Linux in order to exploit some vulnerability - a separate vulnerability, to be clear, given that storing keys in the heap is not automatically a vulnerability.

DeVault: Announcing the Hare programming language

Posted May 3, 2022 12:59 UTC (Tue) by farnz (subscriber, #17727) [Link] (4 responses)

The specific concern I have is related to a user trusting the programmer. The problem here is that the language sets me up for a fall if I do trust the programmer.

Assume I'm administrating a FreeBSD fleet; I discover a need, and find a program written in Hare that fills that need. The documentation written by the programmer asserts several security claims that are true on the assumption that a secure keystore is used, and false otherwise. Being a conscientious sysadmin, before relying on the documentation, I first compile the program and run its test suite.

Here's where the pain lies - because there's no way for a Hare programmer to fail the tests if the keystore is not actually secure (but instead heap memory), I see a full set of passes. And then I get burnt because I trusted the programmer, but the language provided no way for the programmer to tell me that, because of my system choices, my trust is misplaced.

And this applies even if the programmer is conscientious - in autotools C, for example, I'd note that keyctl is not available, and not compile in the "in memory secure" keystore, because it's not present on this platform. It'd then be obvious to the conscientious sysadmin that in memory key storage is not available on FreeBSD, and that you need another implementation (be that PKCS#11, TPMv2, Yubikey, or whatever else the programmer designed in), or that I can't trust the security claims that depend on keyctl.

If Hare wanted me to be able to trust the programmer, there would at a minimum be a way for the programmer to prevent the code relying on the key store if it's not secure. That mechanism is not present here.

DeVault: Announcing the Hare programming language

Posted May 3, 2022 13:16 UTC (Tue) by ddevault (subscriber, #99589) [Link] (3 responses)

>The documentation written by the programmer asserts several security claims that are true on the assumption that a secure keystore is used, and false otherwise.

This is an error in the downstream software, not in Hare. We cannot prevent programmers from making untruthful claims about their software. And, *again*, storing secrets in the heap in the face of the lack of a kernel-managed keystore *does not directly make your program insecure*.

DeVault: Announcing the Hare programming language

Posted May 3, 2022 13:40 UTC (Tue) by farnz (subscriber, #17727) [Link] (2 responses)

It's also a bug in Hare, because it claims to be a secure keystore, but it's not on some systems. And while storing secrets in the heap does not directly make your program insecure, I'm not talking about that - I'm referring to the case where the program does things to ensure that it's secure as long as the keys are not on the heap or stack outside of the times they're used.

And again, it's trivial to fix in Hare - just an is_secure_store function that returns true on Linux, false on other platforms for now.

DeVault: Announcing the Hare programming language

Posted May 3, 2022 13:43 UTC (Tue) by ddevault (subscriber, #99589) [Link] (1 responses)

Again, the "claims" it makes are, verbatim, the following:

> On platforms without a suitable feature, a fallback implementation stores the secrets in the process heap, providing no security. This is an opportunistic API which allows your program to take advantage of these features if available.

In my opinion, this is very clear.

DeVault: Announcing the Hare programming language

Posted May 3, 2022 13:45 UTC (Tue) by farnz (subscriber, #17727) [Link]

And in my opinion, it's not clear at all - which platforms have secure storage? How do I tell my users that they've chosen a platform that doesn't work the way I want it to? How do I prevent use of the keystore when it's not actually secure?

DeVault: Announcing the Hare programming language

Posted May 3, 2022 13:45 UTC (Tue) by nix (subscriber, #2304) [Link]

> I would be very impressed if a man in the middle was able to force a victim into installing BSD instead of Linux in order to exploit some vulnerability

They wouldn't. They would search the set of people using whatever-it-is and filter out those running Linux, knowing that *all the rest* were storing the keys on the heap and they could use heap spraying or whatever. (For which they'd probably need another vulnerability. They're very good at chaining these things together...)

DeVault: Announcing the Hare programming language

Posted May 2, 2022 16:23 UTC (Mon) by wtarreau (subscriber, #51152) [Link] (9 responses)

Such desired behaviors usually depend on the exact use cases. Someone developing a certs-unlocking mechanism for a webserver that needs to run under any circumstances will value the "do this, preferably in a secure way" approach. A user storing GPG keys on a shared system at school will rather think "do this but only if it can be done in a secure way". There's no technical one-size-fits-all solution here, it's often a matter of choice (e.g. by configuration or API). That the same problem as the INSECURE flag to get randoms actually: you want to play Tetris regardless of the random strength but you don't want to produce your server's ssh key from bad randoms.

DeVault: Announcing the Hare programming language

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

I agree. I will also note that reading the documentation is mandatory, especially for security-sensitive use-cases, where the following is clearly stated:

If that's not suitable for your needs, then you need to use something else.

DeVault: Announcing the Hare programming language

Posted May 2, 2022 16:56 UTC (Mon) by dkg (subscriber, #55359) [Link] (7 responses)

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?

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.