Dev With Imagination

As part of looking in to controlling the third party libraries which could be included for use by a project, I wondered if it was possible to effectively apply an approved whitelist at the Sonatype Nexus level. This would only be effective if developers and CI tools are restricted in their web access and cannot contact the central artefact repositories directly, and so are forced to use Nexus as a mirror.

It turns out that this is possible, and the Nexus documentation is pretty good if you know the pieces of the puzzle that need to be joined together to make this work. Roles, which can be assigned to specific users or an anonymous user, are made up of privileges. Privileges can include Content Selectors to restrict the results which are returned. When combining these things, we can effectively build a whitelist. As this approach is role based, different rules can be used depending on who the caller is.

» Continue reading

Third party dependencies are an essential part of every modern software project. It is nearly impossible to build a non-trivial application without depending on third party libraries.

However, by introducing external software dependencies you are also introducing an area of risk to a project. The OWASP top 10 lists “Using Components with Known Vulnerabilities” as the number 9 most critical risk to web applications in the last (2017) list. The linked page provides a lot more detail on the risk and general mitigations, and if you have not came across this list before it really should be required reading for all developers.

There are four key points that need to be considered for the use of libraries by a project:

• only including libraries which are actually required
• ensuring the libraries have a licence which allows their use/distribution in your product
• ensuring libraries are kept up to date
• being aware of Common Vulnerabilities and Exposures (CVEs)

For a small number of dependencies it may be possible to manually keep on top of this, but ideally it should be automated. There are many commercial tools (such as Snyk and Sonatype Lifecycle) which can be used as part of the software delivery supply chain for performing scans and audits on the libraries that a project is using. In this series I will explore some of the options which can be put together using open source solutions.

As part of some experimentation I was doing with Docker Swarm I encountered some inconsistent behaviour in my setup. To rule out inconsistencies in OSs (since I was using a combination of Ubuntu and Debian Buster), I had a look at the install process for Ubuntu on a Raspberry Pi.

The Raspberry Pi which was spare for this experiment was a model 3A+, so no ethernet and only a single USB port. With Raspbian I would have added “wifi_supplicant.conf”¹ and “ssh”² files to configure the WiFi and enable SSH as part of the first boot.

I was looking for a similar approach that would work for a headless Ubuntu install.

I came across this project: Raspberry Pi Cloud-Init for WiFi. This uses the cloud-init system to configure, amongst other things, WiFi. This basically provides a few scripts to generate some additional files to copy on to an Ubuntu imaged SD card.

I did find however that it required a few updates to make it work for me on Ubuntu 19.10.

» Continue reading

Over the past few months I have been expanding the number of smart home devices I have and appreciating how HomeKit allows these to all be managed in a single place, regardless of the manufacturer.

There is one older device that I have which does not support HomeKit, and was only controllable through the App from the manufacturer. HomeKit support for this device is not coming, but there is a workaround.

Enter HomeBridge.

HomeKit support for the impatient.

Homebridge is a lightweight NodeJS server you can run on your home network that emulates the iOS HomeKit API. It supports Plugins, which are community-contributed modules that provide a basic bridge from HomeKit to various 3rd-party APIs provided by manufacturers of “smart home” devices.

There is a docker image available, but the setup instructions for this require the container to be ran with the “host” networking mode. The primary reason for this appears to be to allow an Avahi daemon to run in the container and be able to answer responses to mDNS requests, which requires the container to be in the same local network subnet as the device performing the lookup.

For isolation purposes I’m not a fan of running services in host networking mode, and I already have an avahi-daemon running on my server for advertising other services.

» Continue reading

Lately I have been doing some research into Feature Toggle approaches, and how these can be used in Micro Services components developed in Java. These are simple true/false values used to determine if a given application feature (or code path) is enabled.

On looking at a MicroProfile quick start with sample code, the Config feature specification looked interesting for tackling a piece of this functionality.

The aim here is to provide a proof-of-concept implementation that allows for feature toggles that can be scoped down to different user attributes. This should be able to act as a starting point for a more complicated implementation if required. While it turned out that this could not be done solely using the Config feature, there appears to be a viable approach when combining this with Context Dependency Injection (CDI).

In the interests of speed and simplicity, this will use a header in the HTTP request to define the role of the user. If this approach was to be used in a production environment this role assignment would need to be provided by something which is verifiable, such as the JWT token provided.

All the source code for this implementation is part of my microprofile experiments project.

» Continue reading