Rust Programming

An open-source, lightning-fast, and hyper-relevant search engine that fits effortlessly into your apps, websites, and workflow.

Enarx is an open source framework for running WebAssembly applications in TEEs (Trusted Execution Environments).

Enarx is completely written in Rust and includes an SGX shim, and an X86_64 unikernel via KVM with SEV-SNP support.

Recent contributions allow development and testing of the WebAssembly apps on non X86_64 hardware as described in https://blog.enarx.dev/backend-nil/

Our contributions to Rust include:

• static-pie support
• x86_64-unknown-none Tier 2 target
• stabilization of naked functions
• network support for wasm32-wasi
• bindeps feature for cargo

AMA

This makes real GATs practically unusable for most use cases. I’m still happy they’re being stabilized, but they likely won’t see wide adoption in APIs until this problem is solved.

Rust is often described by its fans (me included) as the most advanced programming language, perfectly mixing Computer Science and real-world usability. Yet, Rust is far from perfect and may often be frustrating for developers.

So today, let's start from the axiom that Rust is the least bad programming language and what it would take to make it the "perfect" language and ecosystem.

This could be trash or not, but finished my first rust crate mailcap.

v0.1.0 is pretty much on par (as an example) with the functionality present in the python mailcap library in the stdlib. I noticed that there's no existing mailcap parsing crate in the rust ecosystem and had plans on actually creating a good custom opener (as my old python one is kinda hacky and well, obviously written when I was very new). So had to make the first step on the parser first before moving onto that.

Mailcap files are honestly much more flexible than .desktop files, as a single configuration file controls everything and it makes creating custom commands much easier. For example, I can specify easily a chain where gifs, despite being images, open in a video player with a custom command, while any other video or image default to something else.

image/gif; mpv --loop-file '%s' --loop=inf; test=test -n "$DISPLAY"
image/*; feh -g 1280x720 --scale-down '%s'; test=test -n "$DISPLAY"
video/*; mpv '%s'; test=test -n "$DISPLAY"

For a quick primer on what the opener would be that justifies this crate, what I use the python one for is setting it as my opener for any software which allows that to be changed (e.g. nnn, alacritty keyboard shortcuts) and overriding XDG_OPENER through a .desktop file. With the above example, any gif will open in mpv and loop infinitely, any other image will open in feh, while any video opens in mpv. The standard ~/.config/mimeapps.list does not support wildcards, and having to create custom .desktop files for variations such as the above is a much greater hassle.

Another plus is specifically for web URLs. The default behavior will be to open in a browser, while using something powered by a mailcap file makes that much more flexible. For example in my current python implementation, seeing the extension for a direct link to a file (e.g. my avi https://lemmygrad.ml/pictrs/image/H7j8YOJVDZ.png) will set this the mime type to image/png, and with the above mailcap example, will default to 'image/*' and open up the image in feh instead of a browser. And given that this is a custom opener, I use domain matching for sites such as gfycat to open in mpv.

The above two paragraphs are out of scope for this crate itself, but just wanted to give context on why I began work on it. I'm new to rust, but I hope this initial release is decent!

srht project page: https://sr.ht/~savoy/mailcap/

Out of the 58 in-the-wild 0-days for the year, 39, or 67% were memory corruption vulnerabilities. Memory corruption vulnerabilities have been the standard for attacking software for the last few decades and it’s still how attackers are having success. Out of these memory corruption vulnerabilities, the majority also stuck with very popular and well-known bug classes:

• 17 use-after-free
• 6 out-of-bounds read & write
• 4 buffer overflow
• 4 integer overflow