#24659: Wrap our sha2 interface in Rust which implements the appropriate traits
-----------------------------------------------+---------------------------
 Reporter:  isis                               |          Owner:  isis
     Type:  enhancement                        |         Status:
                                               |  needs_review
 Priority:  Medium                             |      Milestone:  Tor:
                                               |  0.3.4.x-final
Component:  Core Tor/Tor                       |        Version:
 Severity:  Normal                             |     Resolution:
 Keywords:  rust, tor-crypto, review-group-34  |  Actual Points:
Parent ID:                                     |         Points:  1
 Reviewer:  catalyst                           |        Sponsor:
                                               |  Sponsor3-can
-----------------------------------------------+---------------------------

Comment (by isis):

 I've thought about this a bit more, and—since our C code that I'm wrapping
 is currently tested for correctness in C—I think that an easy workaround
 for this, would be temporarily (assuming we're eventually only going to
 require implementations in C ''or'' Rust, not both) doing what Chelsea
 Komlo's Rust tor logging code is doing: the wrapping implementation in
 release mode, and a dummy implementation in testing mode.  For this, that
 would probably amount to a dev-dependency (Rust distinguishes between hard
 dependencies, optional dependencies, and "dev" or testing dependencies in
 Cargo.toml files) on [https://crates.io/crates/sha2 the sha2 crate].  This
 way, Rust code that is higher level (eventually) will actually be able to
 test correctness of results of functions which rely on the output of a
 hash function. (Probably we'll want to do the same for the
 [https://crates.io/crates/rand rand crate] when we wrap that. Except for
 the `rand` crate, it's a bit messed up, because we'll extremely want the
 `rand::Rng` trait in release/production in order to use generic code
 throughout the Rust ecosystem. Possibly we should nicely ask its
 maintainers to split the trait off into a separate crate, or otherwise
 rely on the fact that the crate is scheduled to be absorbed into
 libstd/libcore in Rust and just use it entirely, including calling it from
 C.)

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/24659#comment:13>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Reply via email to