diff --git a/Makefile b/Makefile index ebfc266..3d96d8d 100644 --- a/Makefile +++ b/Makefile @@ -29,6 +29,9 @@ run: new: $(DOCKER_RUN) ${DOCKER_IMAGE} new post/$(shell read -p "Post Name (i.e. my_post.md): " pn; echo $$pn) +thumbnails: + @./make-thumbs.sh + clean: @# Clean up existing generated site rm -rf public/ resources/ diff --git a/content/post/aperture-study.md b/content/post/aperture-study.md index e52bb76..0c1d76a 100644 --- a/content/post/aperture-study.md +++ b/content/post/aperture-study.md @@ -35,21 +35,22 @@ 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. {{< thumb "/img/aperture-study/f17-f40-comp.jpg" >}} -## *f/1.7*--*f/2.8* --- + +## *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 {{< thumb "/img/aperture-study/f17-f28-comp.jpg" >}} -## *f/2.8*--*f/4.0* --- + +## *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 @@ -57,9 +58,9 @@ finding the best middle-ground between maximum aperture and image quality. {{< thumb "/img/aperture-study/f28-f40-comp.jpg" >}} +--- # Individual Photos ---- Below is the entire collection of all the photos taken of the subject at increasing aperture steps. diff --git a/content/post/gpg_best_practices_and_git.md b/content/post/gpg_best_practices_and_git.md index 98e822f..ce67b81 100644 --- a/content/post/gpg_best_practices_and_git.md +++ b/content/post/gpg_best_practices_and_git.md @@ -1,18 +1,15 @@ --- title: "GPG Best Practices (and Git)" date: 2019-02-17 -lastmod: 2019-02-17 +lastmod: 2019-02-18 categories: ["Blog"] tags: ["linux"] --- I decided to start signing my Git commits for personal, and work Git -repositories. Currently, most Git third-party services only support signing -commits, but _do not_ support signing pushes. Regardless, it would still be -considered good Currently, most Git third-party services only support **signing -commits**, but _do not_ support signing pushes. Regardless, it would still be -considered good practice to start signing commits. practice to start signing -commits. +repositories. Currently, most third-party Git repository hosts only support +signing commits, but **do not** support signing pushes. + That being said, I've added my public key to my [GitLab](https://gitlab.com/bdebyl), and set the global config to use my key, and sign all of my commits: @@ -24,10 +21,10 @@ _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) on the official -GnuPG website. However, I would **strongly** recommend using the `--full-gen-key` -option in place of the `--gen-key`. This will allow you to specify additional -details about your key, such as using a 4096-bit RSA key. +[Getting Started](https://www.gnupg.org/gph/en/manual/c14.html) page on the +official GnuPG website. However, I would **strongly** recommend using the +`--full-gen-key` option in place of the `--gen-key`. This will allow you to +specify additional details about your key, such as using a 4096-bit RSA key. # OpenPGP Keyserver Pool In addition to that, there came the addition of using the @@ -65,33 +62,35 @@ Once the signature has been verified, the CA can be moved over to `/usr/share/ca-certificates` to add to your CA certificates via `sudo update-ca-trust` (_Arch_) or `sudo update-ca-certificates` (_Debian/Ubuntu_). -### GnuPG Versions >2.1 -Two following parameters should be added to your `~/.gnupg` configs: - -#### `gpg.conf`: -```apacheconf -keyserver hkps://hkps.pool.sks-keyservers.net -``` - -#### `dirmngr.conf`: -```apacheconf -hkp-cacert /etc/ca-certificates/path/to/CA.pem -``` - - -### GnuPG Versions <2.1 -#### `gpg.conf`: -```apacheconf -keyserver hkps://hkps.pool.sks-keyservers.net -keyserver-options ca-cert-file=/path/to/CA/sks-keyservers.netCA.pem -``` - {{% 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" %}} +```apacheconf +keyserver hkps://hkps.pool.sks-keyservers.net +``` +{{% /admonition %}} + +{{% admonition note "dirmngr.conf" %}} +```apacheconf +hkp-cacert /etc/ca-certificates/path/to/CA.pem +``` +{{% /admonition %}} + +### GnuPG Versions <2.1 +{{% admonition note "gpg.conf" %}} +```apacheconf +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 diff --git a/make-thumbs.sh b/make-thumbs.sh new file mode 100755 index 0000000..b328016 --- /dev/null +++ b/make-thumbs.sh @@ -0,0 +1,26 @@ +#!/bin/bash +CONVERT=$(command -v convert) +if [ ! $CONVERT ]; then + echo "ERROR: imagemagick must be installed!" + exit 1 +fi + +for i in $(find static/img/*/ -type f -not -path "*thumb*"); do + THUMB_PATH=$(dirname $i)/thumb + IMG_NAME=$(basename $i) + + # Generate a thumbnail if the width is greater than 600px + if [ $(identify -format "%w" $i) -gt 600 ]; then + # Create the thumbnail directory fo the image to be made + if [ ! -d $THUMB_PATH ]; then + echo "Creating directory $THUMB_PATH..." + mkdir -p $THUMB_PATH + fi + + # Create the thumbnail image + if [ ! -f $THUMB_PATH/$IMG_NAME ]; then + echo "Converting $IMG_NAME to thumbnail..." + $CONVERT -resize 600x $i $THUMB_PATH/$IMG_NAME; + fi + fi +done