Just a sample of the Echomail archive
Cooperative anarchy at its finest, still active today. Darkrealms is the Zone 1 Hub.
|    SYNC_SYSOPS    |    Synchronet Multinode BBS Software Suppor    |    33,243 messages    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
|    Message 31,350 of 33,243    |
|    Deucе to GitLab issue in main/sbbs    |
|    Re-examine self-signed certificate gener    |
|    04 Mar 25 09:40:34    |
      TZUTC: -0800       MSGID: 57404.sync_sys@1:103/705 2c2d514e       PID: Synchronet 3.20c-Linux master/80337c044 Mar 01 2025 GCC 12.2.0       TID: SBBSecho 3.23-Linux master/80337c044 Mar 01 2025 GCC 12.2.0       BBSID: VERT       CHRS: UTF-8 4       open https://gitlab.synchro.net/main/sbbs/-/issues/881              In general, it seems that any time I hear about self-signed certificates, it's       because they got generated and clobbered what the SysOp actually wanted. I       can think of a few options...              1. Have a configuration option to allow it. This option could be set in the       default configs and documented to be disabled when "something else" is used.       2. Remove it and have a script that can generated one on demand, document its       use and disable TLS/SSH by default.              The reading of the current cert would then need a retry/backoff mechanism of       some sort and useful error messages.       --- SBBSecho 3.23-Linux        * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)       SEEN-BY: 10/0 1 102/401 103/1 13 17 705 105/81 106/201 124/5016 128/187       SEEN-BY: 153/7715 154/110 214/22 218/0 1 215 601 700 720 840 860 880       SEEN-BY: 226/30 227/114 229/110 114 206 317 400 426 428 470 550 700       SEEN-BY: 229/705 266/512 280/464 291/111 301/1 320/219 322/757 342/200       SEEN-BY: 396/45 460/58 633/280 712/848 902/26 5075/35       PATH: 103/705 218/700 229/426           |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
(c) 1994, bbs@darkrealms.ca