Write cargo-crev reviews in a Graphical User Interface with a cross-platform app written in rust
repository; version: 2021.925.1120 date: 2021-09-25 authors: Luciano Bestia
This is a GUI wrapper around cargo and cargo-crev. First, install and configure cargo and cargo-crev. Then:
bash
cargo install cargo_crev_reviews
cd ~/rustprojects/your-project-name
cargo_crev_reviews
Input your passphrase for cargo-crev proof signing.
I think cargo-crev is a great tool to express trustworthiness in the open-source community, especially for the rust programming language. I fear so much of supply chain attacks using dependencies from crates.io. For the smallest project you can get 100 dependencies easily. How to trust them all? To review them all manually? It is just crazy.
But if enough people write reviews, it will be so much easier to trust the code. It is the same principle as booking.com or air-bnb. Guests of a hotel write a review about their actual experience in the hotel. And you can read a hopefully truthful review and can understand if the hotel is good or bad. Sometimes can happen to find a fake review, but if there is enough people, most of them will be sincere.
Sadly, writing reviews in cargo-crev is hard. Let's make a GUI wrapper around cargo-crev to make write reviews easier.
We will see walking the path what obstacles we must overcome.
Rust does not have a true GUI story. It is mostly for CLI and libraries. Because GUI is mostly non cross-platform. But rust is the best language for Wasm/Webassembly. So let's combine this.
I will make a rust workspace (multi-projects):
The web server CLI will access files, commands, libraries and the network. This will work only in Linux, but today Win10 has integrated Linux with WSL2. It will work just fine on all the operating systems sensible for rust development.
Wasm in browser will just access the local micro web server. This is gonna be the GUI and because the browser works in every OS, this is cross-platform development.
I want the simplest web server ever. It will be used exclusively locally from one super simple web-application, so don't need to care much about security. I choose simple server from the rust book. I don't care about multi-threading or async , because it will be used by only one browser. The example from the book evolved into the github repository of the author of the book github.com/steveklabnik. I cloned it and update the dependencies and consequently fixed some broken code. I published it as devbestiasimple_server on crates.io.
For the browser I will create a simple web app. All the code will be in rust, I will avoid javascript. The GUI will be in HTML5 and CSS3. This is all supported by all modern browsers.
I will use cargo-auto to automate the tasks needed to build the project.
The sub-directory automation_tasks_rs is the rust project for cargo-auto.
The rust workspace is made of members:
The sub-directory web_server_folder contains all the files and folder structure for a working development web_server.
But this files are not used directly. Because of the way the publish to crates.io works, I will embed them inside the rust code as strings (base64 encoded if needed). I will make an automation task for that.
There is a file auto_generated_mod.rs where automation tasks writes boilerplate code.
This is a micro-web-server intended for local use with only one local browser connected to it.
It is the backend of the application cargo_crev_reviews. I had to use the same name here.
Together the backend and the frontend form a complete application that is cross-platform.
They share some structs for communication that are defined in the common_structs_mod module. One automation task copies the content from backend to frontend projects to keep them in sync.
The only URL the server operates is: http://127.0.0.1:8182/cargo_crev_reviews
If I want to publish this on crates.io it must all be inside one binary executable file.
It means that all the static files: css, html, icons, images, ... must be inside the rust code.
For developing it is practical to have all this files as files.
But before release an automation task converts this files to strings and put them into the rust code.
The micro-server will accept mostly POST with json similar to json-rpc. But sure I had to modify it to something more adequate for my use-case. I think in the future I will change that even more to something even more adequate.
```bash Syntax:
--> data sent to Server - request <-- data sent to Client - response
rpc call with named parameters:
--> { "requestmethod": "subtractcalculate", "request_data": { "subtrahend": 23, "minuend": 42, } }
<-- {
"responsemethod": "subtractshow",
"responsedata": {
"subtracted": 19,
},
"responsehtml":"..."
}
```
An example how to test a POST request with curl:
bash
curl -d '{"request_method": "subtract", "request_data": {"subtrahend": 23, "minuend": 42}}' -H 'Content-Type: application/json' http://127.0.0.1:8182/cargo_crev_reviews
There are also a small number of GET requests for static files mostly to start the communication between the browser and the server.
This simple web app is the GUI frontend of the application cargo_crev_reviews.
It is strictly designed for use on desktops as it is a tool for programers. No need to do a mobile version. The response from the rpc server contains:
The method name is used to match and call the appropriate function.
The html template must be microXml compatible. The wasm code reads element by element and when finds a marker, inserts the data. I wanted the html template to be complete with some sample texts. So the markers are added in front of the element or attribute they are meant to replace.
Common structures between backend and frontend. It is kind of a contract for communication.
All in 100% rust language. One automation task keeps in sync the backend and frontend module.
TODO: Using structs is not generic enough. Most of the time I need then name of a field. Because with the name I can bind in different scenarios. Using structs I don't have the name of the field at runtime. I think I will ditch most of the structs to have just a plain old flat text with QVS21. Inside that text every field will have a slice and a name. And I can then use that in runtime for bindings.
The cargo-crev project contains many crates. The crates crev-lib and crev-data are libraries for integration. All the code working with crev is encapsulated in the crev_mod.rs module.
The cargo application is essential for work with the rust language. It maintains a local cargo registry cache. The registry index is git fetched from github. Path to an index file:
~\.cargo\registry\index\github.com-1ecc6299db9ec823\cache\re\ad\reader_for_microxml
The content of this file is roughly:
yaml
bc688d353fc7c7a2f3f1f5fed9a27fc1773fc710
1.0.0 {
"name": "reader_for_microxml",
"vers": "1.0.0",
"deps": [],
"cksum": "623616f68a6441e2f61aa01c9bbcf76f4c9989328e0e10ab747e936718791912",
"features": {},
"yanked": true,
"links": null
}
1.1.11 {
"name": "reader_for_microxml",
"vers": "1.1.11",
"deps": [],
"cksum": "fd50abb1f0d11a59ebe6d3f31446e4af8d0f8a7df668034b6c9b94453fa30c42",
"features": {},
"yanked": true,
"links": null
}
Cargo also downloads from crates.io the complete source code for every dependency in the path ~/.cargo/registry/src/github.com-1ecc6299db9ec823/. Crates.io guarantees the source code for a crate+version cannot be altered or deleted. We know it will never change, so we can review exactly this local code with confidence.
Some data are not available locally and need to be obtained from https://crates.io//api/v1/crates/{}/{}/. Then I store them in ~/.config/crev/cargo_crev_reviews_versions.json
There is a confusion on crates.io who is the owner, author or group that is responsible for a crate version. Lately they added a published_by field for a crate_version. That sounds more accurate. In the file ~/.config/crev/cargo_crev_reviews_trusted_publishers.json is the list of your trusted publishers. You can edit this file manually.
We live in times of danger with supply chain attacks.
It is recommended to always use cargo-crev
to verify the trustworthiness of each of your dependencies.
Please, spread this info.
You can also read reviews quickly on the web:
https://web.crev.dev/rust-reviews/crates/
My open-source projects are free and free as a beer (MIT license).
I just love programming.
But I need also to drink. If you find my projects and tutorials helpful,
please buy me a beer donating on my paypal.
You know the price of a beer in your local bar ;-)
So I can drink a free beer for your health :-)
Na zdravje! Alla salute! Prost! Nazdravlje! 🍻