spec.txt

   1 # ircpipe
   2
   3 sets up an irc connection, and not much more.
   4
   5 ## on connection
   6
   7 - [x] connect
   8 - [x] tls (optional cert validation)
   9 - [?] sasl plain (untested)
  10 - [x] set user and nick
  11 - [x] wait for motd/001-message
  12 - [x] optionally, do an initial join
  13
  14 ## in the background
  15
  16 - respond to server pings
  17 - keep track of when we last received an irc mesasge; if t > $timeout, send ping ourselves.
  18         (first implementation can just send a ping every $timeout (milli)seconds)
  19         (should $timeout be the time between last message and send-ping or between last message and ping-reponse?)
  20         - different timeouts:
  21           - ping interval
  22           - connect timeout
  23           - time between sent message and received response
  24           - send/recv block: invalid, due to polling
  25
  26 ## interfaces
  27
  28 - read from stdin, write to stdout
  29 - cli for setting timeout, user/nick, server info, ...
  30   - netcat-like (everything but host[{: }port] optional
  31   - how to specify tls?
  32   - how to specify auth?
  33     - relatively secure password handling!
  34
  35
  36 ## vulnerabilities
  37
  38 - we don't guard against escape sequences in responses. when used interactively,
  39   a bad actor could send malicious sequences causing terminal corruption.
  40   causing data leaks (by querying terminal information) is unlikely, as the
  41   responses won't be proper irc PRIVMSGs.
  42
  43
  44 ## minor TODOs
  45
  46 - check if port is valid
  47 - irc_poll: handle poll() EINTR (don't exit on nonfatal signal received)
  48
  49
  50 ## future todos:
  51 - flood protection!
  52
  53
  54 ## dropped features (patches accepted)
  55 - nickserv: freenode and hackint support sasl, efenet neither. rest don't care.
  56 - sasl cert: don't care for it
  57 - optionally use socket instead of stdin/stdout?
  58 - checking responses to NICK, JOIN, CAP-REQ, AUTHENTICATE
  59   for now, we're just assuming everything went ok.
  60   - NICK/USER
  61      ok: 001 (checked, to block further commands)
  62      err: 432 433 436 437 <nick>
  63   - JOIN
  64      ok: JOIN <chan>
  65      err: 471 473 474 475 403 405 437 <chan>
  66   - CAP REQ/CAP END
  67      ok: CAP <nick?> ACK
  68      err: CAP <nick?> NAK
  69      err: 421
  70   - AUTHENTICATE
  71      ok: 900 903 <nick>
  72      err: 902 904 905 908 <nick>
  73 - maybe allow HOST:PORT (nc doesn't)
  74   - maybe allow HOST +PORT and/or HOST:+PORT for tls
  75   - maybe allow irc://HOST:PORT and ircs://HOST:PORT
  76 - what to do when nick is taken
  77   - use random nick
  78   - use fallback nick (append '_')
  79   - allow specifying alternate nicks
  80   - exit (this is what we do now on receiving the numeric error response)
  81
  82 ## discarded ideas
  83 all of these would require modifying the streaming data, which is more trouble
  84 than it's worth. these could be implemented as external filters, though.
  85 - -C flag to translate CRLF to LF (from server) and LF to CRLF (from stdin)
  86 - -A flag to strip ctrlchars (formatting, colors, etc) from stdout
  87 - enforce max line length (512 bytes, including CRLF) by splitting PRIVMSG
  88
  89 ## for responses
  90
  91 we need to check and handle multiple responses to commands we've send:
  92 - ping: pong (everytime, everywhere. keep current hack)
  93 - sasl: cap-ack, 900+903 or 90x (when authenticating, during setup)
  94 - (after connecting/authenticating): 001, nick-in-use (everytime, during setup)
  95
  96 the server may send unrelated responses in-between - including pings - and we
  97 want to enforce a timeout in which we expect the response (2000ms).
  98
  99
 100 essentially, we send a command, then block until we receive a response or an error.
 101 commands we send that we need to wait for are:
 102  - PING
 103     ok: PONG :<whatever>
 104