diff --git a/.drone.yml b/.drone.yml index 70a87e0..9f28f20 100644 --- a/.drone.yml +++ b/.drone.yml @@ -3,11 +3,25 @@ kind: pipeline name: default steps: + - name: lint + image: peterdavehello/markdownlint + commands: + - markdownlint content/ + trigger: + event: + exclude: + - promote + - name: build image: bdebyl/hugo commands: - git clone https://github.com/bdebyl/hugo-theme-even.git themes/even - hugo + when: + event: + - promote + target: + - production - name: deploy image: bdebyl/awscli @@ -29,6 +43,6 @@ steps: - production --- kind: signature -hmac: 3109d79e76507ab2e9a820522c68b429007ca6f25e0ca16b1b46ed0aba66d23e +hmac: 7f15ec618d95cce36ecf999e018b38c056d52538fd6b5c81bdf5c6ce46e0fd21 ... diff --git a/.markdownlint.json b/.markdownlint.json new file mode 100644 index 0000000..314cfae --- /dev/null +++ b/.markdownlint.json @@ -0,0 +1,8 @@ +{ + "default": true, + "MD025": false, + "MD013": false, + "MD033": { + "allowed_elements": ["center", "sub", "i"] + } +} diff --git a/README.md b/README.md index 7080d37..e5ae56a 100644 --- a/README.md +++ b/README.md @@ -1,4 +1,5 @@ # Description + This repository houses the posts for my site [bdebyl.net](https://bdebyl.net). I make occasional updates to add blog posts, tutorials, projects write-ups, @@ -9,35 +10,43 @@ specifically [alimac/terraform-s3 (from commit 4b32c8d)](https://github.com/alimac/terraform-s3/tree/4b32c8d336ffacc4318c065f8d135973210f535c) -- big thank you to [**@alimac**](https://github.com/alimac/) on GitHub for that! - # Usage + The Makefile is a simple wrapper for the `bdebyl/hugo` Docker image and `aws s3`, but provides useful short commands to test the hugo site locally and deploy it to AWS. ## Dependencies + [Docker](https://docs.docker.com/install/) is required to run the make targets for hosting and generating the static Hugo site. ## Development + To build the static content _without_ running the Hugo server: -``` + +```bash make build ``` To start the Hugo server on `http://localhost:1313`: -``` + +```bash make run ``` ## Deployment + To deploy to AWS: -``` + +```bash make deploy ``` ## Cache Busting + Bust the Cloudfront cache: -``` + +```bash make cache ``` diff --git a/config.yaml b/config.yaml index cc8244f..7f52e1c 100644 --- a/config.yaml +++ b/config.yaml @@ -1,31 +1,45 @@ +# core baseURL: "https://bdebyl.net/" -title: "A random assortment of my personal projects." +title: "Collection of useful, and useless information" theme: "even" + +# settings +paginate: 5 defaultContentLanguage: "en" languageCode: "en" -paginate: 5 -copyright: "Bastian de Byl" # default: author.name -preserveTaxonomyNames: true -enableRobotsTXT: true buildDrafts: false canonifyURLs: true +enableRobotsTXT: true +preserveTaxonomyNames: true +markup: + goldmark: + renderer: + unsafe: true -googleVerification: "" # Google Verification -googleAnalytics: "UA-163975086-1" # UA-XXXXXXXX-X +# google analytics +googleAnalytics: "UA-163975086-1" +googleVerification: "" + +# See https://gohugo.io/about/hugo-and-gdpr/ +privacy: + googleAnalytics: + anonymizeIP: true + youtube: + privacyEnhanced: true # https://gohugo.io/content-management/syntax-highlighting/ -pygmentsOptions: "" pygmentsCodefences: true -pygmentsUseClasses: true pygmentsCodefencesGuessSyntax: true +pygmentsOptions: "" +pygmentsUseClasses: true author: name: "Bastian de Byl" sitemap: changefreq: "weekly" - priority: 0.5 filename: "sitemap.xml" + priority: 0.5 menu: main: @@ -56,16 +70,12 @@ params: # paginate of archives, tags and categories archivePaginate: 20 - # show 'xx Posts In Total' in archive page ? showArchiveCount: true - # The date format to use; for a list of valid formats, see https://gohugo.io/functions/format/ dateFormatToUse: "2006-01-02" - # show word count and read time ? moreMeta: false - postMetaInFooter: true # contain author, lastMod, markdown link, license linkToMarkDown: true # Only effective when hugo will output .md files. contentCopyright: 'Creative Commons License' @@ -75,27 +85,3 @@ params: g-github: "https://github.com/bdebyl" m-instagram: "https://instagram.com/bastian.remi" n-gitlab: "https://gitlab.com/bdebyl" - -# See https://gohugo.io/about/hugo-and-gdpr/ -privacy: - googleAnalytics: - anonymizeIP: true - youtube: - privacyEnhanced: true - -# Uncomment these options to make hugo output .md files. -#[mediaTypes] -# [mediaTypes."text/plain"] -# suffixes: ["md"] -# -#[outputFormats.MarkDown] -# mediaType: "text/plain" -# isPlainText: true -# isHTML: false -# -#[outputs] -# home: ["HTML", "RSS"] -# page: ["HTML", "MarkDown"] -# section: ["HTML", "RSS"] -# taxonomy: ["HTML", "RSS"] -# taxonomyTerm: ["HTML"] diff --git a/content/about.md b/content/about.md index f6ebaba..fff938f 100644 --- a/content/about.md +++ b/content/about.md @@ -2,6 +2,7 @@ title: "About" --- # About + I created this site as a way of showcasing my projects, or other general ideas. It's a sort of _engineering_ portfolio, if you will. @@ -17,10 +18,12 @@ Git repositories[^1], or ways to contact me such as [email](mailto:bastian@bdebyl.net). # GPG Fingerprint + The image at the **top-left** of this site (_on desktop_) is my OpenPGP v4 key fingerprint QR-code. Feel free to scan it using the [OpenKeychain](https://www.openkeychain.org/) app! I'll provide it here in-case you are on a mobile device, and my full public key: +
![OpenPGP v4 Fingerprint](/static/img/pubfpr-lrg.png) @@ -28,7 +31,8 @@ you are on a mobile device, and my full public key:
{{< admonition info "Public Key" true >}} -``` + +```text -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFoTpoMBEADDIjRewOTvJBQF4ZxK/LS7yBL0TuU7VbZzEH3s5YKj63P/Rmvx 8/jMm0iop+uiPNo+0imIGYsdfW77bt95I9+kBm27eVf8mDMldMiS/LBCCmnuQ19u @@ -146,11 +150,12 @@ teulWQZ/WMzUvU9IR6q3RcYbHm3yzbXVGzHXeLGUDWjvbKsDezUmn2desfexh+U7 KpNnEkXDMtMCsNkEMzM+3/BkuxLO52zYpDe5tV7Igx0= =N6h6 -----END PGP PUBLIC KEY BLOCK----- - ``` + {{< /admonition >}} # Resume + I do not currently keep an up-to-date version of my resume. In the past, I have written up my resume using [LaTeX](https://www.latex-project.org/) as a PDF. I may explore other solutions such as simply keeping it on this website.. _we'll diff --git a/content/post/aperture-study.md b/content/post/aperture-study.md index 96ba796..9a347e5 100644 --- a/content/post/aperture-study.md +++ b/content/post/aperture-study.md @@ -17,28 +17,30 @@ setting for a specific lens. # The Setup + I started out using a tripod, with the same ISO and exposure compensation using a [**Minolta 50mm f1/7**](https://en.wikipedia.org/wiki/Minolta_AF_50mm_f/1.7) lens. Starting at *f/1.7* I worked my way up at reasonable steps to *f/4.0*. My aim was to compare the differences. See the shots below. The target couch cushion was set up roughly a meter from the bottom center of the tripod. - # Depth-of-Field -There may be something to be said about maintaining the best DoF -(*Depth-of-field*). However, using [PhotoPills DoF Calculator] -(https://www.photopills.com/calculators/dof) proves just how **wild**, using a -50mm lens, an aperture of *f/1.7* is. Shooting a target of *2 meters* results in -a depth-of-field of **16 centimeters** -- that's a very narrow range! Bumping up -the aperture value to *f/2.8* provides a much more reasonable *27 centimeters*, -though still a bit narrow. Either way this allays any fears I had of losing out -on that sweet, *sweet* [bokeh](https://en.wikipedia.org/wiki/Bokeh), though the -photos themselves illustrate that not a significant amount of Depth-of-Field is -lost at that target distance of 1 meter. +There may be something to be said about maintaining the best DoF +(*Depth-of-field*). However, using [PhotoPills DoF Calculator](https://www.photopills.com/calculators/dof) +proves just how **wild**, using a 50mm lens, an aperture of *f/1.7* is. +Shooting a target of *2 meters* results in a depth-of-field of **16 +centimeters** -- that's a very narrow range! Bumping up the aperture value to +*f/2.8* provides a much more reasonable *27 centimeters*, though still a bit +narrow. Either way this allays any fears I had of losing out on that sweet, +*sweet* [bokeh](https://en.wikipedia.org/wiki/Bokeh), though the photos +themselves illustrate that not a significant amount of Depth-of-Field is lost +at that target distance of 1 meter. # Comparison + ## *f/1.7*--*f/4.0* + The biggest difference can be seen between the *f/1.7* and *f/4.0* shots. Note the increase in clarity on the pillows fabric. @@ -49,6 +51,7 @@ the increase in clarity on the pillows fabric. --- ## *f/1.7*--*f/2.8* + At *f/2.8* and above I started noticing less increase in perceived sharpness of the image, though the difference in comparison to *f/1.7* was still fairly noticeable @@ -60,6 +63,7 @@ noticeable --- ## *f/2.8*--*f/4.0* + Aside from the perceived exposure difference from what is most likely a difference in shutter speed, the overall difference does not seem as dramatic from *f/2.8* to *f/4.0*. Personally, I'd say that *f/2.8* is the clear winner in @@ -72,6 +76,7 @@ finding the best middle-ground between maximum aperture and image quality. --- # Individual Photos + Below is the entire collection of all the photos taken of the subject at increasing aperture steps. diff --git a/content/post/archinstall.md b/content/post/archinstall.md index a0aee22..de3dc2f 100644 --- a/content/post/archinstall.md +++ b/content/post/archinstall.md @@ -16,6 +16,7 @@ better understanding of the tools and methods used. --- # Partitioning + 1. Create a partition scheme using partitioner of choice (e.g. `gdisk`, `fdisk`, `cgdisk`). - First partition should be EFI/boot partition at around 256MB+ (type: @@ -25,93 +26,116 @@ better understanding of the tools and methods used. 1. Make the the EFI/boot partition FAT32 via `mkfs.fat -F32` # Encryption + 1. Format the Linux LVM partition: - ``` - # cryptsetup luksFormat /dev/sdaN + + ```bash + cryptsetup luksFormat /dev/sdaN Enter passphrase: ``` + **Note:** _Remember your passphrase! You will need this every time you boot your computer_ 1. Create a mapping for your Linux LVM (LUKS): + + ```bash + cryptsetup open --type luks /dev/sdaN ``` - # cryptsetup open --type luks /dev/sdaN - ``` + _Use whatever name you want. Ex. `lvm`, `volume`, etc._ 1. Create the physical volume, volume group, and logical volumes for `` specified in the previous step: + + ```bash + pvcreate /dev/mapper/ + vgcreate /dev/mapper/ ``` - # pvcreate /dev/mapper/ - # vgcreate /dev/mapper/ - ``` + _Use whatever volume name you want. Ex. `volume`, `main`, `linux`, etc._ + + ```bash + lvcreate -L2G -n swap ``` - # lvcreate -L2G -n swap - ``` + _Select size for swap, if desired. Here we use `2G` for 2Gb._ + + ```bash + lvcreate -L16G -n root + lvcreate -l 100%FREE -n home ``` - # lvcreate -L16G -n root - # lvcreate -l 100%FREE -n home - ``` + 1. Specify and write the desired filesystems: - ``` - # mkfs.ext4 /dev/mapper/-root - # mkfs.ext4 /dev/mapper/-home - # mkswap /dev/mapper/-swap + + ```bash + mkfs.ext4 /dev/mapper/-root + mkfs.ext4 /dev/mapper/-home + mkswap /dev/mapper/-swap ``` # Install Linux + 1. Mount the boot partition and logical volumes for installation: - ``` - # mount /dev/mapper/-root /mnt - # mkdir /mnt/home - # mkdir /mnt/boot - # mount /dev/mapper/-home /mnt/home - # mount /dev/sdaN /mnt/boot - # swapon /dev/mapper/-swap + + ```bash + mount /dev/mapper/-root /mnt + mkdir /mnt/home + mkdir /mnt/boot + mount /dev/mapper/-home /mnt/home + mount /dev/sdaN /mnt/boot + swapon /dev/mapper/-swap ``` 1. Install the base system (_Assuming you have internet connectivity. Use `wifi-menu`, or other, to connect to the internet at this point._): - ``` - # pacstrap /mnt base base-devel + + ```bash + pacstrap /mnt base base-devel ``` # Set-up Linux Installation + 1. Generate the `fstab`: - ``` - # genfstab -p /mnt >> /mnt/etc/fstab + + ```bash + genfstab -p /mnt >> /mnt/etc/fstab ``` 1. Move into the installation: - ``` - # arch-chroot /mnt + + ```bash + arch-chroot /mnt ``` 1. Configure `initramfs`: 1. Edit `HOOKS` in `/etc/mkinitcpio.conf` using text editor of your choice (e.g. `vi`, `nano`, etc.). Move the `keyboard` hook before `filesystems`, and add `encrypt` and `lvm2` hooks **before** `filesystems`: - ``` - # egrep '^HOOKS' /etc/mkinitcpio.conf + + ```bash + $ egrep '^HOOKS' /etc/mkinitcpio.conf HOOKS=(base udev autodetect modconf block keyboard encrypt lvm2 filesystems fsck) ``` + _Read the comment documentation on `HOOKS` in the document to find out more._ 1. Generate `initramfs`: - ``` - # mkinitcpio -p linux + + ```bash + mkinitcpio -p linux ``` 1. Install a bootloader (e.g. `systemd-boot`, `grub`, `syslinux`, etc.): 1. I will be using `systemd-boot` - ``` - # bootctl --path=/boot/ install + + ```bash + bootctl --path=/boot/ install ``` 1. Edit the loader configuration using a text editor of your choice: - ```apacheconf - # cat /boot/loader/loader.conf + + ```bash + $ cat /boot/loader/loader.conf default arch timeout 3 editor 0 @@ -121,8 +145,9 @@ better understanding of the tools and methods used. can edit this name if desired._). Use `blkid /dev/sdaN` to find the UUID of your crypt device, and recall the volume name you gave your device above (_`main` in example below_): - ```apacheconf - # cat /boot/loader/entries/arch.conf + + ```bash + $ cat /boot/loader/entries/arch.conf title Arch Linux linux /vmlinuz-linux.img initrd /initramfs-linux.img @@ -131,26 +156,30 @@ better understanding of the tools and methods used. 1. Create a root password using `passwd`. 1. Set a hostname: - ``` - # echo "" > /etc/hostname + + ```bash + echo "" > /etc/hostname ``` 1. Set up the time: - ``` - # ln -fs /usr/share/zoneinfo// /etc/localtime - # hwclock --systohc --utc + + ```bash + ln -fs /usr/share/zoneinfo// /etc/localtime + hwclock --systohc --utc ``` 1. Set the locale to `en_US`: - ``` - # sed -i 's/^\#en_US/en_US/' /etc/locale.gen - # locale-gen - # locale > /etc/locale.conf + + ```bash + sed -i 's/^\#en_US/en_US/' /etc/locale.gen + locale-gen + locale > /etc/locale.conf ``` 1. Done! - ``` - # exit - # unmount -R /mnt - # reboot + + ```bash + exit + unmount -R /mnt + reboot ``` diff --git a/content/post/emacs_clang_libopencm3.md b/content/post/emacs_clang_libopencm3.md index 458a62d..a553e8b 100644 --- a/content/post/emacs_clang_libopencm3.md +++ b/content/post/emacs_clang_libopencm3.md @@ -20,6 +20,7 @@ Emacs workflow to include IntelliSense-like auto-completion! # Dependencies ## System + Assuming you're running Linux, you'll need to have the following packages installed: @@ -29,21 +30,25 @@ installed: ## Emacs ### ELPA + If you already have ELPA/MELPA, feel free to skip this first part To be able to easily fetch the packages, it's highly recommended you use the **Emacs Lisp Package Archive** (ELPA). To do this, all that's required is to simply add the following to your `init.el`/`.emacs`[^1] file: + ```lisp (require 'package) (add-to-list 'package-archives '("melpa" . "https://melpa.org/packages/")) (package-initialize) ``` + Emacs will need to be restarted or reloaded to load the package repository. ### Packages + Install the following packages in Emacs (`M-x package-install`): - `irony` @@ -51,14 +56,15 @@ Install the following packages in Emacs (`M-x package-install`): - `company-irony` - `company-irony-c-headers` (_Required if you want header auto-completion_) - # Configuration ## Company + Company ([company-mode](http://company-mode.github.io/)) needs to be required, added to the `after-init-hook` (_or similar / manually called_), and the back ends to be added to it's list of usable back ends. This is done in the initialization file[^1]: + ```lisp (require 'company) (add-hook 'after-init-hook 'global-company-mode) @@ -66,11 +72,13 @@ file[^1]: ``` ## Irony + Initial setup of `irony` **requires** `M-x irony-install-server` to be run. If errors are encountered, please ensure that you have the necessary [system dependencies](https://github.com/Sarcasm/irony-mode#dependencies) installed. Irony's `irony-mode` should be added to the relevant C/C++ mode hooks: + ```lisp (add-hook 'c++-mode-hook 'irony-mode) (add-hook 'c-mode-hook 'irony-mode) @@ -79,21 +87,25 @@ Irony's `irony-mode` should be added to the relevant C/C++ mode hooks: Additionally, it's a good idea to add the compile options auto setup helper command to the `irony-mode` hook: -``` + +```lisp (add-hook 'irony-mode-hook 'irony-cdb-autosetup-compile-options) ``` # Usage + There are several ways to make `irony-mode` aware of what it should look for in it's completion. My preferred method, though not the only one, is to simply add my compile flags in the special `.clang_complete` file as part of the working directory of the project. For an STM32F0 project, the context of the `.clang_complete` file would be: -``` + +```text -I./libopencm3/include -DSTM32F0 ``` + The above assumes that `libopencm3` is also places within the project directory @@ -106,9 +118,9 @@ fairly uninvolved workaround. {{< /admonition >}} ## Example + {{< img src="/static/img/emacs-clang-libopencm3/completion.png" sub="Completion" alt= "Screenshot showing auto completion for C functions in emacs">}} -[^1]: [Emacs Initialization File] - (https://www.gnu.org/software/emacs/manual/html_node/emacs/Init-File.html) +[^1]: [Emacs Initialization File](https://www.gnu.org/software/emacs/manual/html_node/emacs/Init-File.html) diff --git a/content/post/gpg_best_practices_and_git.md b/content/post/gpg_best_practices_and_git.md index 558cc99..4a2ddb2 100644 --- a/content/post/gpg_best_practices_and_git.md +++ b/content/post/gpg_best_practices_and_git.md @@ -21,16 +21,18 @@ git config --global commit.gpgSign true For reference, I am directly referencing the subkey ID I use for **signing only** denoted by `[S]`: -``` + +```text pub rsa4096/ADAA54FC 2017-11-21 [SC] [expires: 2020-02-23] uid Bastian de Byl sub rsa4096/A72FC2F1 2017-11-21 [E] [expires: 2020-02-23] sub rsa4096/875953A2 2019-02-23 [S] [expires: 2020-02-23] ``` + Note: _I am using git version `2.20.1` in the above example._ - # Getting Started with OpenPGP + It is recommended to read through the [Getting Started](https://www.gnupg.org/gph/en/manual/c14.html) page on the official GnuPG website. It is also **strongly** recommend to use the @@ -40,6 +42,7 @@ create a separate subkey for **signing only** -- read more about that [here](https://wiki.debian.org/Subkeys). # OpenPGP Keyserver Pool + As of GnuPG version [2.1.11](https://github.com/riseupnet/riseup_help/issues/294#issuecomment-192913705), the `hpks.pool.sks-keyservers.net` CA certificate is installed and made use by @@ -51,13 +54,16 @@ signature. Instructions can be found on the reading further below. ## Verification + To verify and retrieve the necessary keys to do so (automatically, if possible): + ```bash gpg --auto-key-retrieve --verify sks-keyservers.netCA.pem.asc sks-keyservers.netCA.pem ``` The expected output: -``` + +```text gpg: Signature made Wed 30 Mar 2016 11:06:29 AM EDT gpg: using RSA key 250B7AFED6379D85 gpg: key 0B7F8B60E3EDFAE3: 1214 signatures not checked due to missing keys @@ -76,57 +82,66 @@ Primary key fingerprint: 94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 ``` ## Adding the HKPS Pool CA + Once the signature has been verified, the CA can be moved over to `/usr/share/ca-certificates` to update the list of trusted CA certificates. Do this via: -+ **ArchLinux:** `sudo update-ca-trust` -+ **Debian/Ubuntu, RHEL:** `sudo update-ca-certificates` - +- **ArchLinux:** `sudo update-ca-trust` +- **Debian/Ubuntu, RHEL:** `sudo update-ca-certificates` {{< admonition tip "CA Path" >}} On my system the full path to the CA certs is: - `/etc/ca-certificates/extracted/cadir/sks-keyservers.net_CA.pem` + {{< /admonition >}} Two following parameters should be added to your `~/.gnupg` configuration files: ### GnuPG Versions >2.1 - {{< admonition note "gpg.conf" >}} -``` + +```text keyserver hkps://hkps.pool.sks-keyservers.net ``` + {{< /admonition >}} - {{< admonition note "dirmngr.conf" >}} -``` + +```text hkp-cacert /etc/ca-certificates/path/to/CA.pem ``` + {{< /admonition >}} ### GnuPG Versions <2.1 + {{< admonition note "gpg.conf" >}} -``` + +```text keyserver hkps://hkps.pool.sks-keyservers.net keyserver-options ca-cert-file=/path/to/CA/sks-keyservers.netCA.pem ``` + {{< /admonition >}} ## *Optional* - Ensure keys refreshed through keyserver + To ensure no keys are pulled from insecure sources, or that an attacked would not be able to designate a keyserver they control, it is recommended to add the following additional parameter to the above `gpg.conf` file: -``` + +```text keyserver-options no-honor-keyserver-url ``` --- # More Information + The [OpenPGP Best Practices](https://riseup.net/en/security/message-security/openpgp/best-practices) page is a good resource for finding out more on best practices. A few points diff --git a/content/post/hardened_linux.md b/content/post/hardened_linux.md index add4bdc..3dd8794 100644 --- a/content/post/hardened_linux.md +++ b/content/post/hardened_linux.md @@ -20,31 +20,37 @@ enable more hardening features. By default, the `linux-hardened` kernel on Arch Linux has security leaning defaults. # Laying the Ground Work + On Arch Linux, it's as simple as: -``` + +```text # pacman -S linux-hardened linux-hardened-headers ``` -_Optionally (additionally) run `mkinitcpio -p linux-hardened` as root if -this wasn't already done automatically as part of the installation_ + +Optionally (additionally) run `mkinitcpio -p linux-hardened` as root if +this wasn't already done automatically as part of the installation The steps to boot to the hardened kernel will change based on your boot loader. Personally, I am using [`systemd-boot`](https://wiki.archlinux.org/index.php/Systemd-boot) and will therefore start with that. - ## Boot Loader Configuration + ### **`systemd-boot`** + Create a new loader config will need to be created on top of your existing one in `/boot/loader/entries/` -**Example** +#### Example Systemd-boot Entry + ```apacheconf title Arch Linux (Hardened) linux /vmlinuz-linux-hardened initrd /initramfs-linux-hardened.img options ... ``` + _The `options` line above will be specific to your system. This can be copied from existing, working loader configurations or such as the one described in [Installing Arch Linux](/post/archinstall/#set-up-linux-installation)_ @@ -53,14 +59,17 @@ Change the default **or** enable `auto-entries` to selectively boot from it in `/boot/loader/loader.conf` ### **`grub`** + For grub, it should be as simple as running `grub-mkconfig -o /boot/grub/grub.cfg` (_as root_) ### **`syslinux`** + Similar to `systemd-boot`, `syslinux` requires an additional entry in it's configuration file, found at `/boot/syslinux/syslinux.conf` -**Example** +#### Example Syslinux Config + ```apacheconf PROMPT 1 TIMEOUT 50 @@ -73,10 +82,12 @@ LABEL archhardened ... ``` + Note that the `APPEND` may differ from the example, same with `options` for `systemd-boot` # Finish Line + It's that simple! There are additional system hardening steps one may opt to take such as: @@ -90,6 +101,7 @@ On top of that, there are other tools one could leverage in addition to a hardened kernel, though that's out-of-scope for this post. One example would be something as simple as **disabling SSH password authentication** (`/etc/ssh/sshd_config`): + ```apacheconf .. PasswordAuthentication no diff --git a/content/post/headphone-fix.md b/content/post/headphone-fix.md index bd2b23e..46f53ad 100644 --- a/content/post/headphone-fix.md +++ b/content/post/headphone-fix.md @@ -13,7 +13,8 @@ with the catch being: _I had to fix them_ alt="Photo of Bern brand headphones under magnifying glass" >}} -# Don't Turn It On, Take It Apart! +# Don't Turn It On, Take It Apart + Past mistakes have taught me to be gentle and patient when it comes to taking things apart. This was no exception either. After looking over the unit on each side, I figured the only way *in* was lifting the mesh cover off. So I went at @@ -21,6 +22,7 @@ it, carefully, with a pair of tweezers. I worked my way around the edge and wedged the mesh upwards. # Okay, Maybe Turn It On + Now that the problematic speaker side was successfully opened without any damage, it was time to investigate what was wrong. @@ -41,8 +43,8 @@ problematic, speaker. The result was much different, indicating either noise or an open circuit. It may be worth mentioning that the right speaker was disconnected at this point in time to ease the troubleshooting process. +# Where Did It All Go Wrong -# Where Did It All Go Wrong? Lucky for me the PCB pads were labeled -- even better `SPKL+` (_left_) and `SPKR+` (_right_) were easy to find. @@ -70,8 +72,8 @@ bother desoldering the left speaker connections to make removal easier. So, with a bit of gentle back and forth I was able to get it the PCB out and inspect traces on the bottom side. +# Something's Not Quite Right -# Something's Not Quite Right... Continuity from `SPKL+` to the QFN pin was good, yet `SPKR+` to the op-amp showed open circuit. Visibly, everything on the PCB looked fine. There were no apparent signs of damaged or lifted traces, nor bad soldered wires or @@ -90,8 +92,8 @@ bodge wire was in order_.. {{< thumb src="/static/img/headphone-fix/IMG_7515.jpg" sub="Note the bodge wire" alt="Photo of close-up magnified view with soldered fix wire in right speaker PCB" >}} - # All's Well That Ends Well + Again, using my trusty Fluke 115, I verified continuity from the chip's `OUTR` pin to `SPKR+`. Lo and behold it was now closed-circuit! I was very happy to see the expected waveform from the known-good left channel now also appearing on the diff --git a/content/post/humble-beginnings.md b/content/post/humble-beginnings.md index a0755c1..f9f9e88 100644 --- a/content/post/humble-beginnings.md +++ b/content/post/humble-beginnings.md @@ -13,6 +13,7 @@ from WordPress) # Disclaimer + {{< admonition warning "Out of Date" >}} The information in this article is **out-of-date**. I am, and have been, using my own fork of the [hugo-even-theme](https://gitlab.com/bdebyl/hugo-theme-even) on @@ -26,8 +27,8 @@ relevant [commit](https://github.com/bdebyl/hugo-tracks-theme/commit/86ca4963c4d0a67ddb1560197c91617e7d3e3754) on my GitHub fork of the **Tracks** theme. - # Rough Start + Right off the bat I noticed the navigation bar seemed a bit off, to say the least:
![Problem Navbar](/static/img/humble-beginnings/header-problem.png)
@@ -40,7 +41,7 @@ page header. > **.Site.Sections** > -> top-level directories of the site. +> top-level directories of the site. \- [Source](https://gohugo.io/variables/site/#site-variables-list) @@ -53,8 +54,8 @@ fully understanding where the `0` and `1` "sections" even originated from. In any case, I decided the only course of action was to use something other than sections for the behavior I wanted. - # The Fix + Looking at other template files in the theme's layout, I stumbled on a chunk of code in `layouts/partials/headers.html` that defined the behavior of the aforementioned "navbar" problem: @@ -91,8 +92,8 @@ appears to be used*) to include the nav links and get my desired behavior: ``` +# But Wait, There's More -# But Wait, There's More! After getting more comfortable with how themes are written for Hugo, I found a slew of other problems with the ported **Tracks** theme: diff --git a/content/post/lineageos_pixel3a.md b/content/post/lineageos_pixel3a.md index 2b4d6f7..5fab137 100644 --- a/content/post/lineageos_pixel3a.md +++ b/content/post/lineageos_pixel3a.md @@ -22,9 +22,9 @@ with a custom recovery to utilize for this purpose! alt="Screenshot showing the LineageOS Trust feature" >}} {{< /thumbgallery >}} - # Thank You + Before going on any further, I'd like to take a moment to give my sincere thanks to InvisibleK (Dan Pasanen). Having to set up the entire custom build for Pixel 3a of LineageOS myself would add far more overhead in the overall simple task in @@ -33,6 +33,7 @@ trying to get LineageOS to work on a Pixel 3a! [**tl;dr**](#flash-custom-recovery) # Preface + There are plenty of guides out there on how to install and set up ADB and Fastboot on your host machine. For me, on Arch Linux, this was as simple as running `pacman -S android-tools`. However, should you be on MacOS or Windows @@ -43,11 +44,14 @@ Additionally, this _guide_ also assumes the reader has some familiarity with ADB and/or Fastboot. # Source Files + If you, the reader, know what you're doing and simply just require the files for your Pixel 3a they can be found here: -- https://updater.invisiblek.org/sargo + +- # Installation + {{< admonition warning "Warning!" >}} If it isn't abundantly clear by now, be aware that you **will be destroying all the data currently on your Pixel 3a** in the process of installing LineageOS on @@ -56,69 +60,88 @@ proceeding. {{< /admonition >}} ## Note about TWRP + As of writing this, TWRP[^1] (_a custom recovery commonly used in custom OS installation_) does not support Android 10. This would have been the preferred for a custom recovery, though not strictly required. Since we will be installing LineageOS 17.1 for Android 10 we cannot use TWRP. ## Flash to Stock + Google is kind enough to provide a variety of versions of the stock images for the Pixel devices. In my process of installing LineageOS, as it will be on Android 10, I made sure to flash to the latest stock version of Pixel 3a Android 10. Do note that the versions are listed in reverse order, with the latest being found in the bottom-most row. -- https://developers.google.com/android/images + +- Additionally, Google provides a helper script `flash-all` that I highly recommend running as-is to flash your Pixel 3a to stock. This can take a few minutes to complete. ## Flash Custom Recovery + Using InvisibleK's build page, you'll find the required custom recovery image for flashing found at the bottom of the list of zip files marked with a lone "download" link. Flash it via the following steps: + 1. Reboot to recovery + ```bash - $ adb reboot bootloader + adb reboot bootloader ``` + 1. Unlock the bootloader if the 'Status' is locked: + + ```bash + fastboot flashing unlock ``` - $ fastboot flashing unlock - ``` + 1. Flash the custom recovery (_make sure to replace `N` with the version you downloaded, mine was '4'_) + ```bash - $ fastboot flash boot sargo-recovery-eng-N.img + fastboot flash boot sargo-recovery-eng-N.img ``` + 1. Boot the custom recovery either by re-entering recovery mode or fastboot -- make sure to wait for it to enter Android Recovery after + ```bash - $ fastboot boot sargo-recovery-eng-N.img + fastboot boot sargo-recovery-eng-N.img ``` ## Install LineageOS + Now that the custom recovery is set up and booted into, we're ready to install LineageOS! + 1. **Important!** Once in recovery, ensure to `Wipe data/factory reset` prior to proceeding. 1. Select `Apply update from ADB` 1. ADB Sideload the version, if not latest, of LineageOS you want for your Pixel 3a + ```bash - $ adb sideload lineage-17.1-2020517-UNOFFICIAL-sargo.zip + adb sideload lineage-17.1-2020517-UNOFFICIAL-sargo.zip ``` + 1. Wait for installation to complete then select 'Reboot system now' from the recovery menu 1. **Enjoy LineageOS!** ## Verification + Once in LineageOS, you can browse the settings to verify the installation and set up Trust the preferred way. Personally, I chose to leave the defaults. # Bugs / Issues + I plan to keep this list of bugs and issues I discover up to date, but this is what I have encountered so far: + - WiFi calling does not seem to work [^1]: [Team Win Recovery Project](https://twrp.me/) diff --git a/content/post/password_checker.md b/content/post/password_checker.md index 2c8c157..bf13c75 100644 --- a/content/post/password_checker.md +++ b/content/post/password_checker.md @@ -16,6 +16,7 @@ script with the following goals: # Preface + The full **source code** for this script can be found in my public scripts repository: [scripts/bash/pass-check.sh](https://gitlab.com/bdebyl/scripts/blob/master/bash/pass-check.sh) @@ -27,6 +28,7 @@ to generate, and manage my passwords. On mobile, this is done using the official shared across my devices using Git[^2] # Pump Your Brakes + Instead of jumping right into checking all my passwords, in plain-text, against the `pwnedpasswords` API, it would be best to figure out how to safely transform them to SHA-1[^3]. The API supports sending the first 5 characters of a SHA-1 @@ -34,9 +36,11 @@ hash, returning a list of all SHA-1s of exposed passwords (_with the exposed count_) for the user to verify them on their end. # Gathering Passwords + The easiest way to get a comprehensive list (_associative array_[^4]) of passwords and their `pass` path was to use `find` to look for `*.gpg` files in my `.password-store` directory: + ```bash # Fetches all passwords in $PASSDIR and checks for duplicates (base check) getpws() @@ -52,6 +56,7 @@ getpws() done < <(find "$PASSDIR" -name "*.gpg" -type f -print0) } ``` + To note, `find` with `-print0` is used to avoid printing newline characters (_unlikely, but good practice_), so that we can utilize the null terminator `''` within `read -d ''`. Also, `read -r` simply prevents backslashes from being @@ -71,10 +76,12 @@ That takes care of gathering our passwords, but we'll revisit this again in the next part. # Sharing is not Caring + The most efficient way of checking for duplicates was simply to iterate over the array of passwords gathered, and check against the current one found in the `getpws()` function's loop. The names of the duplicate passwords are stored in _another_ associative array for printing later as part of the "report". + ```bash # Checks for duplicate sha1sums of passwords in the associative array checkdupes() @@ -88,6 +95,7 @@ checkdupes() ``` That being done, we just incorporate it into the above `getpws()` loop! + ```bash getpws() { @@ -102,6 +110,7 @@ This accomplishes our *first goal* of checking duplicate passwords -- **hooray!** # Passwortstärke + The simplest method of password strength checking, with indications as to _why_ it's weak (_i.e. "Exists in attack dictionary", "Too short", etc._) was to use [`cracklib`](https://github.com/cracklib/cracklib). Sadly, it's not the most @@ -117,6 +126,7 @@ This addition was made in the following order: 1. First, we need to find the executable **and** create _yet another_ useful associative array for us to store the outputs (_a.k.a. messages_): + ```bash CRACKLIB=$(command -v cracklib-check) declare -A pwscracklib @@ -124,6 +134,7 @@ This addition was made in the following order: 1. Then a convenient function to iterate over all found passwords, safely "expose" them, and run the check storing all **relevant** "outputs": + ```bash # Run through the global pws associative array and check for suggestions checkcracklib() @@ -140,6 +151,7 @@ This addition was made in the following order: Done! It's _that_ easy. # Have you been Pwned + The last, but **most important**, step was to add the actual check against the `pwnedpass` API check! This gets a bit fun as we use [Shell Parameter Expansion](https://www.gnu.org/software/bash/manual/html_node/Shell-Parameter-Expansion.html) @@ -152,6 +164,7 @@ exposed (_"pwned"_) password's SHA-1 hash, and the amount of times they have been leaked as a response. The prefix of the first 5 characters is dropped in this list, thus we check for a match of our password using everything after the first 5 characters of the SHA-1 hash and we're done! + ```bash # Check passwords against the HIBP password API (requires internet) checkpwnapi() diff --git a/content/post/stm32-part0.md b/content/post/stm32-part0.md index 196edb0..02c4139 100644 --- a/content/post/stm32-part0.md +++ b/content/post/stm32-part0.md @@ -30,6 +30,7 @@ For those that want to cut to the chase and save time, here is the full source code with friendly names to get you started: {{< admonition note "Source Code" true >}} + ```C #include #include @@ -47,9 +48,11 @@ int main(void) { while (1); } ``` + {{< /admonition >}} # Getting Started with libopencm3 + [libopencm3](https://github.com/libopencm3/libopencm3) is a very powerful, useful, open-source firmware library for use in writing programs for various different ARM Cortex-M microcontrollers. It's read me contains plenty of @@ -60,8 +63,8 @@ Additionally, there is a [libopencm3-template](https://github.com/libopencm3/libopencm3-template) repository to help in getting started. - ## Dependencies + Prior to doing any ARM Cortex-M development, the necessary dependencies need to be installed in order to successfully build/compile source code into a binary capable of being flashed (written) onto the microcontroller: @@ -74,6 +77,7 @@ capable of being flashed (written) onto the microcontroller: - **Text Editor or IDE**: Anything, _really_. ## Flashing the STM32F0 Discovery Board + The discovery series boards provided by ST come with an on-board [ST-LINK/V2](https://www.st.com/en/development-tools/st-link-v2.html) programmer. There are several ways to flash your build programs using this, @@ -86,6 +90,7 @@ not be overlooked for too long! For the sake of brevity, this guide will omit diving into that until later. ## Makefile + The aforementioned `libopencm3-examples` repository provides a useful, yet overly complex, Makefile. For the reader, this has been boiled down (_assuming they are also using `stlink` mentioned above_) the following, simple Makefile[^2] on @@ -95,6 +100,7 @@ To flash, it's as simple as `make flash` (_will also build the binary for your convenience_). ## Linker Script + The loader (`.ld`) file is specific to the _flavor_ of ARM Cortex-M microcontroller being used. The authors of `libopencm3` provide example loader files that can be used for most projects (_e.g. located in @@ -104,12 +110,13 @@ for proper use. There are several articles online that go into detail about linker scripts ## Project Structure + The Makefile, as of writing this, assumes your project directory structure has `libopencm3` either cloned, copied, or initialized as a git submodule within the same directory of your `main.c`. It is advised that you look through the Makefile's variables of things you may want to change: -``` +```text . ├── libopencm3 ├── main.c @@ -139,16 +146,19 @@ The Discovery board comes with two LEDs for use by the user, tied to Port C pins 8 (blue LED), and 9 (green LED). ## Reset and Clock Control (RCC) + The **RCC**, and it's registers, are an important part in _using_ the STM32 microcontroller's peripherals. Luckily, utilizing `libopencm3` we can forego bit-banging our way through each register's bits found in the reference manual[^5] and simply utilize the GPIO port that we need -- in this case `GPIOC`: + ```C rcc_periph_clock_enable(RCC_GPIOC); ``` ## GPIO Setup + Next, we need to define what mode we want the GPIO pins on their respective port to be along with the internal pull-up or pull-down resistor mode: @@ -169,20 +179,22 @@ to be along with the internal pull-up or pull-down resistor mode: authors, along with the function definition can be found [**here**](https://libopencm3.org/docs/latest/html/) - Having clarified that, as we want to **drive** the LEDs, we will need to configure the pins as outputs with no internal pull-up or pull-down resistor: + ```C gpio_mode_setup(GPIOC, GPIO_MODE_OUTPUT, GPIO_PUPD_NONE, GPIO8); gpio_mode_setup(GPIOC, GPIO_MODE_OUTPUT, GPIO_PUPD_NONE, GPIO9); ``` _Simplified using bitwise[^6] OR:_ + ```C gpio_mode_setup(GPIOC, GPIO_MODE_OUTPUT, GPIO_PUPD_NONE, GPIO8 | GPIO9); ``` ## GPIO Output Options Setup + Now that the GPIO mode has been set up, the GPIO output options need to be defined as well. This will encompass the output type, and output speed: @@ -216,11 +228,13 @@ gpio_set_output_options(GPIOC, GPIO_OTYPE_PP, GPIO_OSPEED_LOW, GPIO9); ``` _Simplified[^6]:_ + ```C gpio_set_output_options(GPIOC, GPIO_OTYPE_PP, GPIO_OSPEED_LOW, GPIO8 | GPIO9); ``` -## Turn it on! +## Turn it On + There are no additional options required for the user to be able to now set, or clear, the desired GPIO pins. Thus, we set it _and forget it_: @@ -230,12 +244,14 @@ gpio_set(GPIOC, GPIO9); ``` _Simplified[^6]:_ + ```C gpio_set(GPIOC, GPIO8 | GPIO9); ``` Lastly, we need to make sure our program never **exits** and does something _undesirable_ by keeping it inside a loop: + ```C while(1); ``` @@ -256,7 +272,7 @@ Explained](http://www.learningaboutelectronics.com/Articles/While-(1)-embedded-C [^1]: [GNU Arm Embedded Toolchain](https://developer.arm.com/tools-and-software/open-source-software/developer-tools/gnu-toolchain/gnu-rm) [^2]: [Makefile](https://gitlab.com/bdebyl/stm32f0-example-project/blob/b858d5e38026bcce3b8aad4085ffb665ddf63eef/Makefile) as of writing this post -[^3]: https://gitlab.com/bdebyl +[^3]: [^4]: [STM32F0 Discovery User Manual](https://www.st.com/content/ccc/resource/technical/document/user_manual/30/ae/6e/54/d3/b6/46/17/DM00050135.pdf/files/DM00050135.pdf/jcr:content/translations/en.DM00050135.pdf) [^5]: [STM32F0 Reference Manual](https://www.st.com/content/ccc/resource/technical/document/reference_manual/c2/f8/8a/f2/18/e6/43/96/DM00031936.pdf/files/DM00031936.pdf/jcr:content/translations/en.DM00031936.pdf) [^6]: [Bitwise Operators in C](https://en.wikipedia.org/wiki/Bitwise_operations_in_C) diff --git a/content/post/stm32-part1.md b/content/post/stm32-part1.md index 0a54d87..be9ca5c 100644 --- a/content/post/stm32-part1.md +++ b/content/post/stm32-part1.md @@ -26,6 +26,7 @@ For those that want to cut to the chase and save time, here is the full source code with friendly names to get you started: {{< admonition note "Source Code" true >}} + ```C #include #include @@ -76,20 +77,23 @@ int main(void) { return 0; } ``` + {{< /admonition >}} - # Set up the GPIO + Assuming the reader is either familiar with GPIO setup for the STM32F0, or has reviewed [**Part 0**](/post/stm32-part0) of this series we will set up the GPIO pins tied to the LEDs (_port C, pins 8 and 9_) in the Alternate Function mode. Knowing that we'll be using `GPIOC`, we should enable this peripheral: + ```C rcc_periph_clock_enable(RCC_GPIOC); ``` ## Alternate Functions + The STM32 microcontroller's GPIO has a hardware feature allowing you to tie certain port's pins to a different register as part of the output or input control: @@ -107,8 +111,8 @@ Review the datasheet for the specific **STM32Fx** microcontroller being programmed, as the Alternate Function mappings may be *significantly* different! {{< /admonition >}} - ## GPIO Alternate Function Setup + For the STM32F0 we are using in this series, the Alternate Function selection number desired is `GPIO_AF0` for use with `TIM3_CH3` (_timer 3, channel 3_) and `TIM3_CH4` (_timer 3, channel 4_): @@ -116,8 +120,8 @@ number desired is `GPIO_AF0` for use with `TIM3_CH3` (_timer 3, channel 3_) and sub="STM32F051 Alternate Function Mapping" alt="Screenshot of alternate function pin definition table for STM32F0" >}} - Ultimately, the code with `libopencm3` becomes the following for our use case: + ```C gpio_mode_setup(GPIOC, GPIO_MODE_AF, GPIO_PUPD_NONE, GPIO8 | GPIO9); gpio_set_output_options(GPIOC, GPIO_OTYPE_PP, GPIO_OSPEED_HIGH, GPIO8 | GPIO9); @@ -125,16 +129,19 @@ gpio_set_af(GPIOC, GPIO_AF0, GPIO8 | GPIO9); ``` # Set up the General Purpose Timer + From the previous section we chose the two on-board LEDs on the STM32F0 Discovery board tied to `PC8` and `PC9`. From the Alternate Function GPIO mapping, we know these will be Timer 3 (_channels 3, and 4_). Knowing that we'll be using `TIM3`, we should enable this peripheral: + ```C rcc_periph_clock_enable(RCC_TIM3); ``` ## Timer Mode + The first step in setting up the timer, similar to GPIO, is setting the timer mode. The encompass the divider amount (_dividing the peripheral clock_), alignment for capture/compare, and up or down counting: @@ -165,6 +172,7 @@ timer_set_mode(TIM3, TIM_CR1_CKD_CK_INT, TIM_CR1_CMS_EDGE, TIM_CR1_DIR_UP); ``` ## Timer Prescaler + In addition to the timer clock, set by the peripheral clock (internal), each timer has a perscaler value. This determines the counter clock frequency and is equal to `Frequency/(Prescaler + 1)`. This is the value the timer will count to prior @@ -175,6 +183,7 @@ integer value_). For the sake of simplicity in dividing the clock into easy decimal values, we will utilize setting up the High Speed Internal clock to 48MHz and dividing by 48,000: + ```C rcc_clock_setup_in_hsi_out_48mhz(); // Place at the beginning of your int 'main(void)' ... @@ -184,18 +193,20 @@ timer_set_prescaler(TIM3, (rcc_apb1_frequency/48000)/2*SECONDS)); ``` ## Timer Period + Having set the prescaler to determine the maximum count of the timer, there is an additional period we need to set. For our purposes, this will simply be the same value of the prescaler: + ```C timer_set_period(TIM3, 48000); ``` ## Timer Additional Configuration -There are two minor settings we want to configure for the timer: -
[^1]
-1. Disable preloading the ARR1 (auto-reload register) when the timer is reset +There are two minor settings we want to configure for the timer: + +1. Disable preloading the ARR[^1] (auto-reload register) when the timer is reset 1. Run the timer in continuous mode (never stop counting, clear the status register automatically) @@ -205,6 +216,7 @@ timer_continuous_mode(TIM3); ``` ## Timer Channel Output Compare Mode + Since we are utilizing Timer 3's channel 3 (`GPIOC8`), and channel 4 (`GPIOC9`) we need to determine the output compare mode we want to use for each channel. By default the mode for each channel is frozen (unaffected by the comparison of the @@ -232,6 +244,7 @@ timer_set_oc_mode(TIM3, TIM_OC4, TIM_OCM_PWM2); In layman's terms: _only one LED will be on at a time, alternating._ ## Timer Channel Output Compare Value + Lastly, we need to set the values that the output compare looks to for it's comparison. For this example, we want a 50%-on/50%-off time for ease of timing the duration of LEDs on-time determined by the frequency and period of the @@ -244,6 +257,7 @@ timer_set_oc_value(TIM3, TIM_OC4, 24000); ``` ### Exercise for the Reader + A fun exercise in C to reduce repetition would be by creating an array of timer output compare address values and looping through them to set them to the same value. @@ -254,6 +268,7 @@ microcontroller. That being said, there is still some fun to have. The following snippet will be provided as a note and exercise for the reader in exploring memory allocation and garbage collection: + ```C int tim_oc_ids[2] = { TIM_OC3, TIM_OC4 }; @@ -261,10 +276,12 @@ for (i = 0; i < (sizeof(tim_oc_ids)/sizeof(tim_oc_ids[0])); ++i) { timer_set_oc_value(TIM3, tim_oc_ids[i], 24000); } ``` +
_Determining the 'length' of an array in C is different than in other languages.[^2]_
## Enable the Timer + Lastly, to kick everything off we need to enable both the timer and the relevant output-compare outputs. @@ -277,6 +294,7 @@ timer_enable_counter(TIM3); ``` ### Another Exercise for the Reader + The same for loop for `timer_set_oc_value()` can be appended to for `timer_enable_oc_output()` as discussed previously: @@ -290,8 +308,10 @@ for (i = 0; i < (sizeof(tim_oc_ids)/sizeof(tim_oc_ids[0])); ++i) { ``` # Fin + Lastly, as always, we should not forget to place the microcontroller in an infinite loop: + ```C while (1); ``` diff --git a/content/post/thinkpad_usb_fix.md b/content/post/thinkpad_usb_fix.md index 3df3447..8cd0eb4 100644 --- a/content/post/thinkpad_usb_fix.md +++ b/content/post/thinkpad_usb_fix.md @@ -17,6 +17,7 @@ to say this required fixing. # Damage Assessment + The first step was to look at the PCB to assess how this could be, if at all, replaced. From the outside you could see the damage done. Note the single pin left and lack of the inner pad (_bolster?_). @@ -25,8 +26,8 @@ pin left and lack of the inner pad (_bolster?_). sub="One pin remains" alt="Photo showing one pin remaining on a damaged USB receptacle ">}} - # Measure Twice + Next on the list: measurements. To find a suitable replacement receptacle, I needed to have the relevant dimensions in comparing to receptacle part drawings of those available for sale. @@ -50,13 +51,14 @@ Using generic, non-branded digital calipers I was able to get the following | Pad Width | _1.9mm_ |
Fig. 1
- # Shopping with Purpose + Using the value above, I was able to track down a USB receptacle[^1] on Digi-Key[^2] that matched my requirements very, _very_ closely. ## Resounding Comparison + Keep in mind the measured values were an eyeball approximation with a low cost, unbranded digital caliper. Those values are nearly spot-on. @@ -76,6 +78,7 @@ other the two receptacles matched up just as I had hoped.. **Fantastic!** alt="Photo showing new USB receptacle on top of damaged one for comparison" >}} # It's not over yet + Initial attempts at desoldering the existing (_broken_) receptacle proved futile. Even with liberal application of flux, high soldering iron temperatures well beyond typical soldering temperatures[^3], the solder would not flow and @@ -92,6 +95,7 @@ having spent about half an hour on it with tweezers, solder wick, a solder sucker (_desoldering pump_), and flush cutters, I gave up. # Throwing in the Towel + It turned out the only way to attach the replacement was to modify the new part to fit -- _luckily I had ordered two replacements as I broke the first one in the modification "process"_. Cutting and bending the pins, I was able to get it @@ -108,6 +112,7 @@ been able to bend the flat pads towards the entry of the receptacle down to attempt to solder them to the surface mount pads. # All the King's horses, all the King's men + Alas, it was time to put the laptop back together. To my dismay there were further problems. Due to the modification and forced fitment of the replacement, the USB receptacle was sticking out too far off of the PCB preventing the diff --git a/content/post/updating_gpg_key.md b/content/post/updating_gpg_key.md index 574a0b8..297e1e8 100644 --- a/content/post/updating_gpg_key.md +++ b/content/post/updating_gpg_key.md @@ -19,18 +19,22 @@ write-up on this blog: [**OpenPGP Best Practices (and Git)**](/post/gpg_best_pra {{< /admonition >}} # Importing Secret Keys + Personally, my secret (primary) key is not kept on any device. It's stored, and backed up in encrypted external media devices (_USB, etc._) only to be imported when keys require editing. ## Mounting Secure Device (LUKS) + This is done using `cryptsetup` and Linux Unified Key Setup[^1] (LUKS) for encryption. Plugging in my USB device and mounting it requires only _one_ additional step. Instead of initially running `mount /dev/sdXN` we first must "open" the encrypted drive via: + ```bash cryptsetup --type luks open /dev/sdXN encryptedusb ``` + {{< sub >}} The `encryptedusb` name is a user-specified friendly name that has no relevance to accessing the drive @@ -39,47 +43,58 @@ no relevance to accessing the drive **Now** the device can be mounted to a directory, but not via the `/dev/sdXN` device -- rather the `/dev/mapper/encryptedusb` device (_or whatever friendly name you gave it_). + ```bash mount /dev/mapper/encryptedusb /mnt/media ``` ## Backing up the Keys + Once the device has been securely mounted, it's a good idea to either export the keys currently in the keyring **or** back-up the entire `~/.gnupg` directory. The backup created will be stored on the previously mounted external media device. ### GPG Key Export Backup + It's as simple as exporting the secret key, which will also contain your public key: + ```bash gpg --armor --export-secret-key your@email.address > /mnt/media/some/dir/secretkey.gpg.bak ``` ### GPG Directory Backup (optional) + This isn't entirely necessary, though it's never a bad idea to create a hard back-up of the directory -- _just don't forget to remove it after!_ + ```bash cp ~/.gnupg /mnt/media/some/backup/dir/.gnupg.bak ``` + {{< sub >}} Note: If the `~/.gnupg.bak` directory already exists, the above command will copy it to `~/gnupg.bak/.gnupg`! {{< /sub >}} ## Import and Update Expiration + Now that back-ups have been taken care of, the current keyring can either be emptied, deleted, or simply worked with. That's up to the user. ### Import + In any event, the next step ultimately becomes importing the secret (primary) key: + ```bash gpg --import /mnt/media/some/backup/dir/secretprimarykey.gpg ``` Verify the presence of the primary secret key, noting no presence of `sec#` in the output indicating only a partially stripped secret key, via: + ```bash gpg --list-secret-keys @@ -89,9 +104,11 @@ sec rsa4096 2017-11-21 [SC] [expires: 2021-02-16] ``` ### Update + Updating the primary secret key and all it's sub keys is done via `gpg` in the following manner: -``` + +```text gpg --edit-key your@email.address gpg> key 0 @@ -114,6 +131,7 @@ gpg> save ``` At this point, it's a good idea to send the key to the key server: + ```bash gpg --send-keys your@email.address # or @@ -121,8 +139,10 @@ gpg --keyserver pgp.mit.edu --send-keys your@email.address ``` ## Cleanup + Now it's time to export the primary key and it's sub keys to the encrypted external media device: + ```bash gpg --armor --export-secret-key your@email.address > /mnt/media/some/dir/secretkey.gpg gpg --armor --export-secret-subkeys your@email.address > /mnt/media/some/dir/secretsubkey.gpg @@ -130,6 +150,7 @@ gpg --armor --export-secret-subkeys your@email.address > /mnt/media/some/dir/sec Then, delete the primary secret key from your keyring and import **only** the secret sub-key: + ```bash gpg --delete-secret-keys your@email.address # reply 'yes' to the prompts as needed @@ -138,29 +159,33 @@ gpg --import /mnt/media/some/dir/secretsubkey.gpg ``` ### Verification + Once **only** the secret sub-key has been imported from the previous step, it should be verified that the primary secret key is **not** in your keyring (partial stripped key designated via `sec#` in the following): -``` + +```text gpg --list-secret-keys -------------------------------- sec# rsa4096 2017-11-21 [SC] [expires: 2021-02-16] ... ``` + {{< sub >}} Note: `sec#` is what we are looking for. If it is indicated as only `sec` then the primary secret key is **still** in the keyring! Repeat the prior steps to attempt this again should you have to, but do so carefully. {{< /sub >}} - ## Unmounting + Lastly, remember to remove any local back-ups of the keyring or keys you stored on the host! These should _only_ exist on the encrypted external device. To un-mount the LUKS[^1] encrypted device, it's just one additional step to the usual `umount`: + ```bash umount /mnt/media cryptsetup --type luks close encryptedusb @@ -169,13 +194,16 @@ cryptsetup --type luks close encryptedusb That being done, it is safe to remove the external device! # OpenKeychain Export & Import + Provided the reader is on an Android device, it can be mounted onto the local host using `simple-mtpfs`. ## Mounting Android Device + First, plug in the Android device via a suitable USB cable to the local host and set the USB managed option to "File Transfer" on the Android device. After this the device should be mountable: + ```bash simple-mtpfs -l 1: Google IncNexus/Pixel (MTP) @@ -184,10 +212,12 @@ simple-mtpfs --device 1 /mnt/android ``` ## Export Secret Key + Once the device is mounted, we want to export the _partially_ stripped key (_not the primary key_) to be imported using OpenKeychain on the Android device. The next steps quote from the [OpenKeychain FAQ](https://www.openkeychain.org/faq/#how-to-import-an-openkeychain-backup-with-gpg): + ```bash # generate a strong random password gpg --armor --gen-random 1 20 @@ -199,5 +229,4 @@ gpg --armor --export-secret-keys YOUREMAILADDRESS | gpg --armor --symmetric --ou Import it in OpenKeychain (_may require deletion in OpenKeychain first -- make sure **not to revoke and delete!**_) and we're done! - [^1]: https://guardianproject.info/archive/luks/