Hacker News Reader

Comment by e12e | Hacker News Reader

This looks great. As I understand it, the major reason openssl is still in use (at all, really) -is a very unhealthy dependency on it's demented and complex Api... Has anything changed that makes it easier to switch from broken ssl lib to a new "perfect" one?

Are we likely to see stdlib changes in python, ruby etc?

The site mentions:

> Enforce a no-panic policy to eliminate the potential for undefined behavior when Rustls is used across the C language boundary.

Is this a thing? Does panic open up for undefined behavior when using a rust library via C?

I can't recall seeing it mentioned before/in other rust threads/projects?

I whish you the best of luck- libopenssl is terrifying :)

View on HN

Panicking (unwinding) across an FFI boundary is very much undefined behaviour. You'd get analogous cross language issues with C++ exceptions. Or mixing GCC ABI unwinding with MSVC ABI unwinding.

Nonetheless, there is a working group, proposing to make it defined under certain circumstances. https://blog.rust-lang.org/inside-rust/2020/02/27/ffi-unwind...

But is this undefined behavior in the typical c sense (lol, I see you call function possibly_undefined() I'll just make you a sandwich and clobber all registers instead) - or undefined behavior in the sense that it should crash - but might return?

I’m not sure I'd draw a distinction. People used to say you should initialise your variables in C89 to NULL, so you'd get a crash if you forget to properly set the variable. But enough security bugs have been caused by null pointer dereferences.

In the Rust case, IIRC, Rust annotates functions with the LLVM attribute no_unwind. I'd expect bad things, thanks to optimisation passes, if an unwind were to start. Doubly so if mixing GCC with MSVC ABI.

> is this undefined behavior in the typical c sense (lol, I see you call function possibly_undefined() I'll just make you a sandwich and clobber all registers instead)

Yes.

Thank you for that link, I thought (production build) rust panic was simply a core dump. I didn't realize there was stack unwinding going on.

There are two options at the moment [1]:

  - panic=abort (uncatchable)
  - panic=unwind.

With the latter, you would need a catch_unwind at the FFI boundary.

[1] https://doc.rust-lang.org/cargo/reference/profiles.html#pani...

I see. I would think that for a library, in production, all you'd want for panic was a crash. (I guess this is the abort case).

AAre the panics being discussed for removal in rust tls "soft" errors that should not crash?

There's a categorization here (I don't have access to the triage spreadsheet though):

https://github.com/ctz/rustls/issues/447#issuecomment-820719...

It seems like there's been the most effort on category 4, the ones that can't be reached but can often be proven away with refactoring and typestate. Removing these ensures that the APIs don't expose Result types to callers unnecessarily.

Category 1-3 have different severity, but they are all planned to be folded into Result error values.

On the Python angle, I recently spent some time building Python bindings for another Rust project with PyO3 and was quite happy with the result. Since then, I’ve been toying with the idea about building a somewhat compatible replacement for Python’s ssl module based on rustls. I’d be happy to work on that, but I’d need to find some way to fund it (Patreon or GitHub Sponsors might work, but so far I haven’t had a lot of luck gaining sponsors there).

Reply on news.ycombinator.com