5 ms·

The repo includes a DESIGN.md file that describes the design motivations for the library, and it's definitely worth reading. It goes through a few really powerf

The repo includes a DESIGN.md file that describes the design motivations for the library, and it's definitely worth reading. It goes through a few really powerful techniques for writing misuse-resistant APIs, and I think some of its advice is applicable to good software engineering in general. https://github.com/google/mundane/blob/master/DESIGN.md https://github.com/google/mundane/blob/master/DESIGN.md In particular, their use of the type system to expose opaque types that only allow meaningful operations on them is something that I've seen used to great effect in other statically typed languages, like Haskell.

cyphar 8y ago
It is very interesting, though I do have a small gripe with how they characterise the "goto fail" bug. #[must_use] probably wouldn't have helped because the bug was that they effectively returned Ok() early. However, having an ergonomic error handling design in a systems language definitely helps. try! and ? are actually a massive improvement in the state of systems languages. Error handling is very important when designing a language.
blub 8y ago
One exception to the otherwise solid design principles: "If an error requires particularly subtle error-handling, prefer panicking or aborting the process. When cryptographic operations fail in a way that would require reporting an error to the user (in other words, there's no valid non-error interpretation like in the case of signature verification), and handling that failure is particularly error-prone, it may be justified to make the function's API infallible, and instead panic or abort the process on error. BoringSSL famously does this when failing to read randomness (e.g., from /dev/urandom), as this has historically been a source of vulnerabilities." It is almost never okay for a library to abort the process. The only exception I can think of is when discovering e.g. memory corruption or other UB, or when continuing would result in the above.
- lifthrasiir 8y ago
  > It is almost never okay for a library to abort the process. Using Joe Duffy's distinction [1], bugs aren't recoverable errors. Error handling admits the necessity of error recovery, but you generally don't have such a fine-grained policy for bugs. A dual-use of exceptions as a means to signal bug conditions is unfortunate, and I believe Mundane's policy is clearly following this distinction. Also, panicking in Rust can be caught in the same thread [2]. So it is actually much more flexible than process abort---if you need a general, umbrella protection against bugs, here you have a way. [1] http://joeduffyblog.com/2016/02/07/the-error-model/ http://joeduffyblog.com/2016/02/07/the-error-model/ [2] https://doc.rust-lang.org/stable/std/panic/fn.catch_unwind.html https://doc.rust-lang.org/stable/std/panic/fn.catch_unwind.h...
  - blub 8y ago
    That's a thought provoking article, and I see no problem with the proposed error management technique as a whole, for that particular project. This however is a crypto library designed to run on consumer OSs, as part of programs which will likely offer much more functionality that generating random numbers. In general, a bug is a software fault, which is a passive flaw in the program, introduced by a programmer. Faults can manifest and cause the program to behave in an uninteded way, which in turn can lead to failure - the program can no longer perform its function. Any point on the fault -> error -> failure chain can be an intervention point. The relevant point for this discussion is the detection of errors and preventing them from becoming system failures, and if not possible, handling those gracefully. Let's agree not to discuss recovery attempts and assume that the system is instead moved directly to a safe state when such a bug/error is detected. A crash-only safe state is simple and quite easy to implement, but whether it's the best approach for a particular software depends on the dependability requirements of that software. Abandoning the current operation and returning to the top level execution context is an alternative that shouldn't be so easily dismissed. In the BoringSSL case, there doesn't seem to be a reason to abort. The error condition is known, can be detected and failure can be returned just as easily. Panicking is also fine, if the parent program can react to it.
    - Asooka 8y ago
- PudgePacket 8y ago
  > It is almost never okay for a library to abort the process. For a library with a design principle to be as hard to misuse as possible it seems like the right decision, and the "exception to the rule". Infinitely better to crash than to potentially let the process/library run in some kind of degraded state. If you are aware of this behaviour and are savvy/experiences enough you'll either 1) Catch the panic and perform an appropriate library 2) Use a different library.
  - IshKebab 8y ago
    > Infinitely better to crash than to potentially let the process/library run in some kind of degraded state. Why? Just set the entire library to "failed" mode and have every function return an error or do nothing from that point forward. That is far more sensible than just panicking and bringing down the entire application. Imagine if people want to use this in a cash machine or something like that.
    - heavenlyblue 8y ago
      I would much rather the cash machine crashes than starts communicating with the bank seeded by 00*inf bytes of random. Besides, what exactly do you expect to do with the library in an "exceptional condition"? Do I now need to check the output of every single function for some non-local effects they have on each other?
      - blub 8y ago
        How can the library know that the cash machine will communicate with the bank, or that there even is a cash machine? The library should just tell the program that it failed go perform its task, not guess at what its parent program could, should or would do. Note that the discussion started from "abort". Maybe the authors meant something else by abort, but in a system programming context it means calling abort and terminating the program's execution immediately. If they just meant it as a synonym for panic, we're just having a nice discussion here.
  - blub 8y ago
- deleted 8y ago
  [deleted]
vkjv 8y ago
The `miscreant` library also does this: https://github.com/miscreant/miscreant https://github.com/miscreant/miscreant. It's really effective. For example, any method that requires a one time pad takes ownership. This allows the borrow checker to validate that you don't accidentally use an OTP more than once.

cyphar 8y ago

It is very interesting, though I do have a small gripe with how they characterise the "goto fail" bug. #[must_use] probably wouldn't have helped because the bug was that they effectively returned Ok() early. However, having an ergonomic error handling design in a systems language definitely helps. try! and ? are actually a massive improvement in the state of systems languages. Error handling is very important when designing a language.

blub 8y ago

One exception to the otherwise solid design principles: "If an error requires particularly subtle error-handling, prefer panicking or aborting the process. When cryptographic operations fail in a way that would require reporting an error to the user (in other words, there's no valid non-error interpretation like in the case of signature verification), and handling that failure is particularly error-prone, it may be justified to make the function's API infallible, and instead panic or abort the process on error. BoringSSL famously does this when failing to read randomness (e.g., from /dev/urandom), as this has historically been a source of vulnerabilities." It is almost never okay for a library to abort the process. The only exception I can think of is when discovering e.g. memory corruption or other UB, or when continuing would result in the above.

lifthrasiir 8y ago
> It is almost never okay for a library to abort the process. Using Joe Duffy's distinction [1], bugs aren't recoverable errors. Error handling admits the necessity of error recovery, but you generally don't have such a fine-grained policy for bugs. A dual-use of exceptions as a means to signal bug conditions is unfortunate, and I believe Mundane's policy is clearly following this distinction. Also, panicking in Rust can be caught in the same thread [2]. So it is actually much more flexible than process abort---if you need a general, umbrella protection against bugs, here you have a way. [1] http://joeduffyblog.com/2016/02/07/the-error-model/ http://joeduffyblog.com/2016/02/07/the-error-model/ [2] https://doc.rust-lang.org/stable/std/panic/fn.catch_unwind.html https://doc.rust-lang.org/stable/std/panic/fn.catch_unwind.h...
- blub 8y ago
  That's a thought provoking article, and I see no problem with the proposed error management technique as a whole, for that particular project. This however is a crypto library designed to run on consumer OSs, as part of programs which will likely offer much more functionality that generating random numbers. In general, a bug is a software fault, which is a passive flaw in the program, introduced by a programmer. Faults can manifest and cause the program to behave in an uninteded way, which in turn can lead to failure - the program can no longer perform its function. Any point on the fault -> error -> failure chain can be an intervention point. The relevant point for this discussion is the detection of errors and preventing them from becoming system failures, and if not possible, handling those gracefully. Let's agree not to discuss recovery attempts and assume that the system is instead moved directly to a safe state when such a bug/error is detected. A crash-only safe state is simple and quite easy to implement, but whether it's the best approach for a particular software depends on the dependability requirements of that software. Abandoning the current operation and returning to the top level execution context is an alternative that shouldn't be so easily dismissed. In the BoringSSL case, there doesn't seem to be a reason to abort. The error condition is known, can be detected and failure can be returned just as easily. Panicking is also fine, if the parent program can react to it.
  - Asooka 8y ago
PudgePacket 8y ago
> It is almost never okay for a library to abort the process. For a library with a design principle to be as hard to misuse as possible it seems like the right decision, and the "exception to the rule". Infinitely better to crash than to potentially let the process/library run in some kind of degraded state. If you are aware of this behaviour and are savvy/experiences enough you'll either 1) Catch the panic and perform an appropriate library 2) Use a different library.
- IshKebab 8y ago
  > Infinitely better to crash than to potentially let the process/library run in some kind of degraded state. Why? Just set the entire library to "failed" mode and have every function return an error or do nothing from that point forward. That is far more sensible than just panicking and bringing down the entire application. Imagine if people want to use this in a cash machine or something like that.
  - heavenlyblue 8y ago
    I would much rather the cash machine crashes than starts communicating with the bank seeded by 00*inf bytes of random. Besides, what exactly do you expect to do with the library in an "exceptional condition"? Do I now need to check the output of every single function for some non-local effects they have on each other?
    - blub 8y ago
      How can the library know that the cash machine will communicate with the bank, or that there even is a cash machine? The library should just tell the program that it failed go perform its task, not guess at what its parent program could, should or would do. Note that the discussion started from "abort". Maybe the authors meant something else by abort, but in a system programming context it means calling abort and terminating the program's execution immediately. If they just meant it as a synonym for panic, we're just having a nice discussion here.
- blub 8y ago
deleted 8y ago
[deleted]

vkjv 8y ago

The `miscreant` library also does this: https://github.com/miscreant/miscreant https://github.com/miscreant/miscreant. It's really effective. For example, any method that requires a one time pad takes ownership. This allows the borrow checker to validate that you don't accidentally use an OTP more than once.