3 ms·

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

by e12e 6y ago

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 :)

orra 6y ago
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-design-meeting.html https://blog.rust-lang.org/inside-rust/2020/02/27/ffi-unwind...
- e12e 6y ago
  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?
  - orra 6y ago
    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.
  - nicoburns 6y ago
    > 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.
- e12e 6y ago
  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.
  - Tobu 6y ago
    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#panic https://doc.rust-lang.org/cargo/reference/profiles.html#pani...
    - e12e 6y ago
      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?
      - Tobu 6y ago
        There's a categorization here (I don't have access to the triage spreadsheet though): https://github.com/ctz/rustls/issues/447#issuecomment-820719957 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.
dochtman 6y ago
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).

by e12e 6y ago

orra 6y ago

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-design-meeting.html https://blog.rust-lang.org/inside-rust/2020/02/27/ffi-unwind...

e12e 6y ago
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?
- orra 6y ago
  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.
- nicoburns 6y ago
  > 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.
e12e 6y ago
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.
- Tobu 6y ago
  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#panic https://doc.rust-lang.org/cargo/reference/profiles.html#pani...
  - e12e 6y ago
    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?
    - Tobu 6y ago
      There's a categorization here (I don't have access to the triage spreadsheet though): https://github.com/ctz/rustls/issues/447#issuecomment-820719957 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.

dochtman 6y ago

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).