Subj : Is binkp/d's security model kaputt? To : deon From : Oli Date : Fri Sep 03 2021 11:16 am deon wrote (2021-09-02): >> I'm trying to figure out how to configure binkd for reliable >> security. I see several problems. Part design flaw of the binkp >> protocol (and FTN tradition), part implementation. >> IMHO binkd/binkp offers lots of pseudo security and several security >> and usability pitfalls. Are there any good workarounds or do we need >> a binkp/2.0? d> So I too, would love to see many improvements - that sees this retro d> hobby still function (with the retro software), but at the core, it d> leverages modern technologies for the benefits that they bring (improved d> security, improved authentication, improved authorisation, alternative d> transport methods). For me it's important that it is still simple and works for slow computers and slow connections. And what are modern technologies? Contemporary software is 80% bloat and waste of resources. I'm running Fidonet software, because I don't need 1GB of download and disk space to compile a rust application that does some basic stuff. Or run a messaging server in Python, that wastes a ton of bandwidth and is so complicated that the re-implementation in Go takes forever. Or software where the only supported installation method is a docker container in linux (which installs all the DB software you are already running again). But that is only a little general rant. I'm very much interested in any new developments in FTN land. What I would like to see is further simplification. The Fidonet standards are a convoluted mess. We have the message as the central building block. I wouldn't touch the message format, because that would break compatibility and would lead to a different network. Everything else can easily be changed. We can use another transmission protocol, just create a nodelist flag (or use DNS SRV records). We don't have to use PKT files (their not even a standard) for transmission. We can get rid of the weird and limited BSO. Tossing / routing could be handled differently ... d> I actually dont think a binkp/2.0 should do it all (but it probably d> could). I would also like to see other transport mediums in use - perhaps d> packet radio, perhaps something like lora - so that systems could d> communicate independantly of being dependant on a "service provider" d> (which means whatever is sent between 2 systems should be efficiently d> sent). Developing for IoT, low-bandwidth and unreliable connections is not a bad idea. I'm not sure if binkp is the best protocol for these types of transports. d> I have a few things to sort out with my new mailer, and then I'd be in a d> position to proto type something new - but I guess that's only useful if d> there is something else that uses it too. It would be nice to know that d> other mailer developers were inspired to make enhancements as well. Good luck with that ;-). Maybe BinkIt, but the rest? Binkd gets only bug fixes and even PRs get ignored. The last time I checked Mystic it was still a binkp/1.0 mailer. ifcico, mbcico, d'bridge, ...? The best chance would be a drop-in replacement for binkd. Or if it's based on another protocol, something that can run beside the binkp mailer and use the same BSO. --- * Origin: . (21:3/102) .