https://lwn.net/Articles/893327/ LWN.net Logo LWN .net News from the source LWN * Content + Weekly Edition + Archives + Search + Kernel + Security + Distributions + Events calendar + Unread comments + ------------------------------------------------------------- + LWN FAQ + Write for us User: [ ] Password: [ ] [Log in] | [Subscribe] | [Register] Subscribe / Log in / New account DeVault: Announcing the Hare programming language DeVault: Announcing the Hare programming language Posted May 2, 2022 8:19 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 > Author here, happy to clarify a few things. https://git.sr.ht/~sircmpwn/hare/tree/master/item/crypto/... - as an app developer targeting the standard library, how do I know whether or not my keys are going to be stored securely or not? ----------------------------------------- (Log in to post comments) DeVault: Announcing the Hare programming language Posted May 2, 2022 8:22 UTC (Mon) by ddevault (subscriber, #99589) [ Link] Well, if the kernel does not provide a feature like Linux's keyctl, then there is no secure means of storing keys available. So it's a best-effort interface to utilize the kernel feature if provided, and if it's not, then as a developer you don't have much by way of better options anyway. [Reply to this comment] DeVault: Announcing the Hare programming language Posted May 2, 2022 9:28 UTC (Mon) by mjg59 (subscriber, #23239) [Link ] There are certainly other ways to store keys securely! You could use a TPM, you could implement PKCS#11, you could support Yubikeys - doing this well is not purely a kernel issue. But even in the absence of any support, I have the option of "Don't do this thing if it's not going to be secure", and if the stdlib doesn't let me figure that out then I have questions about the assumptions made in the rest of the stdlib. This feels like a security feature that hasn't been developed by people who think about security. [Reply to this comment] DeVault: Announcing the Hare programming language Posted May 2, 2022 9:35 UTC (Mon) by ddevault (subscriber, #99589) [ Link] 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. [Reply to this comment] DeVault: Announcing the Hare programming language Posted May 2, 2022 9:42 UTC (Mon) by mjg59 (subscriber, #23239) [Link ] 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. [Reply to this comment] DeVault: Announcing the Hare programming language Posted May 2, 2022 9:49 UTC (Mon) by ddevault (subscriber, #99589) [ Link] Again, it's opportunistic. It's not broken. It just does not do what you want it to do. [Reply to this comment] DeVault: Announcing the Hare programming language Posted May 2, 2022 9:52 UTC (Mon) by mjg59 (subscriber, #23239) [Link ] 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. [Reply to this comment] DeVault: Announcing the Hare programming language Posted May 2, 2022 9:54 UTC (Mon) by ddevault (subscriber, #99589) [ Link] I feel no further need to engage with you here. [Reply to this comment] DeVault: Announcing the Hare programming language Posted May 2, 2022 9:59 UTC (Mon) by mjg59 (subscriber, #23239) [Link ] 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 [Reply to this comment] DeVault: Announcing the Hare programming language Posted May 2, 2022 18:12 UTC (Mon) by engla (guest, #47454) [Link] 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. [Reply to this comment] 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. [Reply to this comment] DeVault: Announcing the Hare programming language Posted May 2, 2022 13:14 UTC (Mon) by ncm (subscriber, #165) [Link] Someone who does not feel intensely motivated to learn from mjg59's freely offered expertise has no legitimate claim on anyone's attention. [Reply to this comment] DeVault: Announcing the Hare programming language Posted May 2, 2022 13:18 UTC (Mon) by ddevault (subscriber, #99589) [ Link] Oh good, hero worship. [Reply to this comment] DeVault: Announcing the Hare programming language Posted May 2, 2022 17:02 UTC (Mon) by Lionel_Debroux (subscriber, # 30014) [Link] 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 ;) [Reply to this comment] DeVault: Announcing the Hare programming language Posted May 2, 2022 17:04 UTC (Mon) by ddevault (subscriber, #99589) [ Link] 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. [Reply to this comment] DeVault: Announcing the Hare programming language Posted May 2, 2022 18:40 UTC (Mon) by Wol (subscriber, #4433) [Link] 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 [Reply to this comment] 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? [Reply to this comment] DeVault: Announcing the Hare programming language Posted May 2, 2022 13:14 UTC (Mon) by HelloWorld (guest, #56129) [ Link] > Again, it's opportunistic. It's not broken. In a security context, being opportunistic is broken. [Reply to this comment] DeVault: Announcing the Hare programming language Posted May 2, 2022 13:19 UTC (Mon) by ddevault (subscriber, #99589) [ Link] 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. [Reply to this comment] 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. [Reply to this comment] DeVault: Announcing the Hare programming language Posted May 2, 2022 16:23 UTC (Mon) by wtarreau (subscriber, #51152) [ Link] 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. [Reply to this comment] DeVault: Announcing the Hare programming language Posted May 2, 2022 16:25 UTC (Mon) by ddevault (subscriber, #99589) [ Link] I agree. I will also note that reading the documentation is mandatory, especially for security-sensitive use-cases, where the following is clearly stated: > 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. If that's not suitable for your needs, then you need to use something else. [Reply to this comment] DeVault: Announcing the Hare programming language Posted May 2, 2022 16:56 UTC (Mon) by dkg (subscriber, #55359) [Link] 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? [Reply to this comment] DeVault: Announcing the Hare programming language Posted May 2, 2022 16:59 UTC (Mon) by ddevault (subscriber, #99589) [ Link] 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. [Reply to this comment] DeVault: Announcing the Hare programming language Posted May 2, 2022 18:22 UTC (Mon) by wtarreau (subscriber, #51152) [ 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 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). [Reply to this comment] DeVault: Announcing the Hare programming language Posted May 2, 2022 18:28 UTC (Mon) by ddevault (subscriber, #99589) [ Link] 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. [Reply to this comment] 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. 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. [Reply to this comment] Copyright (c) 2022, Eklektix, Inc. Comments and public postings are copyrighted by their creators. Linux is a registered trademark of Linus Torvalds