💾 Archived View for thrig.me › blog › 2023 › 05 › 10 › misfin.gmi captured on 2023-09-08 at 16:18:36. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-05-24)
-=-=-=-=-=-=-
came up on the tilde #gemini IRC channel, so why not write some code for it? I need more practice with Go.
The implementations (surprise!) did not interoperate, which was fun. Also divergent readings of the specification have already turned up. Whose fingerprint are we sending back to the client, again?
Probably a test suite would help here. Probably I need to unrustify my SSL session debugging skills.
nc is splitting the address from the message. They're coming in as two requests, both of which confuse the mailserver.
Probably that's my client implementation, which did use two write calls:
conn.Write([]byte(header))
conn.Write([]byte(message))
A good server, however, should be able to handle this.
A malicious client can send individual bytes very slowly, or a random client might break the request into multiple sends for who knows what reason. So if you assume that your read(2) call or equivalent will get you the complete request like it does for your well behaved test code, then you have a bug. Here's an example!
The gist here is to split a test string and then send it character by character with a delay between the sends. Shouldn't be hard to implement in most any other language, or to add SSL support. How does your server handle that?
and then there's an echo server if you want to test if your client behaves poorly should the bytes trickle in slowly. SSL complicates things (no, what, really?) but the client requests or server responses could still be split up in unexpected ways. EOF handling can also be problematic (openssl s_client has -ign_eof, or you might need kluges like (cat foo; sleep 10) | ... so that the pipeline does not go away too soon, etc.
Some people do modify their firewalls or SMTP servers to send bytes very very slowly in an attempt to annoy (not really) or slow down (nope) the spammers, but that's probably not too productive and mostly ties up server resources. Still, you may want to test your clients and servers to see how they behave in the face of slow trickles. Maybe set a timeout on the reads, use asynchronous I/O to collect enough data into a buffer, that sort of thing.
And yes, nc(1) on OpenBSD supports SSL.
$ printf 'misfin://ed@example.org test test 1 2 3\r\n' |
nc -T noverify -C usercert.pem -K usercert.pem -c example.org 1958
http://man.openbsd.org/man1/nc.1
tags #misfin #go