Besides the core libraries, we made the following crates generally available (GA):

• azure_storage_blob
• azure_storage_queue
• azure_security_keyvault_secrets
• azure_security_keyvault_keys
• azure_security_keyvault_certificates

azure_data_cosmos and azure_messaging_eventhubs will be available soon.

Getting Started

We have a lot of great examples in our azure_core documentation. You can also find other azure_core examples in our repository.

Extensibility

Rust doesn’t have a lot in its standard library - not even an async executor. Thus, applications need to pick an executor. While tokio is the most common async executor - and on which our default HTTP client, reqwest is based - there are other executors and HTTP clients applications may want to use. Azure service have to use a platform called Oxidizer - some of which is public - that provides an async executor optimized for running Azure services.

Thus, we support replacing the async executor and/or the HTTP client, along with customizing the default reqwest::HttpClient or even just adding HTTP policies like with all our Azure SDK languages.

See our cross-cutting samples.

Origins

This started as passion project. I had been writing Rust for a while but wanted something substantial to work on. I started the original Azure/azure-sdk-for-rust repo. Not long after, some colleagues heard about this and had been working on some unofficial crates that MindFlavor started. I ended up archiving my project and we forked his in its place. It went through a lot of changes to align with our Azure SDK general guidelines while I started working on the initial Rust guidelines.

As people moved on and the project was made official, I was named the architect and started prototyping many different ideas based on popular Rust projects. Anyone that tells you there is decidedly an “idiomatic Rust” is wrong. There are certainly common patterns, but with no clear language guidelines/recommendations like some other languages, there are lots of popular patterns from simple struct initialization, builders, typestate builders, and more. After going through some patterns with other architects, Rustaceans in the company, and people just starting to learn Rust - we want this to be approachable - we settled on a pattern.

While I tried to maintain as much legacy as possible, some radical change was necessary. At that point, I moved the existing code to that point into the legacy branch. If we needed to make any critical security fixes, we still could. But development continued on in the main branch.

Thanks

I can’t thank enough the people who bootstrapped all this effort: Francesco, Ryan, Cameron, Brian, et. al. And for the people who took up the mantle when this was made an official project: Larry, Joel, Rick, Ashley, Anton, Ronnie, Patrick, Brian, et. al.

Blue Hour

I looked at a couple color palette sites for some color ideas then asked Copilot + Sonnet to work up a few color demos keeping accessibility in mind. From there I picked one I liked and had it update the necessary minima colors as well as replace the Kraken-inspired colors. It made re-theming the site pretty quick. I’m no designer, but it thought through accessibility and contrast issues I wouldn’t have considered.

I think it turned out pretty good:

Even for more established Azure SDK languages like .NET or Python, new APIs might be added to a particular service or new patterns may evolve that are better to use.

Whatever the case, additional context can improve productivity and reduce cost.

Example context

I wrote an MCP that discovers Azure SDK dependencies already pulled down, and adds their README.md and other regocnized examples - like Rust’s examples/ directory that is included in our crates - and adds them as context. As the demo video below shows, this greatly reduces the number of turns for Rust, thereby reducing the token count and cost:

As a successful prototype, there is still more we can improve on here like distilling the examples from the README.md instead of sending the entire page. Taking advantage of memory in modern agents, we could also link general patterns like those found in our core libraries e.g., azure_core for Rust.

I’m excited to see how we can apply findings from this prototype to further improve the developer experience when using Azure SDKs!

My posts will always be written by me, a human, sharing tips, personal news, and more. And though I started writing web sites before HTML 1.0 was formally standardized, I’ve never been good at design. My blog used Jekyll Minima with a few overrides and I only recently updated it to 2.5, but was envious of the theming that 3.0 has in development. Though I really haven’t touched much CSS since shortly after 2.0 was released, I knew the mechanics but wanted a little help prototyping some ideas quickly.

Trying out themes

It probably wasn’t obvious, but my previous color palette used Seahawks colors. I wanted to see what mixing those colors or other colors might look like for light and dark themes. With some links to the color palettes I was considering - but haven’t necessarily settled on for the foreseeable future - asked Copilot with Sonnet 4.6 to render a few. It didn’t take long - certainly faster than I’d have done it - and I was able to select a theme as a start quickly. I made a few tweaks and had it apply the changes with some color mapping instructions from the old palette.

Having been to several of their games with my son - who loves hockey - and my wife - who merely tolerated it but got a selfie with Buoy - I choose a Kraken color palette. They put on one heck of a show at Climate Pledge Arena.

It took a few iterations to iron out the kinks. I would verify the responsive site in Safari’s dev tools and batch several changes with explicit instructions. As with any time I use an LLM to generate code, I review and recommend changes as needed.

Theme switcher and responsive fixes

With separate light and dark themes, I next had it lay the ground work to switch themes and fix some responsive issues, like certain buttons being too long on mobile viewports so I’d change the text to “Subscribe” instead of “Subscribe on Sequoia” in the sequoia-subscribe component. Again, with a carefully crafted prompt, it didn’t take long to generate the necessary changes that’d probably have taken me a couple hours.

With all changes reviewed and tested, I finally had a properly responsive and themed web site I’ve been wanting but just haven’t found the time.

I was also working on an idea for unified test resource provisioning across SDKs and languages and was working with a couple different vaults in the Azure Portal: our test secrets used by all the languages, and one I had just created for some tests. Certain I had the right one selected, I was prompted Are you sure you want to delete this vault? with just Yes and No buttons, and clicked Yes.

I was wrong.

I deleted the shared test secrets used by Azure Pipelines and more.

Within seconds I realized my mistake, hurried down the hall to our engineering systems team room, and echoed Gob Bluth’s famous line, “I’ve made a huge mistake.”

Not the best start on a new team, but what happened next is what I like to share with mentees both junior and senior.

Driving change

In the short term, we needed to restore functionality. Soft delete wasn’t enabled on the vault, so the vault was truly gone. But across all the developers, we all had enough secrets in process or machine environment variables¹ that we could restore most of the secrets. Others we just had to regenerate and deal with as problems arose.

In the long term, I wanted to make sure something so vital - think about a company losing production secrets on which their business depends - didn’t happen again, or at least wasn’t so easy.

I had already developed a pretty good rapport with the Key Vault service team, and worked with them on some changes:

1. The name of the vault wasn’t part of the original prompt. They added the name of the vault and changed the buttons to more descriptive Delete and Cancel.

2. They moved up plans to enable soft delete by default. After that change, you had to explicitly disable soft delete. Seems many customers weren’t aware of soft delete, which allows you to recover a deleted vault or vault resource for a configured number of days - the default being 90 days.

   Eventually, a change was made such that soft delete couldn’t be disabled, and purge protection could be enabled that prevented a deleted vault or vault resource from being purged for the configured number of days.

Final thoughts

We all make mistakes. I was a senior at the time and not long after that was promoted to a principal engineer. I still make mistakes - perhaps not as bad and hopefully won’t - but how we deal with them and learn from them is what matters.

Own up to the mistake and try to prevent them from happening again or to anyone else, if relevant. Seek out partners to brainstorm ideas and show a growth mindset among your peers and management. They’ve all made mistakes too.

Since the Key Vault service allowed an empty string for the key version for all endpoints, the KV SDKs across all languages back then - .NET, Java, JavaScript/TypeScript, and Python - we made the key version parameters in all those languages optional even though they didn’t all technically follow language guidelines for optional parameters: optional parameters go into “options bags” - an optional parameter that had a bunch of optional properties on it or, for pythonistas, kwargs.

For key data operations that generally fine: an empty version means you act on the latest key version; however, for cryptography operations - encrypt, decrypt, sign, verify, wrap, and unwrap - that can inadvertently lock you out of your data. For example, if you encrypt with key version 1 and that key is rotated to version 2, you won’t be able to decrypt with version 2. You can work around this by cycling through key versions, but knowing when you found the right one isn’t always easy if you don’t know the plaintext. This is compounded when unwrapping a symmetric key because the key length is the same and, in some block ciphers, will decrypt into plaintext you can’t always validate.

Required for Rust

Since I’m the architect for the Azure SDK for Rust, have much more experience with Azure Key Vault now, and have been working on the Key Vault SDKs for Rust, after having talked with the Key Vault service team about it, we made the key version parameter required for cryptography operations. Not only does this mean the version parameters actually follow language guidelines, but that they steer customers into the pit of success. You can still pass an empty string "" to use the latest version but it’s not recommended.

I’ve updated the akv CLI accordingly to require the key version for the encrypt command, whether passed to --version or (new) passed as a key URI with version.

Hopefully by requiring a key version for crypto functions, customers will be less likely to accidentally lock themselves out of their encrypted data.

Using cargo-cache as I described previously can help clean up old dependencies, and you can delete all targets/ from repos under some directory like so:

find -maxdepth 2 -name targets -execdir rm -rf {} \;

After that and cleaning up any other files you don’t need, log out of all your WSL sessions, close down Visual Studio Code if you have it running and connected to WSL e.g., if you started code from within WSL, and shut down WSL:

wsl --shutdown

Now for the easier part: find the VHDX for your distro and shrink it all from within PowerShell:

# Replace "Ubuntu-24.04" with your distro name
$path = (Get-ChildItem -Path HKCU:\Software\Microsoft\Windows\CurrentVersion\Lxss `
  | Where-Object { $_.GetValue("DistributionName") -eq 'Ubuntu-24.04' } `
  ).GetValue("BasePath") + "\ext4.vhdx"
Optimize-VHDX -Path $path

It may take a while, but after it completes you can log back into your distro. Seems WSL changed it so you don’t have to run resize2fs anymore - Ubuntu 24.04, at least, automatically picked up that more space was available.

It’s a CLI that works with various static-site generators to publish records into your PDS - something I was just starting to think how I wanted to tackle it. This CLI is a good start, so I’m happy to try it out, file bugs, and even submit pull requests!

This post, if all is set up correctly, should be the first post published to the ATmosphere.

rustup target add x86_64-unknown-linux-gnu
cargo build --target x86_64-unknown-linux-gnu

Of course, the targets’ compiler, headers, and libraries need to be available, but a typical install of Visual Studio or gcc will support common targets. But on my new work Surface Laptop 7 arm64 I needed to compile openssl-sys for my a project and that’s when the fun began:

error: failed to run custom build command for `openssl-sys v0.9.102`

----- SNIP ---8<
  cargo:rerun-if-env-changed=OPENSSL_DIR
  OPENSSL_DIR unset

While there are lots of ways of getting the bits I need - like compiling source myself or downloading and extracting files to the right locations - I like the convenience of a package manager especially when it comes to installing updates. But I’m running Ubuntu 24.04 aarch64, so how do I install packages for amd64 e.g., libssl-dev:amd64?

Configuring sources

While I’ve had some experience managing debian package repositories e.g., in /etc/apt/ I’ve never before had need to try to install packages for other architectures. I wasn’t even entirely sure it was supported, but a quick search got me started:

sudo dpkg --add-architecture amd64
sudo apt update

But updating the package index failed: I was getting several 404s because packages weren’t available on http://ports.ubuntu.com/ubuntu-ports/. I was also only familiar with the one-line format and not this new format I was seeing, which `man 5 sources.list tells me is DEP822-style.

After reading sources.list(5) and a bit of trial and error, I ended up with the following /etc/apt/sources.list.d/ubuntu.sources

Types: deb
URIs: http://ports.ubuntu.com/ubuntu-ports/
Suites: noble noble-updates noble-backports
Components: main universe restricted multiverse
Architectures: arm64
Signed-By: /usr/share/keyrings/ubuntu-archive-keyring.gpg

Types: deb
URIs: http://archive.ubuntu.com/ubuntu/
Suites: noble noble-updates noble-backports
Components: main universe restricted multiverse
Architectures: amd64
Signed-By: /usr/share/keyrings/ubuntu-archive-keyring.gpg

Types: deb
URIs: http://ports.ubuntu.com/ubuntu-ports/
Suites: noble-security
Components: main universe restricted multiverse
Architectures: arm64
Signed-By: /usr/share/keyrings/ubuntu-archive-keyring.gpg

Types: deb
URIs: http://archive.ubuntu.com/ubuntu/
Suites: noble-security
Components: main universe restricted multiverse
Architectures: amd64
Signed-By: /usr/share/keyrings/ubuntu-archive-keyring.gpg

Installing packages

After a quick and finally successful sudo apt update, I was able to install packages:

sudo apt install --yes libssl-dev:amd64

I was able to get further with my original goal of compiling openssl-sys, but then got an error about no linker available. I installed gcc:amd64 and almost able to compile my crate, but the linker failed so I needed to specify the linker explicitly in .cargo/config.toml:

[tageet.aarch64-unknown-linux-gnu]
linker = "aarch64-linux-gnu-gcc"

[target.x86_64-unknown-linux-gnu]
linker = "x86_64-linux-gnu-gcc"

Success! …well, almost.

When I tried a normal build e.g., cargo build I got pages full of compiler errors. Turns out, when I installed gcc:amd64 it replace a few components, since apt list --installed *gcc showed gcc-13-aarch64-linux-gnu was now removable.

After a quick search - there’s plenty of information of people wanting to cross-compile for aarch64 on amd64 - I realized I need to install a few packages at once, to effectively make sure all the right symlinks are created. I could’ve done this manually, but figured there were a number of executables I’d need to fix and would rather just let apt handle it:

sudo apt install --yes gcc-13 gcc-13-aarch64-linux-gnu gcc-13-x86-64-linux-gnu
sudo ln -s /usr/bin/x86_64-linux-gnu-gcc /usr/bin/x86_64-linux-gnu-gcc-13

The last line was just for convenience, which apt did for aarch64-linux-gnu-gcc and, originally, when I installed gcc-13-x86-64-linux-gnu standalone.

Cross-compiling for openssl-sys

I was finally able to cross-compile openssl-sys:

cargo build
PKG_CONFIG_SYSROOT_DIR=/usr/lib/x86_64-linux-gnu cargo build --target x86_64-unknown-linux-gnu

Fortunately, cleaning up all that Rust doesn’t require WD-40 and a little elbow grease. Here are a few tips:

1. Use cargo-cache to view information about and clean up the cargo cache:

   cargo install cargo-cache
   cargo cache --info
   cargo cache --help
   

   It hasn’t been updated in a while, but seems to work quite well.

2. Delete your target/ directory. Generally, most of the time building is spent acquiring crates anyway, but this can typically save you a lot of space, especially if you’ve been working in a repo for a while and dependencies have changed frequently.

WSL

This can be even more problematic when working in Windows Subsystem for Linux (WSL), since the virtual hard disk (VHDX) used to default to 256GB then later 512GB, and currently 1TB. Note, however, this is only the maximum size the VHDX sees as the maximum space. Depending on your physical drive space availability, it may be less.

In my case, recently, my old WSL Ubuntu-22.04 image thought it ran out because it only saw 256GB. Most of that was consumed by Rust and Go. You can view space using du from within WSL like so:

du -hd1 -t1gb .

If deleting repos’ target/ directories didn’t free enough space, you can resize your VHDX from an elevated shell:

# Replace 'Ubuntu-22.04' below with the name of your distro.

# Shut down your distro.
wsl --shutdown 'Ubuntu-22.04'

# Find the path to the VHDX file for your distro.
(Get-ChildItem -Path HKCU:\Software\Microsoft\Windows\CurrentVersion\Lxss `
  | Where-Object { $_.GetValue("DistributionName") -eq 'Ubuntu-22.04' } `
  ).GetValue("BasePath") + "\ext4.vhdx"

# Launch diskpart and resize the disk returned above as {path}.
diskpart
select vdisk file="{path}"
expand vdisk maximum="{size in MB}"
exit

Now log into your distro’s shell again and tell it that it has more disk space available:

# Find the correct device.
sudo mount -t devtmpfs none /dev 2> /dev/null
mount | grep ext4

# Copy the name e.g., /dev/sdc and resize it using the same size in MB as above.
sudo resize2fs /dev/sdb '{size in MB}M'