Hi all,

ref: https://programming.dev/post/16349359

I agree with all the criticism about the author, the intentions, and the points in the article, expressed in the ref. thread. I also think the author highlights a serious issue (if we leave "selling the book", cheap criticism, and sensationalism aside). While nothing new for most developers, the article has spawned a personal rabbit hole of discovery, starting from supply chain attacks.

I am still very early in my process of learning Rust (still reading The Book) and self-taught software engineering in general, and the journey the article has spawned was very educational to me. I've learned about securing software and being mindful across the whole SDLC[1], AppSec, DevSec, OWASP, SLSA[2] Socket[3], GitHub Advanced Security, and many more tools and guidelines. Last of which is RustSec[4]. Which quenched my thirst and closed that personal rabbit hole. It has opened a different can of worms though.

While endemic to any non-monolithic ecosystem and only part of the "big security picture", supply chain is possibly the major player across the spectrum. Comparable to "the legacy issue" of stagnating systems and infrastructures, open to exploits as old as the Sun.

Now, while I am aware that security is a process, not a product and that this is easier said than done: I wonder if tools like RustSec should be embraced at the foundational level and made a "mandatory best practice". RustSec tools integrate with an up to date security advisory database and Cargo. They can also be deployed as GitHub Actions.

Because I am sure this is not all roses: I agree that (for example) dependabot is seen as a major annoyance more than a useful tools for a number of reasons, and that RustSec could spark the same kind of thoughts. However, it could be a great stepping stone of the security process.

I am aware I may be being too idealistic here, but the process has to start from somewhere and stagnating on "dogmas" ain't helping either.

Please be kind in your replies.

Cheers

[1] https://www.youtube.com/watch?v=hDvz8KivY_U [2] https://slsa.dev [3] https://socket.dev [4] https://rustsec.org

We finally were able to finish the sync with the Rust compiler and now support the types f16 and f128!

I had a lot of stuff going on lately in my private life, so I wasn't able to work as much as I wanted on rustc_codegen_gcc. Hopefully, it should be back to normal after my vacation.

It's less than two weeks until our next Rust and NixOS meetup in Mannheim, Germany. We're meeting on the 16th of July at the Mafinex technology center close to the main station. If you want to join us, please sign up for the event on Mobilizon (no account required) or Meetup.com.

https://rheinneckar.events/events/9d740b89-7713-4e19-a112-45aff1670f0f

https://www.meetup.com/hackschool-rhein-neckar/events/301504325/

As first talk, we will hear Andre Dossinger on "Using NixOS for Pragmatical Self-hosting", where he will show us how NixOS can be used in a problem oriented manner to preserve privacy and make complex setups manageable. Questions and discussions are highly encouraged!

Then, we will hear Benjamin Sparks on "Reading from Streams and Writing to Sinks" using Rust and Tokio, with a focus on low runtime overhead, safe buffer management, and robust error handling. He will show us the types and traits Tokio leverages to efficiently decode bytes and encode structured data in a type-safe manner is presented, and give us a practical demonstration of codecs for two different protocols.

Finally, Stefan Machmeier of the EMCL at Heidelberg University will give us an introduction to Nix Flakes, the experimental dependency management system built into Nix since version 2.4 that can be used for reusable Nix libraries as well as your own Nix packages and NixOS configurations.

The talks will be recorded and uploaded after the meetup.

July 2, 2024

Sylvain Kerkour writes:

Rust adoption is stagnating not because it's missing some feature pushed by programming language theory enthusiasts, but because of a lack of focus on solving the practical problems that developers are facing every day.

... no company outside of AWS is making SDKs for Rust ... it has no official HTTP library.

As a result of Rust's lack of official packages, even its core infrastructure components need to import hundreds of third-party crates.

• cargo imports over 400 crates.

• crates.io has over 500 transitive dependencies.

...the offical libsignal (from the Signal messaging app) uses 500 third-party packages.

... what is really inside these packages. It has been found last month that among the 999 most popular packages on crates.io, the content of around 20% of these doesn't even match the content of their Git repository.

...how I would do it (there may be better ways):

A stdx (for std eXtended) under the rust-lang organization containing the most-needed packages. ... to make it secure: all packages in stdx can only import packages from std or stdx. No third-party imports. No supply-chain risks.

[stdx packages to include, among others]:

gzip, hex, http, json, net, rand

Read Rust has a HUGE supply chain security problem

Submitter's note:

I find the author's writing style immature, sensationalist, and tiresome, but they raise a number of what appear to be solid points, some of which are highlighted above.

Hi rustaceans! What are you working on this week? Did you discover something new, you want to share?

Rust Rover is out of preview and is free for non-commercial use. The only caveat is:

It’s also important to note that if you’re using a non-commercial license, you cannot opt out of the collection of anonymous usage statistics.

Found this on Mastodon https://fosstodon.org/@dpom/112681955888465502 , and it is a very nice overview of the containers and their layout.

Hi rustaceans! What are you working on this week? Did you discover something new, you want to share?

Is there a good general-ish purpose scripting language (something like Lua on the smaller end or Python on the bigger) that’s implemented in only Rust, ideally with a relatively low number of dependencies?

Have you used it yourself, if so for what and what was your experience?

Bonus points if it’s reasonably fast (ideally JITed, though I’m not sure if that’s been done at all in Rust).

I've needed to detect a frequency of an audio signal a couple of times in my life, but I cannot for the love of me remember what does the FFT output actually mean. So I took this knowledge out of my latest project and packed it up in this crate.

Also this is my first potentially useful published crate, so if I missed anything, please let me know!

 name                                            diff %  speedup 
 slice::sort_large_random                       -65.49%   x 2.90 
 slice::sort_large_strings                      -37.75%   x 1.61 
 slice::sort_medium_random                      -47.89%   x 1.92 
 slice::sort_small_random                        11.11%   x 0.90 
 slice::sort_unstable_large_random              -47.57%   x 1.91 
 slice::sort_unstable_large_strings             -25.19%   x 1.34 
 slice::sort_unstable_medium_random             -22.15%   x 1.28 
 slice::sort_unstable_small_random              -15.79%   x 1.19

Hi! I've created a CLI tool for downloading Rust web books (like The Rust Programming Language) as EPUB, so that you can easily read them on your e-book reader. The tool is heavily based on this gist and a lot of proompting.

Check it out here: https://github.com/mawkler/rust-book-to-epub

That was a hard long adventure, massive refactoring with bug-fixing 🥵

I went to look into the activitypub federation package from Rust and noticed that it does not support JSON-LD. This took me to a search into other libraries, which got me to RDF-based crates. Just thought it was a good idea to share.

Hi rustaceans! What are you working on this week? Did you discover something new, you want to share?