Page MenuHomePhabricator

Add generating device ID rust code to our general native rust library
AbandonedPublic

Authored by inka on Oct 5 2022, 5:36 AM.
Tags
None
Referenced Files
Unknown Object (File)
Mon, Apr 29, 12:36 AM
Unknown Object (File)
Mon, Apr 29, 12:36 AM
Unknown Object (File)
Mon, Apr 29, 12:36 AM
Unknown Object (File)
Mon, Apr 29, 12:33 AM
Unknown Object (File)
Mon, Apr 29, 12:05 AM
Unknown Object (File)
Apr 13 2024, 6:59 AM
Unknown Object (File)
Apr 1 2024, 12:27 PM
Unknown Object (File)
Mar 28 2024, 9:17 AM

Details

Reviewers
marcin
varun
tomek
Summary

The code from D4754 had to be moved to our general rust library. As suggested in comments on D4754, the enum has been renamed to DeviceType.

Test Plan

In native/cpp/CommoonCpp/NativeModules/CommCoreModule.cpp add #include "../../../native_rust_library/lib.rs.h" and in the same file in function getAllMessages add printf("%s\n", generate_device_id(DeviceType::KEYSERVER).c_str()); and see that after launching ios from XCode a string subjet to "^(ks|mobile|web):[a-zA-Z0-9]{64}$" is logged to the XCode console. I tested this launching
a phisical device as for some reason I cannot launch the simulator from XCode.

Diff Detail

Repository
rCOMM Comm
Lint
No Lint Coverage
Unit
No Test Coverage

Event Timeline

inka requested review of this revision.Oct 5 2022, 5:46 AM
native/native_rust_library/src/crypto_tools.rs
17 ↗(On Diff #17354)

I couldn't find a nice way of using DEVICE_ID_CHAR_LENGTH for defining this regex (I mean sth like "^(ks|mobile|web):[a-zA-Z0-9]{${DEVICE_ID_CHAR_LENGTH}}$"). The best way I found is using const_format create, but I'm not sure we want do introduce another dependency for something like this...

native/native_rust_library/src/lib.rs
14 ↗(On Diff #17354)

Is using pub use here necessary? For the purpose of generating C++ bindings for this rust function use is enough.

37 ↗(On Diff #17354)

Declaration outside of extern "Rust" scope is essential here since C++ would not be able to understand this type. Context is here: https://cxx.rs/shared.html. I am leaving this comment in case future reviewers get confused here.

80 ↗(On Diff #17354)

I am not requesting it but in my opinion it would be nice to use some source of separation here like a comment line: //crypto_tools or something. Unfortunately we cannot create separate module for each function set we want to generate C++ bindings for, so we could at least provide "logical" separation with comments.

marcin requested changes to this revision.Oct 5 2022, 6:19 AM
This revision now requires changes to proceed.Oct 5 2022, 6:19 AM

Address Marcin's review, section naming based on D5057

marcin added a reviewer: tomek.
marcin added inline comments.
native/native_rust_library/src/crypto_tools.rs
17 ↗(On Diff #17357)

If we can separate stuff related to tests from application code then I think we should do so.

native/native_rust_library/src/crypto_tools.rs
17 ↗(On Diff #17357)

Originally this was in mod tests, but because of the need to keep this in sync with other files (as explained in the comment above the constant) I've put these constants that relate to some application logic next to each other, like in the other files. In rust code this is just related to tests, but in other places this regex is actually used. Eg. in services/tunnelbroker/src/Tools/Tools.cpp DEVICEID_FORMAT_REGEX from services/tunnelbroker/src/Constants.h is used validate device id passed to tunnelbroker.
I'm open to changing this if you still think it's best, just wanted to explain why I moved it.

tomek requested changes to this revision.Oct 10 2022, 2:45 AM

The code from D4754 had to be moved to our general rust library. As suggested in comments on D4754, the enum has been renamed to DeviceType.

Does that mean that the plan is to abandon that diff and land only this one? I don't think this is a good idea. Usually, we should update the diff so that the discussion is preserved. Also, moving already accepted code makes it necessary to review it again - it's hard to tell which parts are new and which are moved.

This revision now requires changes to proceed.Oct 10 2022, 2:45 AM

As @tomek pointed out, this diff should have been done as an amend to D4754, so I moved these changes and relevant comments there, and will abort this diff. Sorry about this.