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

DeVault: Announcing the Hare programming language

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

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.

to post comments

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.