add soft blog entries 004 through 006.

soft/004-a-preface.md

@@ -0,0 +1,22 @@
+# a preface
+
+before entering into the details of building a secure foundation for one's
+digital self, a caveat and a suggestion:
+
+1) security is not a "set it and forget it" affair.  it is active and constantly
+   changing.  assumptions turn out to be wrong.  people make mistakes, even if
+   they have good training.  expect to make mistakes.  have plans in place for
+   when (not if) that happens.  at the very least, make sure you have tools in
+   place to notify you when your perimeter, whatever it may be, is breached.  my
+   focus in the next few entries will be on strengthening the perimeter around
+   one's keys, but know that no perimeter is unbreachable.  the goal is always
+   to make breaching the perimeter so expensive or difficult that it doesn't
+   justify the payoff.
+
+2) one might consider taking up an art form as a way to believably produce
+   original cover messages.  (being a meme lord _does_ count.  the "seriousness"
+   of one's art form is irrelevant, for our purposes.)  art can always be as
+   "noisy" as one likes, and an artist may always have their own reasons for
+   creating an artwork one way or another.  having a hobbyist's level of
+   knowledge of electronics may also be very beneficial, as bespoke electronics
+   are unlikely to have well-known noise signatures.

soft/004-a-preface.md.asc

@@ -0,0 +1,16 @@
+-----BEGIN PGP SIGNATURE-----
+
+iQIzBAABCAAdFiEE0ZVR9dPnC9rIvgC+tQHDCzf0gGwFAl++vEQACgkQtQHDCzf0
+gGyvhg//YMt4F0RVzFgelnLc3d2+ePXx6wD5+jA9Y1jUf3blcnk4SYHPmbQ8PVrY
+YsSjQ/NhyxlTiNXEboGiMhgNTEwk7LK5jA+ASsIlYUwju/33v+pvNl8cLMrcj8+b
+LGZGMte4f1ZK9SD6A/pmQU4F9QFaJ0j/ijQi5CPF2IRGnXEzu7bz0LmKR0X1nl4G
+Gyrk2uixv8tQ91LxaPzQRWdbWvQ7eaZmHtX4ENHDamnn6SmSCEYtlxPish/IdirI
+htCQ5+e+DUWqVn2SWoIhXFnbXFM5BrLAXCkVEk0IKhzBs35qeGYZQ6ReKx0UYs2O
+WSrBG+0Ua4Wmio00WSOMkd9WyhbopcgsFf2V3Py+iii+MnZN8FK5UbCScRdo4IW0
+BYt/4W4CIrAQnLj5mKIEXKjt49qmZIwnlJhqgrs8G8WfFZGLCOoVorLZJPwl+9FQ
+Smhl12fKlSs8aGgeQHHSe5GYVVF+G5zJ2oqYopdtZDZWxuDKnWT+rxXT9AF0+2cl
+WUxzXTeM07eYZpLk4zDhmRlqmUSKMxMJGP981BMev6QyUIh1HMkE6o3A9Xj5SRF/
+heeGn1ArKxQFNt+iviuF6po1U2xBwHpVzonRWyNDBGAsDpGynp2dn5dtLKp5UqjU
+o/mgagW2VvoXK0dmFYoDGnVja8ouAC14NQNlvukg5/7GyLtJTqQ=
+=EID+
+-----END PGP SIGNATURE-----

soft/005-stack-zero.md

@@ -0,0 +1,101 @@
+# stack zero
+
+i will share first the components of my stack and what each is for, and then
+some things i would like to improve in the not-so-distant future.  this is a
+bootstrapping stack; it is not perfect, but it does seem to be more supportive
+of end user control and security than most technology stacks.
+
+## components and rationales
+
+1) a "hardware random number generator" (hrng).  optional.  i just happened to
+have one lying around, so i decided to use it.  good for generating a lot of
+high-quality entropy very quickly.  makes creating new keys much faster.
+
+2) a ledger hardware wallet.  this cryptocurrency wallet plays the role of a pgp
+smartcard, allowing me to sign things without revealing my private keys to my
+online computer.  i like that this is a self-contained device with a screen, and
+that it has a "plausible deniability" function.  it seems to strike a good
+balance between security and convenience.
+
+3) a safe means of transferring data to and from an airgapped computer, such as
+a good usb stick.  if one uses a usb stick, one should be careful to choose one
+with signed or locked firmware, to protect against unknowingly ferrying an
+attacker's code between one's "online" computer and one's airgapped computer.
+one might also consider turning off hotplugging, to keep the device from
+emulating other devices in the event it _does_ harbor malicious code in its
+firmware.
+
+if no such stick can be obtained one might use a
+[tinfoil chat](http://git.fuwafuwaqtlkkxwc.onion/yafox/tfc-mirror)-like data
+diode system instead.
+(original clearnet repository: https://github.com/maqp/tfc )
+
+in a pinch, if one's online and airgapped computers have headphone and
+microphone jacks, one could also just use an audio cable and
+[minimodem](http://git.fuwafuwaqtlkkxwc.onion/yafox/minimodem-mirror).
+(original clearnet repository: https://github.com/kamalmostafa/minimodem )
+
+4) an old luks-encrypted thinkpad with libreboot, to be kept airgapped after the
+initial setup.  used for provisioning everything and for interacting with
+sensitive material (such as encrypted backups of private keys).  libreboot might
+have been unnecessary, but as this is the most foundational element in the
+stack, i thought it would be better to be safe.  for extra security, i set up
+libreboot so that it only boots kernels signed with my pgp private key.
+
+this laptop should at least be loaded with gpg, pcscd, and the tools necessary
+to flash the firmware on one's "online" computer.  it should also have whatever
+software one needs to use one's hrng, if applicable.
+
+5) an openpower pc from raptor computing systems.  this serves as an "online"
+computer.  all its firmware (except the onboard broadcom nic; there is a
+whiteroom re-implementation effort on for that) is open source, so every chip
+requiring firmware can be flashed with custom firmware.  the system can also
+require that all firmware be signed by one's own private keys, and the firmware
+can in turn require a signed kernel and initramfs to boot, and the kernel can
+_then_, in theory, require that all executable binaries be signed as well.
+
+so it is possible to lock down this hardware with one's own keys such that
+_nothing_ which is not explicitly signed off on by oneself can run on it.
+
+of course, since this only applies to binaries, any script at all can be run
+without having been signed first.  there is always a way around whatever
+security measures one puts in place.  the goal is simply to make it difficult
+enough to get around one's defenses that the attacker moves on to another
+target, and to escape (as much as possible) mass surveillance.
+
+regardless, assuming there are no fatal bugs in the implementation, an attacker
+would have to gain physical access to one's computer to load their own firmware.
+being able to reasonably trust one's own hardware is invaluable.
+
+6) a simple linux distribution.  whatever one understands intimately is fine.
+i am building my own and have finally got it to the point where it's not too
+embarassing to share.  the goal is simply to have a system on which there is
+nothing running or installed which one has not consciously chosen, and which can
+readily support things like experimenting with different kernel configurations.
+
+## caveats
+
+the first caveat here: i am trusting IBM to be truthful about the properties of
+their openpower chips, and i am trusting raptor computing systems to be truthful
+about the properties of the mainboard they sold me.  i am also trusting everyone
+involved in the production of these chips and boards.  (attacks in manufacturing
+[do happen](https://www.bbcnewsv2vjtpsuy.onion/news/technology-47800000).)
+
+second, this stack is hardly innocuous!  the hrng, ledger, and openpower system
+are all rather unusual pieces of equipment.
+
+i have made some compromises along the way in the name of expedience.  i would
+rather not have to trust IBM, but the alternative is trusting that libreboot has
+managed to dig all the backdoors out of the old thinkpads.  it comes down to a
+bet, though i am not wagering everything on that one bet.  if my online machine
+fails me, my digital person is at least safe for a time because my keys are not
+on my online machine.  detecting that failure then becomes paramount.
+
+this is not a bet i would like to have to make if my life were in danger.  i
+share all this not because i am confident that it is the best that anyone can
+come up with, but because i think it may be a good starting point for some.
+experimenting, thinking through things, and customising one's own stack is
+encouraged.  for example, the ledger might be swapped out with some sort of
+
+at the very least, i hope this starting point provides a strong enough
+foundation for the work ahead.

soft/005-stack-zero.md.asc

@@ -0,0 +1,16 @@
+-----BEGIN PGP SIGNATURE-----
+
+iQIzBAABCAAdFiEE0ZVR9dPnC9rIvgC+tQHDCzf0gGwFAl++0LUACgkQtQHDCzf0
+gGxO7Q/+PL14+Sy2agS+nAcSihZrMJRcZo0DHuf0gCv5vE+4R7fXvO6URV1RZgTo
+iQpiE/JEKB0/vL+mc5yaQuPJPJbmW9qP0BjGEbHnnMMLnPi4YDbuokdHEvPFYm06
+/aYhR9sjp38FyphZoKDtQKuArRdbNlAfZIIf5bGRo7sK3vQGFhsxOzDzYrgVEXPZ
+rEtvzQ1r3WqztBKFnQuIl8/ZMRVYmqE0dOr3BGWqYRZXO+sd8s5Ib8UTT5Uhyp7g
+4fDNP/8ezC66nt7+fgwVVJm+6RRCRPIfUG6OUje8cU2aKNkFwiee6V70SBaWYBL6
+sOVhbSFw07Ca0Pcisz8y4atLCZOn4rBN8WCdy37LpIv5u40Zc7b6bWu9Nhq8WHm6
+ZsotWMtd9UuRsXlxmDfW0+J4nctK/1rvfZ0S202GqLFvsBGEn1Z3DMe01Nba37GZ
+5/Nl5b7H0S6jkYvYZqzbYmWvUDnf1d3tuN1scCGlBhwDRvPT5oK/fd+6H4qoBzal
+4DjhEsdzbM8WmIuUo9DAHPOhEF7Khhu/8UXBcuXUtfwt2Abnvi/me7NGoO1/g3iV
+yjufAqjhAwWizxIrVd8hb7hAI1mMV6C2Xzga4/q6Q3yx22V5nSLe/eF+RgjK3otZ
+xsRtWF18Qe3kVJ/M+Hasm+ezVnjazwuEfx6gfYdNyrgd+E4Lg/I=
+=2FZp
+-----END PGP SIGNATURE-----

soft/006-lix-os.md

@@ -0,0 +1,74 @@
+# lix os
+
+in order to have a system which both minimised trust dependencies and allowed me
+to explore my ideas around securing my system unimpeded, i decided to design and
+compile my own linux from source code.
+
+i had done this before, years ago, by following the "linux from scratch" guide.
+my goal now was to build a system i could use to birth my more-than-reasonably
+secure digital identity.  the goal was a statically linked linux based on musl
+and suckless tools.  i wanted an inflexible system that would do nothing without
+my explicit, cryptographic permission, along with a tiny codebase that would be
+easy to examine and modify.
+
+my first attempt i named "mu linux," unaware that the name was already in use.
+it was essentially a scripting of the linux from scratch approach, with a strict
+"filesystem-as-database" approach.  every discrete field was a file, so nothing
+more than "cat" was needed to read package details.  it had no ability to set
+redundant urls for fetching source code, though, and no sandboxing at all.  the
+whole thing was also written as one, tightly coupled piece.
+
+having proven that it was possible to build a static suckless userland with musl
+on my openpower computer, i decided to start using some fancier linux features
+to create some separation of state and concerns.  i took note of what seemed to
+me the discrete "units" of mu linux and began writing standalone utilities that
+did only one thing each and which i hoped might prove useful to others tackling
+the same problems.  i built a package manager that used overlayfs and chroots to
+keep filesystem changes from the build process and from the installation process
+in their own directories, facilitating insight into each step of package
+development.
+
+as i went, i started having to make compromises.  gnu tools were the first.
+getting a c compiler toolset set up with musl proved difficult.  only two
+compilers seemed to have support for the powerpc64le platform: gcc and clang.
+clang took an age to compile and gave me some trouble early on.  musl-cross-make
+provided a canonical set of patches for enabling muslc support, as well as some
+other nice features.  autotools, gnu-sed, and gnu-grep followed soon after.
+
+then dynamic linking began creeping in.  the first dynamically linked packages
+were gpg and pcscd.  i needed smartcard support, and gpg uses dlopen to load
+smartcard drivers dynamically.  rewriting portions of gpg would have resolved
+the problem, but it seemed simpler to just allow this one package to use dynamic
+linking.  i also ended up making exceptions for perl and python, as they needed
+dynamic linking to be able to load certain modules.  i absolved myself by making
+sure statically linked versions of those packages were the default.  those
+compromises got me a console userland with tmux, tor, lynx, and the ability to
+display images to the framebuffer.  
+
+then i tried to start building an identity on tor and quickly discovered i had
+no way to solve captchas!  i tried building a copy of netsurf targeting the
+framebuffer and learned i had to choose either wayland or sdl2 as middleware.
+i chose wayland, thinking i could just use michael forney's wld and swc, both of
+which were built with static linking in mind, and get a desktop environment out
+of the deal.  after quite some time wrestling with these packages, i ultimately
+gave up: netsurf would launch, but then shortly thereafter lock up the whole
+system, and i could not figure out why.  i was losing patience with the whole
+endeavor, so i decided to just use more common components for my desktop and
+revisit the problem later.
+
+so i made another compromise and built an almost entirely dynamically-linked
+desktop system: sway as the window manager, foot as the terminal emulator,
+netsurf with gtk3 as the web browser, and webkit2gtk as an alternate web browser
+for when netsurf wasn't cutting it.
+
+along the way i tried to bootstrap rust using mrustc in order to get firefox
+built and then the tor browser, but no luck there.  yet another problem to
+revisit.  in the meantime i've come up with new ideas for a third linux
+distribution better able to manage runtime dependencies, but lix os works and
+has been working for me now for a couple months.
+
+today i've released my work so far.  i have not yet purged the false starts and
+half-working packages from their respective repositories, but at present it is
+possible to set up the desktop system i have described here.  my work is spread
+out across several repositories, but the entry point for lix os is
+[here](http://git.fuwafuwaqtlkkxwc.onion/yafox/lix-os).

soft/006-lix-os.md.asc

@@ -0,0 +1,16 @@
+-----BEGIN PGP SIGNATURE-----
+
+iQIzBAABCAAdFiEE0ZVR9dPnC9rIvgC+tQHDCzf0gGwFAl++0L4ACgkQtQHDCzf0
+gGw78g/+I8Cet09ZuTjIyIaI5prB9XI6gAbIA4BSeKgJQ8gG1X1kHEUuSEDIhNcd
+nR2RwAtfQHmCzDkJ254K+9qEua9qi6jWusX9joYLYxPtAiKfgt+zPf/czzEXKHC3
+pvyBxogG9ANo7Oe3rFWucHCUjyu9Lp9wIo0XIIjPkgGfS5z9fcAJNgjecCUrDLzx
+1LBeAYqA4c1rn0lGuqFcD0GIim+GFlEcozvb0iCXK9xPam9d6+04z3lELH+LNCXH
+c5QLlzEDapXgI3FNc6tvhRnmUmSNj9grJHhTzU9pIZ5CXoBrYtgau+4ayFMK0+89
+hg8xlUnnc5S/I2a9rZxunsIi+RDN/i6VS6IIpRg9bHoIfpudimWwlM9ZfkVNpxdT
+QRCE21DTyTiDn0reRaLZTQBLxGENcAMkGlGqkJ1hoyrLwcWzCmNH9NzlEDTE07aZ
+ozWB0edG5zmdOkILZn5OEvIkY4CnIym7mVU0AnaKAyDJzR5VySdvIdlmrrKhuPzu
+EuBo/fNyD+rR3LmLCfyIxMRO49IrugNrQRYqAfZvmSFuvFGf8U4mS0FQQiLKpCLs
+F5ZxkcRWa4lhIq2KftS/7cp/uYd3fPuejCOJa0td0KNGUTdTeEEdDl5j48GMWkt4
+oJGDONyHbOC4UZaBg09XWFrj7nu2MrYU+QlkQGF9DwHtAA2teDM=
+=CmJ5
+-----END PGP SIGNATURE-----