Project Description

Crev [1] is a collaborative code audit idea. Since it's common that more security engineers can work on the same projects, or there can be a different person auditing a piece of code after some time, there is the need to keep track of the code audit notes in a non-repudiable way.

This can be of interest to our internal security team, for the audits we did on the distribution code packages.

Goal for this Hackweek

  • Understand the as-is: complete
  • Create / expand workflow proposal: uncomplete
  • Implement some support tooling to create proofs uncomplete
  • Create some small PoC code in BASH: partially complete

Hackweek 21 outcomes

During this hackweek I tried to understand the framework by putting some basic concepts into code[2] and I wrote dome final considerations [3].

TL;DR there's a lot of work that must to be done in improving formal framework specification. I feel the need to help redesign the grammar of the specifications and the filetype and add some more examples. Implementation has to be agnostic from the documentation, so this means it must be decoupled from the doc itself

Resources

  1. https://github.com/crev-dev/crev
  2. My repo on Github
  3. Considerations

Looking for hackers with the skills:

codereview codeaudit security workflow rust

This project is part of:

Hack Week 21

Activity

  • over 3 years ago: jzerebecki liked this project.
  • over 3 years ago: jzerebecki added keyword "rust" to this project.
  • over 3 years ago: jzerebecki joined this project.
  • over 3 years ago: wfrisch liked this project.
  • over 3 years ago: fbonazzi liked this project.
  • over 3 years ago: fbonazzi started this project.
  • over 3 years ago: pperego added keyword "codereview" to this project.
  • over 3 years ago: pperego added keyword "codeaudit" to this project.
  • over 3 years ago: pperego added keyword "security" to this project.
  • over 3 years ago: pperego added keyword "workflow" to this project.
  • over 3 years ago: pperego originated this project.

  • Comments

    • jzerebecki
      over 3 years ago by jzerebecki | Reply

      See also https://hackweek.opensuse.org/21/projects/rust-security-reviews-and-cargo-crev

    • jzerebecki
      over 3 years ago by jzerebecki | Reply

      Updated packages available at https://build.opensuse.org/package/show/devel:tools/cargo-crev

    Similar Projects

    Modal editor in Rust by acervesato

    Description

    To write a modal editor in Rust inspired by vim and having the following features:

    • vim basic motion commands + insert/visual mode
    • multiple buffers with tabs
    • status bar

    It should be written for terminal only using ratatui library and crossterm.

    Goals

    The goal is to start with a functional prototype that can be extended in the future with the following features (in random order):

    • treesitter support + styles
    • fuzzy finder
    • grep finder
    • integration with git
    • tree viewer
    • internal terminal floating window
    • mailing list workflow integration

    Resources


    RMT.rs: High-Performance Registration Path for RMT using Rust by gbasso

    Description

    The SUSE Repository Mirroring Tool (RMT) is a critical component for managing software updates and subscriptions, especially for our Public Cloud Team (PCT). In a cloud environment, hundreds or even thousands of new SUSE instances (VPS/EC2) can be provisioned simultaneously. Each new instance attempts to register against an RMT server, creating a "thundering herd" scenario.

    We have observed that the current RMT server, written in Ruby, faces performance issues under this high-concurrency registration load. This can lead to request overhead, slow registration times, and outright registration failures, delaying the readiness of new cloud instances.

    This Hackweek project aims to explore a solution by re-implementing the performance-critical registration path in Rust. The goal is to leverage Rust's high performance, memory safety, and first-class concurrency handling to create an alternative registration endpoint that is fast, reliable, and can gracefully manage massive, simultaneous request spikes.

    The new Rust module will be integrated into the existing RMT Ruby application, allowing us to directly compare the performance of both implementations.

    Goals

    The primary objective is to build and benchmark a high-performance Rust-based alternative for the RMT server registration endpoint.

    Key goals for the week:

    1. Analyze & Identify: Dive into the SUSE/rmt Ruby codebase to identify and map out the exact critical path for server registration (e.g., controllers, services, database interactions).
    2. Develop in Rust: Implement a functionally equivalent version of this registration logic in Rust.
    3. Integrate: Explore and implement a method for Ruby/Rust integration to "hot-wire" the new Rust module into the RMT application. This may involve using FFI, or libraries like rb-sys or magnus.
    4. Benchmark: Create a benchmarking script (e.g., using k6, ab, or a custom tool) that simulates the high-concurrency registration load from thousands of clients.
    5. Compare & Present: Conduct a comparative performance analysis (requests per second, latency, success/error rates, CPU/memory usage) between the original Ruby path and the new Rust path. The deliverable will be this data and a summary of the findings.

    Resources

    • RMT Source Code (Ruby):
      • https://github.com/SUSE/rmt
    • RMT Documentation:
      • https://documentation.suse.com/sles/15-SP7/html/SLES-all/book-rmt.html
    • Tooling & Stacks:
      • RMT/Ruby development environment (for running the base RMT)
      • Rust development environment (rustup, cargo)
    • Potential Integration Libraries:
      • rb-sys: https://github.com/oxidize-rb/rb-sys
      • Magnus: https://github.com/matsadler/magnus
    • Benchmarking Tools:
      • k6 (https://k6.io/)
      • ab (ApacheBench)