The sudo-rs project improves on the security of the original sudo by:

• Using a memory safe language (Rust), as it's estimated that one out of three security bugs in the original sudo have been memory management issues

• Leaving out less commonly used features so as to reduce attack surface

• Developing an extensive test suite which even managed to find bugs in the original sudo

Beginning the Project with Learning Goals

In the summer of 2018, I started a project called Joshuto to learn Rust. At first, I considered learning C++, but became interested in Rust and decided to build something in it instead. While the main goal was for me to learn Rust, over the past four years it has grown into a much larger open source project with many contributors. I wanted to share some of my experiences and lessons learned along the way.

What Joshuto Is and Early Development

I describe Joshuto as a ranger-like terminal file manager written in Rust. For those unfamiliar, ranger is another terminal file manager that makes navigating files and folders in the terminal extremely fast and efficient. The interface usually consists of three columns - the parent directory, the current directory, and a preview of the next directory or file. You can navigate with arrow keys or vim keys, select/cut/copy/paste files, create new tabs and directories, rename files, and more - like a normal GUI file manager. Joshuto also supports bulk file renaming across multiple selected files.

My goal was to learn Rust by challenging myself to build a replacement for ranger that matched all my use cases. I decided to use the ncurses library in Rust since I had experience with ncurses-based terminal programs in the past. I quickly built out a UI to display the current and parent directories, added logic to handle different key presses, custom remappings and themes, and background threads for cut/copy jobs. Under the hood, I used a HashMap to store directory contents instead of a tree structure, which was harder to implement efficiently in Rust.

Reflecting on Design Choices and Major Refactors

Of course, nobody writes perfect code on the first try. Over the years I've had to do some major refactors due to early design decisions that didn't age well.

One of the biggest was switching from ncurses to tui-rs. Ncurses is very primitive without high level abstractions, making reusable code difficult. I could never get things like windows or panels working well, and ncurses can have inconsistent wide character support leading to compile issues for some users. It also caused a lot of screen flickering from refreshing the entire screen. Moving to tui-rs improved the codebase drastically and adoption rate, at the cost of deleting a lot of existing code. This migration took about a week in February 2020 after putting it off for 2 years.

Another refactor was removing the fs-extra library I used for cutting/copying files. Although elegant, it wasn't efficient - doing unnecessary copies and deletions instead of renames. I wrote a custom implementation to directly rename when possible. There were challenges around handling permissions and edge cases, but it improved performance substantially.

Lessons Learned

Some key lessons I learned:

• Be pragmatic in your technology choices - don't force a library or design that isn't working well. The cost of refactoring later is worth avoiding longer term issues.

• Write in idiomatic Rust - avoid fighting the language and leverage its strength like enums for event handling.

• Performance matters more than it may seem at first. Do profiling and optimize bottlenecks.

• Listen to your users and their pain points to guide development. Their diverse environments and use cases will reveal flaws in your thinking.

• Open source is extremely rewarding. Seeing others use and contribute to your project is an amazing feeling.

This has been an incredible learning experience. While a ton of work, I'm proud of the project Joshuto has become and still very motivated to keep improving it. I encourage anyone interested in Rust or open source to give it a try!

Abstract—New contributors are critical to open source projects. Without them, the project will eventually atrophy and become inactive, or its experienced contributors will bias the future directions the project takes. However, new contributors can also bring a greater risk of introducing vulnerable code. For projects that have a need for both secure implementations and a strong, diverse contributor community, this conflict is a pressing issue. One avenue being pursued that could facilitate this goal is rewriting components of C or C++ code in Rust— a language designed to apply to the same domains as C and C++, but with greater safety guarantees. Seeking to answer whether Rust can help keep new contributors from introducing vulnerabilities, and therefore ease the burden on maintainers, we examine the Oxidation project from Mozilla, which has replaced components of the Firefox web browser with equivalents written in Rust. We use the available data from these projects to derive parameters for a novel application of learning curves, which we use to estimate the proportion of commits that introduce vulnerabilities from new contributors in a manner that is directly comparable. We find that despite concerns about ease of use, first-time contributors to Rust projects are about 70 times less likely to introduce vulnerabilities than first-time contributors to C++ projects. We also found that the rate of new contributors increased overall after switching to Rust, implying that this decrease in vulnerabilities from new contributors does not result from a smaller pool of more skilled developers, and that Rust can in fact facilitate new contributors. In the process, we also qualitatively analyze the Rust vulnerabilities in these projects, and measure the efficacy of the common SZZ algorithm for identifying bug-inducing commits from their fixes.

Oxide is a personal project that takes inspiration from the principles discussed in "Notes on a Smaller Rust" and its follow-up, "Revisiting a 'smaller Rust'". It aims to explore a new language design that simplifies and optimizes the development process while inheriting Rust's best qualities.

Quite some exciting progress since the last progress report! There have been 180 commits since the last progress report.

As of today, rustc_codegen_cranelift is available on nightly! :tada: You can run rustup component add rustc-codegen-cranelift-preview --toolchain nightly to install it and then either CARGO_PROFILE_DEV_CODEGEN_BACKEND=cranelift cargo +nightly build to use it for the current invocation or add

Secure by default

It tries to be as secure as possible by default while still providing all the options needed to be compatible with older systems. For instance, if you create a new OIDC client, it activates ed25519 as the default algorithm for token signing and S256 PKCE flow. This will not work with old clients, which do not support it, but you can of course deactivate this to your liking.

MFA and Passwordless Login

Rauthy provides FIDO 2 / Webauthn login flows. If you once logged in on a new client with your username + password, you will get an encrypted cookie which will allow you to log in without a password from that moment on. You only need to have a FIDO compliant Passkey being registered for your account.

Fast and efficient

The main goal was to provide an SSO solution like Keycloak and others while using a way lower footprint and being more efficient with resources. For instance, Rauthy can easily run a fully blown SSO provider on just a Raspberry Pi. It makes extensive use of caching to be as fast as possible in cases where your database is further away or just a bit slower, because it is maybe running on an SBC from an SD card. Most things are even cached for several hours (config options will come in the future) and special care has been taken into account in case of cache eviction and invalidation.

Highly Available

Even though it makes extensive use of caching, you can run it in HA mode. It uses its own embedded distributed HA cache called redhac, which cares about cache eviction on remote hosts. You can choose between a SQLite for single instance deployments and a Postgres, if you need HA. MySQL support might come in the future.

Client Branding

You have a simple way to create some kind of branding or stylized look for the Login page for each client. The whole color theme can be changed and each client can have its own custom logo. Additionally, if you modify the branding for the default rauthyclient, it will not only change the look for the Login page, but also for the Account and Admin page.

Already in production

Rauthy is already being used in production, and it works with all typical OIDC clients (so far). It was just not an open source project for quite some time. Keycloak was a rough inspiration in certain places and if something is working with Keycloak, it does with rauthy too (again, so far).

To me, the two major problems are:

1. no namespaces

Someone uploads "serde2"? that's blocked forever. Someone uploads a typo version of a popular package? Too bad for you, learn how to type.

2. the github connection

If you want to contribute to crates.io you're bound to github. No gitlab, codeberg, gitee, sourcehut, etc.

Not sure if there are any other problems, but those two seem like the biggest things and #1 is AFAIK not something they ever want to change + it would be difficult to as one would need a migration strategy.

TL;DR

We want to improve the reliability and performance of crate downloads.

"Non-canonical downloads" (that use URLs containing hyphens or underscores where the crate published uses the opposite) are blocking these plans.

On 2023-11-20 support for "non-canonical downloads" will be disabled.

cargo users are unaffected.

I'm working on a parsing library for mil-std-1553 messages. It's a fun, minimal project that doesn't currently exist as far as I can tell.

Really fast post parser, notifications, OpenTelemetry, dedicated job runner, and more!

Now with pre-built binaries for Windows, MacOS, and Linux with install scripts for PowerShell and Bash!

https://corteximplant.com/@0x0/111297237963021572

Hey everyone, first time poster, long time lurker.

I've been crawling crates.io trying to find an existing crate that supports using JSONPath to query a document and returns both the selected node, and the actual path to said node.

For example, say I have the following JSON object:

{ 
  "foo": { 
    "bar": { 
      "baz": "hello!" 
    } 
  }
}

And I query it with $.foo.*.baz, it would return something like:

{ 
 node: "hello!", // Would be something like serde::Value
 path: "$.foo.bar.baz"
}

Does anything like this exist (or is in development) in the rust eco-system today?

Any help would be most appreciated, thank you!

@rust Blog post: Mutable object trees in Rust, using memory arenas

https://radiki.dev/posts/mutable-cursor-dags-in-arenas-rust/