I am trying to build a more complex template based site for another project, to transform the GitHub Wiki pages to a more fancy layout.
The idea is to let the technicians write markdown content and put the layout to the system.
I agree, static pages are the way to go.
Thank you for the suggestion to use GHPages.
Iāve started the process of putting a framework out there. As this is not an area Iām particularly familiar with, Iād love to hear your thoughts.
If I understand the things Iāve setup:
main branch/docs/_posts, following the specific naming convention for dates specified, and they will show up anywhere I have that little snippet that loops through categories.Are there any gotchaās I should be aware of? I imagine folks whoāve been using this for a while may have a list of tips, tricks, and best practices.
If you can help me by sharing those, I will appreciate you even more! 
I am mostly annoyed by the fact GitHub is using another (modified, not really known) version of the layout files. So it is a little hard to develop local and push online. You will get headache while working with tables. My workaround is embedded html instead of markdown.
First you create a repo at http://github.com/username with the name `username.github.io`, which is available at the same direct domain. But It can be redirected to a known CNAME, for a more professional look.
As I see you are already over this steps.
I have a Debian VM with a clone of my repo. I am using a local jekyll build to test changes with a nginx virtual directory ā¦ as said before, it looks a little different, but close enough.
Instead of copying every layout from file to file, make sure the layout is stored in one file. Like Layouts | Jekyll ā¢ Simple, blog-aware, static sites
I like your theme. Nice terminal style.
As I see above, your text is, for a good reason, very spoiler rich. As I have not written them in Markdown so far, I was curious. And as the tables, the solution is also embedded html:
https://stackoverflow.com/questions/32814161/how-to-make-spoiler-text-in-github-wiki-pages
<details>
<summary>SPOILERS - Second stage skills</summary>
The second stage is actually almost trivial, once you understand how the āECBā mode of AES works:
- Each 0x10-byte block is independently encrypted / decrypted.
- Only the last block is required to have the PKCS7 padding.</details>
- [...]
</details>
The auto convert works, as I see at your page. But I think I prefer the local jekyll build way.
One of the best features is to write in markdown at any terminal, and still get the complete layout.
See Layouts | Jekyll ā¢ Simple, blog-aware, static sites for the layout format and how to include header/footer.
Plus the static files, for example an āaboutā which differs from the ā_postā pages. See Directory Structure | Jekyll ā¢ Simple, blog-aware, static sites
One issue I hit was that including embedded HTML in markdown can prevent the text in those elements from being converted to HTML.
## Section Title
<details><summary>Section Title</summary><P/>
This should be a list, but is not:
* Foo
* Bar
* Baz
</details>
I actually am disappointed by that, since I have used those extensively in my write-ups. My āhow to use SPIā post originally used those for each section ā¦ but I had to quickly commit an edit to remove all those collapsible sections.
Thatās painful, because I really want folks to be able to browse without seeing the actual spoiler text, but I donāt want to have to reformat everything to HTML.
Sighā¦
Ask Claude? Itās surprising good at that kind of thing, and you can do winmerge or whatever to make sure the text hasnāt been mangled.
I see. I will take a look, but I canāt test it before tomorrow.
I hoped the more complex solution 2 in the linked article would help. But I have not tested it myself. And as said before, sometimes the GitHub pages are a little quirky.
But in general, they are developing and react to feedback.
Hereās a test page that shows how it just munges everything in a markdown file that uses <details>. I even tried various options to put stuff into <P>, <DIV>, or none of the above. Every option so far has resulted in the details being put as unmodified text ā¦ no markdown ā html conversion.
Iāll ask Claude next, but Iām starting to think Iāll be forced to transition from markdown to full HTML. 
Well ā¦ Claude found the correct cause and fix:
The issue is Kramdown (Jekyllās default Markdown parser) doesnāt process Markdown inside block-level HTML elements by default. The fix is the
markdown="1"attribute on the<details>tag, which tells Kramdown to process the inner content as Markdown.
This will be a huge help in reducing spoiler fatigue.
Woo-hoo! The collapsible sections are confirmed working now. Iām ready to start pushing more content. Thank you for the help!
Haha! Glad it worked out. I just meant to have Claude do all the reformatting but I guess this is one better!
Four posts are now live, now including stage 2. Enjoy the read!
The source code link under āWhile you waitā¦ā returns a 404 error.
https://github.com/gili-yankovitch/SwordOfSecrets/src
fixed, thanks!
words words
# Sample workflow for building and deploying a Hugo site to GitHub Pages
name: Deploy Hugo site to Pages
on:
# Runs on pushes targeting the default branch
push:
branches: ["main"]
# Allows you to run this workflow manually from the Actions tab
workflow_dispatch:
# Sets permissions of the GITHUB_TOKEN to allow deployment to GitHub Pages
permissions:
contents: read
pages: write
id-token: write
# Allow only one concurrent deployment, skipping runs queued between the run in-progress and latest queued.
# However, do NOT cancel in-progress runs as we want to allow these production deployments to complete.
concurrency:
group: "pages"
cancel-in-progress: false
# Default to bash
defaults:
run:
shell: bash
jobs:
# Build job
build:
runs-on: ubuntu-latest
env:
HUGO_VERSION: 0.124.1
steps:
- name: Install Hugo CLI
run: |
wget -O ${{ runner.temp }}/hugo.deb https://github.com/gohugoio/hugo/releases/download/v${HUGO_VERSION}/hugo_extended_${HUGO_VERSION}_linux-amd64.deb \
&& sudo dpkg -i ${{ runner.temp }}/hugo.deb
- name: Install Dart Sass
run: sudo snap install dart-sass
- name: Checkout
uses: actions/checkout@v4
with:
submodules: recursive
- name: Setup Pages
id: pages
uses: actions/configure-pages@v5
- name: Install Node.js
uses: actions/setup-node@v3
with:
node-version: '16'
- name: Install Node.js dependencies
run: |
npm install -g postcss postcss-cli autoprefixer
[[ -f package-lock.json || -f npm-shrinkwrap.json ]] && npm ci || npm install
- name: Build with Hugo
env:
HUGO_ENVIRONMENT: production
HUGO_ENV: production
run: |
hugo \
--minify \
--baseURL "${{ steps.pages.outputs.base_url }}/"
- name: List files in public directory before rename
run: ls -l public/
- name: Rename offline search index
run: |
for file in public/offline-search-index*.json; do
mv -f "$file" public/offline-search-index.json
break # This ensures only the first matching file is copied
done
- name: Upload artifact
uses: actions/upload-pages-artifact@v3
with:
path: ./public
# Deployment job
deploy:
environment:
name: github-pages
url: ${{ steps.deployment.outputs.page_url }}
runs-on: ubuntu-latest
needs: build
steps:
- name: Deploy to GitHub Pages
id: deployment
uses: actions/deploy-pages@v4
```
Iāve added posts up to the initial evaluation of stage3, and Iāve published my (sos_helper)[GitHub - henrygab/sos_helper Ā· GitHub] python-based sword of secrets helper. Made it SO much easier to interact with the sword, even by just having up arrow / down arrow history. Of course, also adds programmatic access.
Hope to post the remaining bit about Stage 3 this weekendā¦
ā¦ and stage 3 review, hints, and walkthrough are now out, as is the module for sos_helper.
The sos_helper library has grown into an indispensible tool, wrapping the SPI functionality into easily used commands (and python functions).
I put up stage 4 last week or so, and I started thinking about just how deep I wanted to break into this device.
Things I could still write about (done already):
The author of this kickstarter campaign said I could write whatever I wanted, but I feel like publishing either of those two AES keys would be ā¦ in poor taste.
What do you folks think?
Given the authorās explicit āOKā, should I include the AES keys directly in my library and/or posts?
In my opinion, it would be poor taste to include the AES keys directly. If users want them, they can follow the information you write to extract them themselves (and get the sense of accomplishment from actually doing something directly instead of just downloading the defeated end boss).
Maybe include a hash of the key (yeah, I know how that soundsā¦), but it would be a way for a person to verify theyāve correctly retrieved the key.
Edits: sheesh, 2 edits to convince my phone not to autocorrect āretrievedā
For the challenge key, anyone doing the CTF would already have the data to verify the key (all the challenges used that key for encryption/decryption). While the firmware decryption key could be heuristically determined, a hash there sounds good. I could probably also include hashes of the firmware and the bootloader. 
Thank you, Matt!