// Git

For some time, I've been using GitHub actions to update the content of my site (i.e. pages, descriptions, metadata, etc.). Through Hugo, these content updates automatically update the RSS feeds. This then makes the episodes appear in podcast services such as Apple Podcasts, Google Podcasts and Spotify. However, throughout that time I have been manually uploading the podcast files to my storage account. It wasn't a significant overhead, but I kept thinking that there must be a better way to do this. And, there is - I've implemented it! This blog post will walk you through why I've made these changes, how I made them and what the result is.

Git stores all version history as compressed objects — commits, trees, and blobs — inside the .git folder. This Cloud Drop walks through the .git directory structure, uses git cat-file -p to inspect commit, tree, and blob objects, and shows how refs map human-readable branch names to commit hashes, including remote-tracking refs created when pushing to GitHub.

Git LFS (Large File Storage) is a Git extension that replaces large binary files in your repository with lightweight text pointers, storing the actual data on a remote server. This Cloud Drop demonstrates git lfs install, git lfs track "*.mp3", staging and committing with LFS active, and using git clone --config lfs.fetchExclude to selectively skip large files when cloning.

Three months and 350+ subscribers in, with content shipping every day of the past week: a GitHub Codespaces Cloud Drop, the final GPG commit-signing instalment covering YubiKey hardware key storage, a Welsh Azure User Group lightning talk on GitHub Actions, and a Terraform Cloud deep-dive on Azure state management. Azure news centres on Microsoft's commitment to bring Availability Zones to every region by end of 2021, new forecasted cost alerts for Azure Budgets, and the Start Small & Expand landing zone guidance from Sarah Lean and Thomas Maurer. GitHub updates include Dependabot gaining private registry support, CodeQL scanning for Solarigate traces, and a detailed post-mortem on the recent GitHub.com security incident.

Part 4 - The final part (at least for now, until I find somewhere else that we can expand on with this)! This part will focus on porting the keys that we have recently generated onto our YubiKey device. I own a YubiKey NEO, so i'll be using that.

Vlog #11 debuts a refreshed brand and on-screen layout, then covers a busy week: the third instalment of Chris's GPG commit-signing series (linking keys to Git and GitHub), the Cache Aside cloud design pattern episode, and a preview of the upcoming YubiKey-focused Part 4. Azure news centres on the preview of Trusted Launch VMs (defending against bootkits and rootkits), Azure Defender for Storage's new malware-upload detection, and Naraya — the ML system Microsoft uses to predict and proactively mitigate infrastructure failures at scale. On the security operations side, GitHub and Azure DevOps announce automated token revocation for leaked PATs found on public GitHub repositories.

Okay, part 3! At this point, I'm assuming that you have already familiarised yourself with [part 1](./blog/gpg-git-part-1) and [part 2](./blog/gpg-git-part-2) of the series. As a quick recap, part 1 focused on why we would consider using GPG Keys in general. Part 2 focused on how to generate GPG keys along with some recommended practices on splitting out our master (Certification) key, from our specific purpose-driven keys. This post (part 3) focuses on using those keys as part of our usual development workflow using Git. We'll be assuming that GitHub is our end target, as GitHub supports [commit signature verification using GPG Keys](https://docs.github.com/en/github/authenticating-to-github/managing-commit-signature-verification).

Vlog #10 is a milestone episode: Chris celebrates his birthday and a full year of Cloud With Chris with a new Shure SM7B microphone upgrade. The bulk of the episode is a walkthrough of Microsoft Ignite announcements, covering Azure Arc-enabled Machine Learning for on-premises data sovereignty scenarios, the Azure Communication Services and Microsoft Teams interoperability story, and significant security updates including Azure Key Vault Managed HSM (preview) and Trusted Launch for VMs. GitHub Actions fans also get a bonus segment on four lesser-known platform capabilities, including semantic release note generation and bring-your-own-environment workflows.

Hopefully by now you've had a chance to read [part 1](gpg-git-part-1) of this series, which explains why you may be interested in using GPG keys to sign your commits. Congratulations on getting to the second part! In part two, we're going to focus on how I worked through setting up GPG in my Windows environment, and generating a set of keys for use. There were some challenges/hurdles along the way, and we'll talk through those too!

For a while now, I've been using GPG Keys to sign my Git Commits to prove that my commits on GitHub are genuine and from me. Over the last few weeks, I've been inspired by a couple of colleagues (Kudos to Adrian and Julie if you're reading this) to dig out my YubiKey and use these for my key signing activities. While there are several blog posts on the topic already, I encountered a number of roadblocks along the way. The intent of this blog post is to be the first of a series, where we'll explore what GPG is, why it may be valuable to you and how you can get going using them. We'll then take this forwards an additional step, and show how you can use YubiKeys as a second factor of verification and the benefits of this approach. By no means am I the world's expert in cryptography, and some of these topics, but I wanted to document my own understanding for posterity, as I'll inevitably need to repeat/review the process in the future. I hope that this may be useful to you.