blog: 2022-08-22: sshsvf

Resolves: #296

blog/_posts/2022-08-22-ssh-signing-verifying-functions.md

@@ -0,0 +1,76 @@
+---
+layout: post
+title: "bash/zsh functions for easier SSH signing and verification"
+category: [english]
+tags: [ssh]
+---
+
+*I have been using SSH signed git commits from 8 months and started signing things with my SSH key instead of PGP keys and thought to share how to do that more easily*
+
+If you didn't know that SSH can be used for this, I suggest reading
+
+* [Andrew Ayer: It's Now Possible To Sign Arbitrary Data With Your SSH Keys](https://www.agwa.name/blog/post/ssh_signatures)
+* [Caleb Hearth: Signing Git Commits with Your SSH Key](https://calebhearth.com/sign-git-with-ssh) ([web.archive.org](https://web.archive.org/web/20211117182628/https://calebhearth.com/sign-git-with-ssh))
+
+## Signing
+
+Usually you do `ssh-keygen -Y sign -f MYPUBLICKEY -n TYPE filename`, but that is a bit of effort, why not make an alias for it? In my shellrc's I have:
+
+```bash
+alias ssh-sign-file="ssh-keygen -Y sign -f ~/.ssh/signingkey.pub -n file"
+```
+
+As I don't change which key I use so often, I can export my public key to `~/.ssh/signingkey.pub`
+or symlink it to the right place and now when I need to sign something, I can just `ssh-sign-file file.txt`
+to generate a `file.txt.sig`. Of course this assumes that I always sign files, but I don't remember signing other things as git handles the commits for me.
+
+Thus to sign file, I simply say `ssh-sign-file hello.txt` to receive `hello.txt.sig` containing my signature.
+
+```
+Signing file hello.txt
+Write signature to hello.txt.sig
+```
+
+## Verifying
+
+There isn't much point in signing things, unless you are able to verify them. The command for this is `ssh-keygen -Y verify -f $allowed_signers -I $EMAIL -n file -s SIGNATUREFILE < $2`, isn't that a bit much to keep in mind? In my opinion it is and thus the function gets a bit more complicated:
+
+```bash
+sshAllowedSigners=$HOME/src/gitea.blesmrt.net/Mikaela/ssh-allowed_signers/allowed_signers
+ssh-verify-file () {
+    echo "$1 ${2:?Usage: ssh-verify-file <email> <file-to-verify>}" > /dev/null
+    ssh-keygen -Y verify -f $sshAllowedSigners -I $1 -n file -s $2.sig < $2
+}
+```
+
+First I specify where is my `allowed_signers` file so I don't have to repeat it and in case I misuse the function, it reminds me how to use it:
+
+```bash
+% ssh-verify-file hello.txt
+ssh-verify-file:1: 2: Usage: ssh-verify-file <email> <file-to-verify>
+```
+
+I again don't remember verifying other types of files as git handles it for me and I think it's a safe assumption that the signature ends to `.sig`.
+
+So to use it properly and verify the previously signed file `ssh-verify-file noreply@aminda.eu hello.txt`
+
+```
+Good "file" signature for noreply@aminda.eu with ED25519 key SHA256:y2OpGEbett3Fqn8XFrP0X4mWfCVKf4rWkxERzqPY81U
+```
+
+## Extra: having git handle it for me
+
+When git is configured properly with `gpg.ssh.allowedSignersFile` the usual git verification commands work with SSH as well:
+
+* `git log --show-signature` for the usual git log with signatures visbile
+* `git verify-tag 1.0` for verifying a specific tag signature.
+* `git verify-commit HEAD` to verify the latest commit signature or just to see that git signing is working.
+
+Isn't the last command again effort? What if I could just say `git verify`?
+
+```
+% git verify
+Good "git" signature for *@mikaela.info with RSA key SHA256:CXLULpqNBdUKB6E6fLA1b/4SzG0HvKD19PbIePU175Q
+```
+
+This is possible too, `git config --global alias.verify verify-commit HEAD`

pages/matrix.markdown

@@ -28,7 +28,7 @@ links.*
 
 ### Why so many accounts?
 
-In my opinion it's preferable to have multiple accounts on different homeservers for ensuring decentralisation instead of having a single authority in power and being able to issue commands from multiple servers in case of federation meltdown which multiple rooms experienced during the period of room version 9 before homeserver software started to nag on unintentionally open registration refusing to start.
+In my opinion it's preferable to have multiple accounts on different homeservers for ensuring decentralisation instead of having a single authority in power and being able to issue commands from multiple servers in case of federation meltdown which multiple rooms experienced during the period of room version 9 before homeserver software started to nag on unintentionally open registration refusing to start. Additionally state resets are a good reason to keep old accounts around.
 
 ### Why do you use Matrix URI scheme instead of matrix.to?
 
@@ -42,6 +42,49 @@ They are related to bringing Matrix to other protocols or vice versa.
 * A puppet is the opposite, a Matrix account controlled from another protocol such as IRC or XMPP (the controller/puppetmaster being the user there).
 * A double-puppet is when you are using both protocols and have connected them to each other such as a message from Discord appears as your real Matrix account and message from Matrixx appears as your real Discord account instead of something virtual only existing due to the bridge.
 
+### What are state resets?
+
+The term is used least in two different scenarios:
+
+* when your display name and/or avatar return back to what they were previously
+  without anyone doing anything.
+* more seriously when the Matrix federation decides that the room is actually
+  in the past adding/removing users who were (or weren't) in the room at that time.
+  This also affects administrator/moderator access.
+
+[This issue was supposed to be fixed at room version 2 with Stare Resolution Version 2](https://spec.matrix.org/latest/rooms/#complete-list-of-room-versions),
+but regardless [still happens in all versions after that](https://github.com/matrix-org/synapse/issues/8629). If you are affected, your best bet is to
+`/upgraderoom {{site.matrixLatestRoomVersion}}`, which is a bit distruptive operation as all your users have to join the upgraded version and all homeservers involved must support it.
+
+You shouldn't just trust me or the variable on this site on what is the latest version, [consult the Spec](https://spec.matrix.org/latest/rooms/#complete-list-of-room-versions) and add [Version Checker](matrix:u/version:maunium.net) or [Fluff Generator](matrix:u/+:jae.fi) or [their sibling](https://github.com/maubot/rsvc) to your room and once they join, `!servers upgrade {{site.matrixLatestRoomVersion}}` replacing the  {{site.matrixLatestRoomVersion}} with your target version.
+
+### What are these idlekicks for inactivity, why are they for?
+
+Some Matrix rooms decide to connect their channel to IRC maintaining the same users on both sides, which can be heavy for the IRC network depending on bridge type of which there are three "major" variants:
+
+* matrix-appservice-irc which creates a ghost for every Matrix user on the IRC side. All of these pretend to be separate clients, so if you have 1000 ghosts at IRC, all internal PING/PONG (keepalive) traffic will be sent 1000 times every few minutes and so will every message received.
+* heisenbridge has two modes, either it acts as a IRC bouncer keeping everything separate for every user or a single bot connection to IRC while creating puppets for IRC users to use at Matrix. It also supports RELAYMSG for more modern IRC networks.
+* matterbridge is the most lightweight of the three working as a traditional relaybot on both sides. Unlike the others, it doesn't require selfhosting your own homeserver making it the most accessible for those with less resources and the option I use whenever possible. Sadly it doesn't look that great [without RELAYMSG support I live in hope of Matrix implementing one day](https://github.com/matrix-org/matrix-spec/issues/840).
+
+As matrix-appservice-irc very quickly becomes traffic-intensive, its operators generally have agreement with IRC networks (or are IRC networks by themselves) to remove unused connections after a month or three of inactivity, which is judged by lack of public read-receipts anywhere the bridge can see. It could have been implemented better [pretending to be a server instead](https://github.com/matrix-org/matrix-appservice-irc/issues/329), which would have a problem of practically being `root` and thus not many IRC networks would open their door to a third party bridge and the Ergo IRCd doesn't even support server linking (opting to be HA instead, but more of that in "Why should I use Matrix instead of IRC?").
+
+Being a server would also resolve IRC users getting annoyed by huge disconnection floods whenever matrix-appservice-irc restarts as it could be [batched by the IRCd users are connected to](https://ircv3.net/specs/batches/netsplit).
+
+The issues of matrix-appservice-irc grow worse when the room has bridges to other protocols, as those grow the IRC user count, use nicknames (sometimes capturing nicknames of people using both protocols and may be difficult to regain if the bridge doesn't answer to `!irc nick SomethingElse`) especially when the other protocol doesn't support direct/private messages and doesn't have even that excuse of using a connection slot.
+
+I hope this answer helped explain why this behaviour exists and that IRC users aren't opposed to bridging out of malice.
+
+#### But the relaybots look so ugly
+
+IRC users have dealt with them since always, I tend to use Limnoria IRC bot which is forked from Supybot and has had the Relay plugin (for relaying messages between multiple IRC networks) [since possibly before `Wed Feb 2 06:45:35 2005 +0000`](https://github.com/progval/Limnoria/commit/e4e5c1482489451c1ae9b6b4ee9b9147a295320e) and I imagine it was far from the first IRC relay.
+
+This means that even before IRCv3 RELAYMSG and displayname proposals, which I wish to merge so modern clients could show displaynames and legacy RELAYMSGs, there have been client-side solutions that have also been evolving:
+
+* Irssi I haven't used personally, but I hear it has a [detelexify](https://github.com/zouppen/irssi-detelexify/) that looks a bit like it's made with Heisenbridge in mind.
+* WeeChat used to have a separate script for this, but at version 1.1 in gained the Trigger plugin able to perform actions without scripts, thus meaning you can use something like [this Relaybot 2 Trigger example](https://github.com/weechat/weechat/wiki/Triggers#relaybot-2) without having to install anything (while `/script` would be easy too).
+
+I hope Matrix will get better at this too.
+
 ### Which client do you recommend?
 
 The one that fits your needs. Personally I mix-and-match:
@@ -118,6 +161,11 @@ However it cannot currently mature past that as:
   which has been supported by Matrix Specification since September 2021 or so meaning
   users of those aren't able to request access to our rooms.
 
+If you want in, you may knock using Nheko. Additionally/Alternatively your best
+bet is to come to [#verkkopalvelut](https://webchat.pirateirc.net/?channel=#verkkopalvelut)
+and tell `AmindaSuomalainen` your Matrix ID in a nice message (to show you aren't a bot)
+that you wish in.
+
 ### So do you wish Matrix to fail?
 
 No, I have been using countless of hours at writing these critiques and performing "quality assurance"/testing,