Cuprate/cuprate
Cuprate/cuprate
1
0
Fork 0
mirror of https://github.com/Cuprate/cuprate.git synced 2024-12-22 19:49:28 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions

update readme

Browse source 
remove boog900's credit
This commit is contained in:
Someone Else 2023-03-18 18:35:41 +00:00 committed by Boog900
parent 8a5e7f543e
commit 5ba92e7643
No known key found for this signature in database
GPG key ID: 5401367FB7302004
1 changed files with 48 additions and 16 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

64
readme.md
View file

@ -24,27 +24,45 @@ Releasing an alternative node will reinforce the Monero Network if a security vu
### Status
Status of current parts being work on can be found in the pull request section.
Status of current parts being work on can be found in the [pull request section](https://github.com/SyntheticBird45/cuprate/pulls).
@boog900 have delivered the net code and is working on ringCT.
@boog900 have delivered the net code and is working on ringCT & P2P.
@SyntheticBird45 is working on the database part.
### Contributions
## Contributions
Any help on rewriting other parts of the node while also aligning with the targeted improvements is appreciated.
Any help is appreciated. If you want to help but don't know where to start, you can take a look at the [issues section](https://github.com/SyntheticBird45/cuprate/issues)
I encourage anyone to review the work being done, discuss about it or propose agressive optimizations (at architectural level if needed, or even micro-optimizations in 'monolithic components').
We encourage anyone to review the work being done, discuss about it or propose agressive optimizations (at architectural level if needed, or even micro-optimizations in 'monolithic components').
For non-developers people, it is time for you to unleash your ideas.
For non-developers people, you can also propose ideas in the [discussion section](https://github.com/SyntheticBird45/cuprate/discussions). The sooner we hear about your ideas, the better the chance are we implement them into Cuprate.
### Code, Repository & Dependencies
## Code & Repository
No unsafe code is permitted in the project, and the codebase will never contain `.expect()` or `panic!()`. We discourage the use
of `.unwrap()`, as it implied that all errors are correctly handled.
of `.unwrap()`, as it implied that all patterns are correctly handled. This way the node will never suddenly crash.
The organization of the repository is at the moment arbritrary. The blockchain database components can be found under the blockchain_db member.
The repository is a cargo workspace. You will find every corresponding codebase in their crates folders. These crates are librairies and the main crates used to compile the node can be found in src/
### Security measures
<details><summary>Exploit Mitigations</summary></br>
As specified in the cargo.toml, cuprate releases are compiled with several rustflags & cargoflags to improve binary security:
</br><details><summary>Debug informations are cleared & symbols are stripped.</summary></br>
Even if the source code is available, sometimes you can find bugs in a program by looking at the metadata left by the compiler at assembly level. Stipping these metadata help mitigating some vulnerability analysis. Of course someone could recompile it without these flags. The same way some people could tunes some compilation flags if they decide to compile it by themselves. But it is likely to change call hierarchy and other data that could ruin a potential vulnerability. </details>
<details><summary>In case of panic, the node immediately abort.</summary></br>
This isn't to be annoying. This is security measure. Most of the times, exploits are designed to use vulnerabilities that don't crash the targeted process but is definitely modifying it's behavior. In such case, where a function doesn't end properly, the sanest way to deal with it, is to stop all the threads immediately. If you don't, you risk to trigger a vulnerability or execute potential malware code.</details>
<details><summary>Forward-Edge <a href="https://en.wikipedia.org/wiki/Control-flow_integrity">Control-Flow Integrity</a></summary></br>
This is an exploit mitigation that can be enable in GCC & LLVM to fight against <a href="https://en.wikipedia.org/wiki/Return-oriented_programming">Return-oriented programming</a>. This isn't enabled by default in Rust, because to make a rop chain you need first to corrupt a pointer (which is *normally* impossible), but since we focus on security it's worth enabling it. CFI is basically a combination of added code to verify if the program is respecting it's functions call hierarchy or if its calling part of the binary it shouldn't do.</details>
<details><summary>Compiling as a <a href="https://en.wikipedia.org/wiki/Position-independent_code">Position Indepent Executable</a></summary></br>
This is a type of executable that permit its machine code to be executed regardless of it's address layout by dynamically playing with its global offset table. This way, functions called each others based on offset instead of absolute address. It permit better security because at each execution the address being used in the execution stack change. This is great to make a potential exploit unreliable on targeted machines.</details>
<details><summary>Using stack-protector=all</summary></br> Stack protector are a set of strategy used by LLVM & GCC to detect buffer overflow & general memory corruption. By setting it as all, we tell LLVM to enable this strategy to all functions. Making it as difficult as possible to corrupt memory without being detected (=abort).
</details>
</details>
### Dependencies
<details>
<summary>Dependencies</summary>
@ -54,24 +72,38 @@ The organization of the repository is at the moment arbritrary. The blockchain d
| monero-rs | Used to define monero's type and serialize/deserialize data.
| serde | serialize/deserialize support.
| thiserror | used to Derive(Error) in the codebase.
| libmdbx | safe wrapper for mdbx implementation.
</details>
### Improvements & Features
### License
<details> <summary>Traffic Obfuscation</summary> </br> Different protocol to bypass DPI will be available, such as with <a href="https://github.com/vtnerd/monero/blob/docs_p2p_e2e/docs/LEVIN_PROTOCOL.md#encryption">Levin protocol</a> (TLS based, see https://github.com/monero-project/monero/issues/7078) and QUIC <a href="https://github.com/syncthing/syncthing/pull/5737">like Syncthing have done</a>, but with offset and timing mitigations. Unless the monero-core team decide to implement these protocols, they'll only by available between cuprate peers.</details>
Cuprate is licensed under MIT-AGPL. the corresponding license to each crates can be found in their respective folders.
<details> <summary>Blockchain Storage</summary> </br>LMDB is replaced by RocksDB, a high-performance database designed for SSD, already used by the Parity ethereum's rust client. HSE is also going to be implemented, as a more dsitributed and scalable alternative. </details>
## Improvements & Features
<details> <summary>Sandboxing & System</summary> </br> There will be maintained SELinux/Apparmor policy for this node. It will internally use seccomp/Landlock to limit syscalls being used in order to improve isolation of the node with rest of the OS & Wallet Software.</details>
<details> <summary>Traffic Obfuscation</summary> </br> Different protocol to bypass DPI will be available, such as with a proposal for <a href="https://github.com/vtnerd/monero/blob/docs_p2p_e2e/docs/LEVIN_PROTOCOL.md#encryption">Levin protocol</a> (TLS based, see https://github.com/monero-project/monero/issues/7078) and QUIC <a href="https://github.com/syncthing/syncthing/pull/5737">like Syncthing have done</a>, but with offset and timing mitigations. Unless the monero-core team decide to implement these protocols, they'll only by available between cuprate peers.</details>
<details> <summary>RPC</summary> </br> ZeroMQ as well as gRPC will be available to communicate with the node.</details>
<details> <summary>Blockchain Storage</summary> </br>LMDB is replaced by MDBX, a spiritual successor of LMDB with insane performance, already used by the reth Ethereum's rust client. HSE (Heterogeneous Storage Engine for Micron, optimized for SSD & random writes & reads) is also going to be implemented, as a more dsitributed and scalable alternative. </details>
<details> <summary>Sandboxing & System</summary> </br>
- For Linux : There will be maintained SELinux/Apparmor policy for this node for major linux distributions. It will internally use seccomp to limit syscalls being used. Landlock is also going to be setup in order to improve isolation of the node with rest of the OS.
</br>- For Windows : It still need some research but we could use capability primitives & WinAPI to limit access to certain system functions.
</br>- For macOS : There is unfortunately no library to setup some isolation, as Apple seems to have deprecated Seatbelt.
</details>
<details> <summary>RPC</summary> </br> ZeroMQ as well as gRPC will be available to communicate with the node. Powered by tonic library from Tokio</details>
<details> <summary>Terminal Interface</summary> </br> More accessible interface based on the excellent [tui](https://lib.rs/crates/tui) library. There will be Geolocation of peers on map, VPN Detection, Ressource usages, statistics etc... </details>
<details> <summary>Tor connections</summary> </br> arti_client library will be embedded to make possible connections to tor peers without a system daemon or proxy (for the moment arti_client can't handle onion services, but it'll certainly in the near future).</details>
<details> <summary>Tor connections</summary> </br> arti_client library will be embedded to make possible connections to tor peers without a system daemon or proxy (for the moment arti_client can't handle onion services, but it'll certainly in the near future). i2p support is not planned at the moment</details>
### Regressions
- No integrated miner planned
- LMDB support removed (unless someone else want to work on it, or I've time). Which means that the blockchain synced by monerod is incompatible with cuprate
- LMDB support removed. Which means that the blockchain synced by monerod is incompatible with cuprate.
- [Some](https://github.com/monero-project/monero/blob/c5d10a4ac43941fe7f234d487f6dd54996a9aa33/src/wallet/wallet2.cpp#L3930) [funny](https://github.com/monero-project/monero/blob/c5d10a4ac43941fe7f234d487f6dd54996a9aa33/src/common/dns_utils.cpp#L134) [messages](https://github.com/monero-project/monero/blob/c5d10a4ac43941fe7f234d487f6dd54996a9aa33/src/common/util.cpp#L602) in the original codebase will be lost.
## PGP keys
If you wish to contact contributors privately, you can import our gpg keys from the pgp_keys folder.