{
"type": "entry",
"published": "2026-11-05T03:07:55.314077+00:00",
"url": "https://cleverdevil.io/2026/ugh-of-all-the-weeks-for-malachi-toney-t",
"syndication": [
"https://cleverdevil.club/@jonathan/117561627469159956",
"https://bsky.app/profile/cleverdevil.io/post/3mzjvaplpyt2e"
],
"content": {
"text": "Ugh\u2026 of all the weeks for Malachi Toney to get injured \ud83e\udd26",
"html": "<p>Ugh\u2026 of all the weeks for Malachi Toney to get injured \ud83e\udd26</p>"
},
"author": {
"type": "card",
"name": "Jonathan LaCour",
"url": "https://cleverdevil.io",
"photo": "https://cleverdevil.io/profile/photo"
},
"post-type": "note",
"_id": "50130699",
"_source": "10"
}
{
"type": "entry",
"author": {
"name": null,
"url": "https://herestomwiththeweather.com/",
"photo": null
},
"url": "https://herestomwiththeweather.com/2026/11/03/outgoing-rfc-9421-signatures/",
"published": "2026-11-03T13:41:15+00:00",
"content": {
"html": "<p>Previously, I mentioned that support for incoming <a href=\"https://www.rfc-editor.org/info/rfc9421/\">RFC 9421</a> signatures was added to <a href=\"https://github.com/herestomwiththeweather/irwin\">Irwin</a> for inbox deliveries. A week ago, I finished implementing outgoing signatures for both inbox deliveries and \u201cauthorized fetch\u201d GET requests. So, how does it know whether to send a legacy signature or a new RFC 9421 signature? In general, the <a href=\"https://swicg.github.io/activitypub-http-signature/#how-to-upgrade-supported-versions\">double-knocking technique</a>:</p>\n\n<blockquote>\n <p>First, try generating or verifying an HTTP Signature with one version, ideally (but not necessarily) the latest. If the remote server rejects that signature, eg with an HTTP 401 response, or the incoming signature doesn\u2019t verify, try with another version. Repeat until a signature passes or you\u2019ve tried all supported versions.</p>\n\n <p>(Many fediverse servers do process incoming activities asynchronously, but they generally still verify signatures synchronously, so double knocking is still viable when delivering activities to remote inboxes.)</p>\n</blockquote>\n\n<p>So, first try RFC 9421 and if that returns a 401, then retry with the legacy signature.</p>\n\n<p>However, Irwin also has a hosts database table and a new <code>legacy_signature</code> boolean was added to it. By default, it is false. There is a long tail of fediverse hosts that do not support RFC 9421: many hosts that my fediverse server rarely interacts with and I do not bother with setting their <code>legacy_signature</code> to true.</p>\n\n<p>However, there are a few that my fediverse server does interact with a lot, so their host records have been updated so that Irwin doesn\u2019t make many unnecessary requests. For example, threads.net returns 404 when it is sent a request signed with RFC 9421 rather than the expected 401 that correctly implemented servers return.</p>\n\n<p>So, at the start of <a href=\"https://github.com/herestomwiththeweather/irwin/blob/main/app/lib/http_client.rb#L42\">HttpClient#request_headers()</a>, the legacy signature is sent for such hosts:</p>\n\n<pre><code> def request_headers(method_string, legacy_signature = false)\n if !legacy_signature && Host.find_by(name: @url.host)&.legacy_signature\n Rails.logger.info \"#{self.class}##{__method__} setting legacy signature for #{@url.host}\"\n legacy_signature = true\n end\n</code></pre>\n\n<p>The API method to construct signature headers for both legacy and RFC 9421 signatures is the same.</p>\n\n<pre><code> klass = legacy_signature ? Serge::FediSignature : Serge::MessageSignature\n Rails.logger.info \"#{self.class}##{__method__} signing request with #{klass}\"\n\n headers.merge!(\n klass.headers(\n method: method_string,\n url: @url,\n body: @body,\n public_key_id: @main_key_url,\n private_key: @private_key\n )\n )\n</code></pre>\n<p>The ruby gem library <a href=\"https://github.com/herestomwiththeweather/serge\">serge</a> that is being used here uses the <a href=\"https://github.com/nomadium/linzer\">linzer</a> gem for RFC 9421 signatures and Irwin\u2019s old code for the legacy signatures.</p>",
"text": "Previously, I mentioned that support for incoming RFC 9421 signatures was added to Irwin for inbox deliveries. A week ago, I finished implementing outgoing signatures for both inbox deliveries and \u201cauthorized fetch\u201d GET requests. So, how does it know whether to send a legacy signature or a new RFC 9421 signature? In general, the double-knocking technique:\n\n\n First, try generating or verifying an HTTP Signature with one version, ideally (but not necessarily) the latest. If the remote server rejects that signature, eg with an HTTP 401 response, or the incoming signature doesn\u2019t verify, try with another version. Repeat until a signature passes or you\u2019ve tried all supported versions.\n\n (Many fediverse servers do process incoming activities asynchronously, but they generally still verify signatures synchronously, so double knocking is still viable when delivering activities to remote inboxes.)\n\n\nSo, first try RFC 9421 and if that returns a 401, then retry with the legacy signature.\n\nHowever, Irwin also has a hosts database table and a new legacy_signature boolean was added to it. By default, it is false. There is a long tail of fediverse hosts that do not support RFC 9421: many hosts that my fediverse server rarely interacts with and I do not bother with setting their legacy_signature to true.\n\nHowever, there are a few that my fediverse server does interact with a lot, so their host records have been updated so that Irwin doesn\u2019t make many unnecessary requests. For example, threads.net returns 404 when it is sent a request signed with RFC 9421 rather than the expected 401 that correctly implemented servers return.\n\nSo, at the start of HttpClient#request_headers(), the legacy signature is sent for such hosts:\n\n def request_headers(method_string, legacy_signature = false)\n if !legacy_signature && Host.find_by(name: @url.host)&.legacy_signature\n Rails.logger.info \"#{self.class}##{__method__} setting legacy signature for #{@url.host}\"\n legacy_signature = true\n end\n\n\nThe API method to construct signature headers for both legacy and RFC 9421 signatures is the same.\n\n klass = legacy_signature ? Serge::FediSignature : Serge::MessageSignature\n Rails.logger.info \"#{self.class}##{__method__} signing request with #{klass}\"\n\n headers.merge!(\n klass.headers(\n method: method_string,\n url: @url,\n body: @body,\n public_key_id: @main_key_url,\n private_key: @private_key\n )\n )\n\nThe ruby gem library serge that is being used here uses the linzer gem for RFC 9421 signatures and Irwin\u2019s old code for the legacy signatures."
},
"name": "Outgoing RFC 9421 Signatures",
"post-type": "article",
"_id": "50114987",
"_source": "246"
}
Our secondary is… not good. Pretty much have to get home with the pass rush or you’re guaranteed chunk plays all day long. Hope the defense steps the hell up in the second half.
{
"type": "entry",
"published": "2026-11-01T01:18:09.781471+00:00",
"url": "https://cleverdevil.io/2026/our-secondary-is-not-good-pretty-much-ha",
"syndication": [
"https://cleverdevil.club/@jonathan/117538546636741959",
"https://bsky.app/profile/cleverdevil.io/post/3mz7narbr7n24"
],
"content": {
"text": "Our secondary is\u2026 not good. Pretty much have to get home with the pass rush or you\u2019re guaranteed chunk plays all day long. Hope the defense steps the hell up in the second half.",
"html": "<p>Our secondary is\u2026 not good. Pretty much have to get home with the pass rush or you\u2019re guaranteed chunk plays all day long. Hope the defense steps the hell up in the second half.</p>"
},
"author": {
"type": "card",
"name": "Jonathan LaCour",
"url": "https://cleverdevil.io",
"photo": "https://cleverdevil.io/profile/photo"
},
"post-type": "note",
"_id": "50082041",
"_source": "10"
}
{
"type": "entry",
"published": "2026-10-31T22:22:18.064732+00:00",
"url": "https://cleverdevil.io/2026/lewis-so-happy-for-him-sad-for-charles-w",
"syndication": [
"https://cleverdevil.club/@jonathan/117537855120673388",
"https://bsky.app/profile/cleverdevil.io/post/3mz7dgcfpwb2z"
],
"content": {
"text": "Lewis!!! So happy for him. Sad for Charles, who was easily outperforming all weekend, but just couldn\u2019t do it in Q3 yet again.",
"html": "<p>Lewis!!! So happy for him. Sad for Charles, who was easily outperforming all weekend, but just couldn\u2019t do it in Q3 yet again.</p>"
},
"author": {
"type": "card",
"name": "Jonathan LaCour",
"url": "https://cleverdevil.io",
"photo": "https://cleverdevil.io/profile/photo"
},
"post-type": "note",
"_id": "50080548",
"_source": "10"
}
My new PGP setup. A primary yubikey has my main "certify" key, which is able to certify subkeys. Two other yubikeys have duplicate copies of the same subkey. These can be used for signing and verifying. I also have a subkey on my Mac directly for day to day things like signing git commits.
{
"type": "entry",
"published": "2026-10-30T14:49:00-07:00",
"url": "https://aaronparecki.com/2026/10/30/16/",
"category": [
"pgp",
"gpg",
"yubikey"
],
"photo": [
"https://aperture-media.p3k.io/aaronparecki.com/318ae6c81bfe4b817b1f54ffcb94f46e72fa5e3198de385e6139f410abe717c5.jpg"
],
"content": {
"text": "My new PGP setup. A primary yubikey has my main \"certify\" key, which is able to certify subkeys. Two other yubikeys have duplicate copies of the same subkey. These can be used for signing and verifying. I also have a subkey on my Mac directly for day to day things like signing git commits."
},
"author": {
"type": "card",
"name": "Aaron Parecki",
"url": "https://aaronparecki.com/",
"photo": "https://aperture-media.p3k.io/aaronparecki.com/41061f9de825966faa22e9c42830e1d4a614a321213b4575b9488aa93f89817a.jpg"
},
"post-type": "photo",
"_id": "50065156",
"_source": "16"
}
