diff --git a/posts/2020-06-30-blog.md b/posts/2020-06-30-blog.md index 728fed2..a0b5fae 100644 --- a/posts/2020-06-30-blog.md +++ b/posts/2020-06-30-blog.md @@ -14,7 +14,7 @@ update. Multiple people had recommended Jekyll to me, and I had seen many others use it for their websites. Making a simple blog with it seemed simple, but extending -it to handle a custom page for my music was a pain. It didn't help that I am far +it to handle a custom page for my music was a pain. It didn’t help that I am far too lazy to learn about Ruby. The solution was ridiculously simple: a Makefile and some Python scripts. I had diff --git a/posts/2020-07-12-nds-constraint.md b/posts/2020-07-12-nds-constraint.md index a776f58..16b9bdc 100644 --- a/posts/2020-07-12-nds-constraint.md +++ b/posts/2020-07-12-nds-constraint.md @@ -1,11 +1,11 @@ template: post -title: nds-constrain't +title: nds-constrain’t author: flewkey timestamp: 1594525504 license: CC-BY -Once upon a time, shutterbug2000 discovered nds-constrain't: a bug in Nintendo's -NTR SSL library that allowed it's connections to be easily intercepted. This +Once upon a time, shutterbug2000 discovered nds-constrain’t: a bug in Nintendo’s +NTR SSL library that allowed it’s connections to be easily intercepted. This made it possible to connect to alternative online services without ROM patching. The bug itself is simple: the NDS SSL library does not care whether or not a @@ -19,22 +19,22 @@ better written than mine. However, you are free to keep reading this one. **Update (2020-12-31):** I have corrected some mistakes in this post. There is also information at the bottom of this post regarding OpenSSL which is important -to setting up nds-constrain't properly. +to setting up nds-constrain’t properly. --- ### Getting the Wii client certificate As explained in the [official page](https://github.com/KaeruTeam/nds-constraint) -for nds-constrain't, the Wii client certificate is signed by Nintendo and -considered valid. Therefore, we can use it's key to sign whatever we want. You +for nds-constrain’t, the Wii client certificate is signed by Nintendo and +considered valid. Therefore, we can use it’s key to sign whatever we want. You _could_ grab it from a Wii, but it is much easier to download it from -[Larsenv's page](https://larsenv.github.io/NintendoCerts/index.html). Choose the -"Wii NWC Prod 1" key pair. +[Larsenv’s page](https://larsenv.github.io/NintendoCerts/index.html). Choose the +“Wii NWC Prod 1” key pair. ### Converting it to a useable format -The file is a PKCS12, and we can't do anything useful with it until we extract +The file is a PKCS12, and we can’t do anything useful with it until we extract the certificate and the private key. Thankfully, this is pretty simple. openssl pkcs12 -in WII_NWC_1_CERT.p12 -passin pass:alpine -passout pass:alpine -out keys.txt @@ -67,7 +67,7 @@ NGINX users need to create a file for the certificate chain as well. Once the SSL certificate is installed, you may run into issues connecting with your DS. This because your NDS only knows how to use SSLv3, with either the -RC4-SHA or RC4-MD5 cipher set. Webservers don't support this by default, so this +RC4-SHA or RC4-MD5 cipher set. Webservers don’t support this by default, so this requires special configuration. ### NGINX configuration @@ -85,9 +85,9 @@ Assuming that you have added your certificate chain and key, your DS should be able to connect. It is worth noting that most services for Nintendo consoles make liberal use of headers, and some headers (e.g. `http_x_gamecd`) contain underscores, which -[shouldn't be in the header field](https://tools.ietf.org/html/rfc7230#section-3.2.6). +[shouldn’t be in the header field](https://tools.ietf.org/html/rfc7230#section-3.2.6). You should also configure NGINX to pass request headers to your server if you -haven't already. +haven’t already. underscores_in_headers on; proxy_pass_request_headers on; @@ -154,11 +154,11 @@ so: --with-openssl-opt=enable-ssl3 --with-openssl-opt=enable-ssl3-method \ --with-openssl-opt=enable-weak-ssl-ciphers -Run "make" and "sudo make install" like usual. Be sure that you run the version -of NGINX in /usr/local for nds-constrain't. You might want to uninstall any +Run “make” and “sudo make install” like usual. Be sure that you run the version +of NGINX in /usr/local for nds-constrain’t. You might want to uninstall any existing versions of NGINX to avoid confusion. -Gentoo users can add the "sslv3" and "weak-ssl-ciphers" USE flags to OpenSSL +Gentoo users can add the “sslv3” and “weak-ssl-ciphers” USE flags to OpenSSL and rebuild it. Since there is no weak-ssl-ciphers USE flag at the time of writing, you might want to add my [flewkey-overlay](https://git.sdf.org/flewkey/flewkey-overlay) and unmask @@ -172,21 +172,21 @@ OpenSSL like so: ./config enable-ssl3 enable-ssl3-method enable-weak-ssl-ciphers -After this, run "make" and "sudo make install". OpenSSL will install in -/usr/local and /usr/local/ssl by default, so it shouldn't interfere with the +After this, run “make” and “sudo make install”. OpenSSL will install in +/usr/local and /usr/local/ssl by default, so it shouldn’t interfere with the version currently installed on your system. You will also need to make the -OpenSSL configuration change made in the "Apache configuration" +OpenSSL configuration change made in the “Apache configuration” Next, we need to actually configure Apache, specifying the location of OpenSSL like so: ./configure --enable-ssl --with-ssl=/usr/local -Run "make" and "sudo make install" like usual. Be sure that you use the version -of Apache in /usr/local for nds-constrain't. You might want to uninstall any +Run “make” and “sudo make install” like usual. Be sure that you use the version +of Apache in /usr/local for nds-constrain’t. You might want to uninstall any existing versions of Apache to avoid confusion. -Gentoo users can add the "sslv3" and "weak-ssl-ciphers" USE flags to OpenSSL +Gentoo users can add the “sslv3” and “weak-ssl-ciphers” USE flags to OpenSSL and rebuild it. Since there is no weak-ssl-ciphers USE flag at the time of writing, you might want to add my [flewkey-overlay](https://git.sdf.org/flewkey/flewkey-overlay) and unmask @@ -197,7 +197,7 @@ writing, you might want to add my ### Contributions Thanks to [shutterbug2000](https://github.com/shutterbug2000) for discovering -nds-constrain't, as well as [Lauren Kelly](https://muffinti.me/) and +nds-constrain’t, as well as [Lauren Kelly](https://muffinti.me/) and [jaames](https://jamesdaniel.dev/) for their work on the official guide. These individuals have contributed a lot to the Nintendo and Flipnote Studio communities in general. diff --git a/posts/2020-08-28-regarding-git-hosting.md b/posts/2020-08-28-regarding-git-hosting.md index 443958a..ac6ad91 100644 --- a/posts/2020-08-28-regarding-git-hosting.md +++ b/posts/2020-08-28-regarding-git-hosting.md @@ -6,41 +6,41 @@ license: CC-BY When it comes to online services, many people look past simple solutions and jump to the large pieces of software and complicated solutions. One case of this -which I see on a regular basis is git hosting, and I don't think that most +which I see on a regular basis is git hosting, and I don’t think that most people understand how simple it is to host git repositories. -Many people think that hosting git is hard because they believe that it's +Many people think that hosting git is hard because they believe that it’s necessary to install and configure a code forge on their server. They will usually install GitLab, which is -["robust"](https://docs.gitlab.com/ee/administration/operations/unicorn.html#unicorn-worker-killer) +[“robust”](https://docs.gitlab.com/ee/administration/operations/unicorn.html#unicorn-worker-killer) and definitely not overkill for hosting a handful of personal repositories. There are also a few people who install less gross robust git services like [Gitea](https://gitea.io/) and [SourceHut](https://sr.ht/) -to host their projects. The thing is... they really don't have to. +to host their projects. The thing is... they really don’t have to. `git clone --bare repo repo.git && scp -r repo.git name@server:/srv/git` Those are the only commands needed to run to host a git repository on any server -with SSH access. The path doesn't even have to be `/srv/git`. As long as the +with SSH access. The path doesn’t even have to be `/srv/git`. As long as the URI (e.g. `ssh://name@server:/srv/git/repo.git`) points to a bare git repository which the user has read access to, they can pull from it. With write access, they can even push to it. Amazing. For more information on using git with your server, read the [relevant chapter](https://git-scm.com/book/en/v2/Git-on-the-Server-The-Protocols) -from the Pro Git book. It will explain how to set up a more limited "git" user for +from the Pro Git book. It will explain how to set up a more limited “git” user for SSH, use the git daemon, rig up git-http-backend on your webserver, and even use -GitWeb to show a web UI. It's not much harder the simple setup above. +GitWeb to show a web UI. It’s not much harder the simple setup above. -There are also other projects which can complement git hosting. If GitWeb isn't +There are also other projects which can complement git hosting. If GitWeb isn’t fancy enough, there is also [cgit](https://git.zx2c4.com/cgit/). Issue tracking can be handled with [Trac](https://trac.edgewall.org/), and [e-mail](https://git-send-email.io/) can be used to accept patches. At that point though, using a proper code forge might be a more suitable option. -Self-hosting git really isn't _that_ important, nor is there anything wrong with -sticking all of one's projects on GitHub. (Most of mine are on the SDF GIT -Society anyways.) However, I've seen too many people purchase subscriptions from -GitHub for the privilege of private repositories. I'm tired of seeing unused +Self-hosting git really isn’t _that_ important, nor is there anything wrong with +sticking all of one’s projects on GitHub. (Most of mine are on the SDF GIT +Society anyways.) However, I’ve seen too many people purchase subscriptions from +GitHub for the privilege of private repositories. I’m tired of seeing unused GitLab and Gitea instances as well. When setting up a code forge, make sure -that it's necessary. +that it’s necessary. diff --git a/posts/2021-03-29-gentoo-overlays-for-noobs.md b/posts/2021-03-29-gentoo-overlays-for-noobs.md index 5873267..d5356b5 100644 --- a/posts/2021-03-29-gentoo-overlays-for-noobs.md +++ b/posts/2021-03-29-gentoo-overlays-for-noobs.md @@ -24,20 +24,20 @@ and [dev-util/pkgcheck](https://packages.gentoo.org/packages/dev-util/pkgcheck). 4. `echo masters = gentoo > metadata/layout.conf` Congratulations, you now have the basic directory structure of a Gentoo overlay. -Now that we've named our repository and set the repository master to the Gentoo +Now that we’ve named our repository and set the repository master to the Gentoo ebuild repository, we are ready to go. At this point, you can turn this folder into a git repository, create your initial commit, and push it somewhere. I personally recommend doing this since it makes changes easy to track, and allows you to sync it between devices. If -you don't want to do this, add `auto-sync = false` to your layout.conf to tell +you don’t want to do this, add `auto-sync = false` to your layout.conf to tell Portage not to sync it with anything. To check that your repository is good, run `repoman` or `pkgcheck scan` in the root of your repository. It is good to keep an eye on it to keep the quality of your ebuilds from going in the gutter. -After that, let's tell Portage about it! Create +After that, let’s tell Portage about it! Create `/etc/portage/repos.conf/test-overlay.conf` and add the following: ``` @@ -54,15 +54,15 @@ Your repository is now ready for packaging data. In Gentoo, [ebuilds](https://wiki.gentoo.org/wiki/Ebuild) are used to make packages. An ebuild is like a recipe that tells Portage how to build and install -a package. For this example, we're going to make an ebuild for +a package. For this example, we’re going to make an ebuild for [gui-apps/swaybg](https://packages.gentoo.org/packages/gui-apps/swaybg). -Don't peek at the Gentoo ebuild yet! +Don’t peek at the Gentoo ebuild yet! -First, let's create a folder for the package. +First, let’s create a folder for the package. `mkdir -p gui-apps/swaybg && cd $_` -Before we make an ebuild, let's create a metadata.xml file. Vim users will +Before we make an ebuild, let’s create a metadata.xml file. Vim users will notice that this is already filled out, thanks to the power of [gentoo-syntax](https://gitweb.gentoo.org/proj/gentoo-syntax.git). We can specify a bit more, but all we need is a maintainer. @@ -79,8 +79,8 @@ specify a bit more, but all we need is a maintainer. ``` Now we can create an ebuild. First, open [the swaybg repository](https://github.com/swaywm/swaybg) -and check the version that we want to package. The only version is "1.0", so we -can package that. Let's create a file called "swaybg-1.0.ebuild". For vim users +and check the version that we want to package. The only version is “1.0”, so we +can package that. Let’s create a file called “swaybg-1.0.ebuild”. For vim users the gentoo-syntax tool should have already filled part of this out for you. If not, it should be something like this. @@ -109,8 +109,8 @@ guide](https://devmanual.gentoo.org/ebuild-writing/file-format/index.html#file-n ### Information -Now, we should fill out the metadata. Let's add a description, paste in the -homepage link, and specify the license as "MIT". The SRC_URI should link to a +Now, we should fill out the metadata. Let’s add a description, paste in the +homepage link, and specify the license as “MIT”. The SRC_URI should link to a copy of the latest version, like so: `SRC_URI="https://github.com/swaywm/${{PN}}/archive/${{PV}}.tar.gz -> ${{P}}.tar.gz"` @@ -139,12 +139,12 @@ dependencies: - scdoc (optional) Looking closely, we can also see that pkgconfig is used in -meson.build, so pkgconfig is a dependency as well. We also won't need to list +meson.build, so pkgconfig is a dependency as well. We also won’t need to list meson as a dependency, since we already inherited meson.eclass. (If the version of Meson it requires is unstable though, it might be worth adding it to prevent Portage from trying and failing to build it with the stable version.) -Now let's track down the packages for our dependencies. +Now let’s track down the packages for our dependencies. - [dev-libs/wayland](https://packages.gentoo.org/packages/dev-libs/wayland) - [dev-libs/wayland-protocols](https://packages.gentoo.org/packages/dev-libs/wayland-protocols) @@ -153,10 +153,10 @@ Now let's track down the packages for our dependencies. - [virtual/pkgconfig](https://packages.gentoo.org/packages/virtual/pkgconfig) - [app-text/scdoc](https://packages.gentoo.org/packages/app-text/scdoc) -Shoving them all into the DEPEND variable wouldn't be the end of the world, but +Shoving them all into the DEPEND variable wouldn’t be the end of the world, but it is good to sort them out. All of these are required for building the package, so none of them will go in RDEPEND. As for BDEPEND, we know that pkgconfig and -wayland-protocols obviously won't be needed to run it. +wayland-protocols obviously won’t be needed to run it. This leaves scdoc. We know that it goes in BDEPEND, but it is an optional dependency that is _only used to build documentation_, so we will make it @@ -174,9 +174,9 @@ Then, we will specify app-text/scdoc as an optional dependency in BDEPENDS: `man? ( app-text/scdoc )` -Finally, we need to tell Meson to only build documentation when the "man" USE +Finally, we need to tell Meson to only build documentation when the “man” USE flag is enabled. The meson.build file shows that the man-pages Meson option -controls this. It is passed to the "required" argument, making it a +controls this. It is passed to the “required” argument, making it a [feature option](https://mesonbuild.com/Build-options.html#features). The meson.eclass docs provide us with an @@ -195,7 +195,7 @@ src_configure() {{ ### Finishing Now, we will generate a Manifest, which will allow Portage to check the -integrity of the ebuild and it's source files. We can use the ebuild tool to do +integrity of the ebuild and it’s source files. We can use the ebuild tool to do this. `ebuild ./swaybg-1.0.ebuild manifest` @@ -206,7 +206,7 @@ Manifest for an entire folder. `repoman manifest` All right, this should be complete! Now, it is time to run `repoman` or -`pkgcheck scan` to look for issues. If it looks similar to what's below, then +`pkgcheck scan` to look for issues. If it looks similar to what’s below, then all should be good. ``` @@ -268,14 +268,14 @@ then commit. `git commit -m "gui-apps/swaybg: New package"` Users of repoman can also use `repoman commit`, which will automatically prefix -their commit with the package name and add some extra information. Once you're +their commit with the package name and add some extra information. Once you’re happy, feel free to push your work. Just make sure that it is in good shape. Changing history and forcing a git push in an ebuild repository is a terrible idea. ### Checking our work -Now let's look at +Now let’s look at [swaybg-1.0.ebuild](https://gitweb.gentoo.org/repo/gentoo.git/tree/gui-apps/swaybg/swaybg-1.0.ebuild) and see how we did. @@ -283,13 +283,13 @@ Despite trying to be thorough for the sake of the blog post, I still missed some things. - x11-libs/gdk-pixbuf and x11-libs/cairo are under BDEPEND - - I did not notice that they were statically linked since I don't understand Meson well. + - I did not notice that they were statically linked since I don’t understand Meson well. - It prevents swaybg from running alongside versions of gui-wm/sway below 1.1_alpha1 - Likely because that is the version where [swaybg became standalone](https://github.com/swaywm/sway/releases/tag/1.1-rc1). - I forgot to remove the -Werror compiler flag - Leaving it enabled can [break things](https://devmanual.gentoo.org/ebuild-writing/common-mistakes/index.html#-werror-compiler-flag-not-removed). - The ebuild uses usex instead of meson_feature - - meson_feature wasn't added until + - meson_feature wasn’t added until [2019-03-17](https://gitweb.gentoo.org/repo/gentoo.git/commit/eclass/meson.eclass?id=eeb4c7afa12a3acb5773fbfdb4e6e1b1f626e731), so the authors probably just missed it. @@ -313,7 +313,7 @@ time. Good luck, and godspeed! ### Sharing with others -If you've made your overlay into a git repository, you can easily share it with +If you’ve made your overlay into a git repository, you can easily share it with your friends! Although they could always clone it and add it to their repos.conf manually, it is easier to do so using a tool. The two I know of are [app-eselect/eselect-repository](https://packages.gentoo.org/packages/app-eselect/eselect-repository)