• Binkd 1.1a101 binaries for Win32, Win64, OS/2, DOS

    From Max Vasilyev@2:5057/77 to All on Sun Apr 19 02:41:30 2020
    Hello All!

    http://download.binkd.org
    http://sites.google.com/site/vasilyevmax/fido

    whatsnew:

    2020/04/05 20:33:09 git
    README.md,2.2,2.3
    Update README.md
    Fixed incorrect instructions and beautified the steps into a tested and verified cookbook style Howto.

    2020/01/30 10:21:49 1.1a-101 git
    client.c,2.109,2.110
    Fix an out-of-bounds error on sockaddrs.
    The `invalidAddresses` vector in `client.c` is used
    to hold invalid addresses `binkd` should not use.
    However, the array was of type `struct sockaddr`,
    which is not large enough to hold all of the
    protocol-specific data of the `struct sockaddr_*`
    structures. As a result, `binkd` would access
    out-of-bounds memory when examining elements of
    the array.

    Fixed by redefining `invalidAddresses` to be an
    array of type `struct sockaddr_storage`, which is
    guaranteed by POSIX to be large enough to hold all
    data associated with a socket address for any
    protocol family.

    Signed-off-by: Dan Cross <cross@fat-dragon.org>

    2020/01/30 10:21:13 1.1a-100 git
    client.c,2.108,2.109 ftnnode.c,2.50,2.51 iphdr.h,2.28,2.29 protocol.c,2.236,2.237 readcfg.c,2.113,2.114 readcfg.h,2.44,2.45
    Fix use-after-free bug in get_host_and_port.
    Don't use pointer assignment in this function,
    but rather, copy into a fixed-length buffer.

    Fixes #15

    Signed-off-by: Dan Cross <cross@fat-dragon.org>

    2019/01/23 09:16:18 git
    binkdfaq-en.txt,2.7,2.8 binkdfaq-ru.txt,2.7,2.8
    add a question on non-ASCII domains

    2018/05/14 22:32:57 git
    configure,2.56,2.57 configure.in,2.56,2.57
    Updated autoconf scripts

    * Originally in RU.BINKD
    * Crossposted in BINKD

    WBR, Max. piwamoto!ᥬ-
    --- FleetStreet' :-(((
    * Origin: Personal Reality (2:5057/77)
  • From Michiel van der Vlist@2:280/5555 to Max Vasilyev on Sun Apr 19 01:14:35 2020
    Hello Max,

    On Sunday April 19 2020 02:41, you wrote to All:

    http://download.binkd.org
    http://sites.google.com/site/vasilyevmax/fido

    D:\FIDO\BINKD>binkd binkd.cfg
    01:11 [1140] d:\fido\binkd\nodes.cfg: line 27: error in configuration files
    ? 01:11 [1140] -64: unknown option for `node' keyword
    ! 01:11 [1140] error in configuration, aborting


    D:\FIDO\BINKD>binkd -vv
    Binkd 1.1a-101-mv (Apr 18 2020 21:23:59/Win32)
    Compilation flags: mingw32, zlib, bzlib2, perldl, https, ntlm, amiga_4d_outbound, bwlim, ipv6.
    Facilities: fts5004 ipv6


    Cheers, Michiel

    --- GoldED+/W32-MSVC 1.1.5-b20170303
    * Origin: http://www.vlist.eu (2:280/5555)
  • From Michiel van der Vlist@2:280/5555 to Max Vasilyev on Sun Apr 19 10:46:29 2020
    Hello Max,

    Sunday April 19 2020 01:14, I wrote to you:

    The -64 and -46 options are missing in versions 101.

    I found this::

    D:\FIDO\BINKD\1-1A99>binkd -vv
    Binkd 1.1a-99 (Jun 25 2018 22:50:08/Win32)
    Compilation flags: mingw32, zlib, bzlib2, perldl, https, ntlm, amiga_4d_outbound, bwlim, ipv6, af_force.
    Facilities: fts5004 ipv6


    D:\FIDO\BINKD>binkd -vv
    Binkd 1.1a-101-mv (Apr 18 2020 21:23:59/Win32)
    Compilation flags: mingw32, zlib, bzlib2, perldl, https, ntlm, amiga_4d_outbound, bwlim, ipv6.
    Facilities: fts5004 ipv6

    The af_force compilation flag is missing in 101.

    Could this be the problem and if so can you recompile with af_force ?


    Cheers, Michiel

    --- GoldED+/W32-MSVC 1.1.5-b20170303
    * Origin: http://www.vlist.eu (2:280/5555)
  • From Tommi Koivula@2:221/1.1 to Michiel van der Vlist on Sun Apr 19 12:51:08 2020
    Hi Michiel.

    19 Apr 20 10:46:28, you wrote to Max Vasilyev:

    Sunday April 19 2020 01:14, I wrote to you:

    The -64 and -46 options are missing in versions 101.

    It is off by default.

    --with-af-force Enable soft AF force feature (default no)

    However, it is there in the Win64 version of Max:

    C:\bbs\BinkD>binkd64-static-perl-zlib-bzlib2.exe -vv
    Binkd 1.1a-101-mv (Apr 19 2020 01:55:52/Win64)
    Compilation flags: msvc, static, zlib, bzlib2, perl, https, ntlm, amiga_4d_outbound, bwlim, ipv6, af_force.
    Facilities: fts5004 ipv6

    Does anyone really need this option? :)

    'Tommi

    And BTW, the "official" -101 version still does not compile in OS/2...

    ---
    * Origin: IPv6 Point at [2001:470:1f15:cb0:2:221:1:1] (2:221/1.1)
  • From Michiel van der Vlist@2:280/5555 to Tommi Koivula on Sun Apr 19 14:00:17 2020
    Hello Tommi,

    On Sunday April 19 2020 12:51, you wrote to me:

    The -64 and -46 options are missing in versions 101.

    It is off by default.

    --with-af-force Enable soft AF force feature (default no)

    Max fixed it :)

    However, it is there in the Win64 version of Max:

    No good for me withold 32 bit hardware.

    Does anyone really need this option? :)

    I use it in the configuration for nodes that connectby 6to4.

    (Not surprising since I was the one to request it in the first place)

    And BTW, the "official" -101 version still does not compile in OS/2...

    But your version does ;-)

    Not my problem, I said goodbye to OS/2 over two decades ago. ;-)


    Cheers, Michiel

    --- GoldED+/W32-MSVC 1.1.5-b20170303
    * Origin: http://www.vlist.eu (2:280/5555)
  • From Tommi Koivula@2:221/360 to Michiel van der Vlist on Sun Apr 19 17:53:07 2020
    On 19.4.2020 15:00, Michiel van der Vlist : Tommi Koivula

    I use it in the configuration for nodes that connectby 6to4.

    (Not surprising since I was the one to request it in the first place)

    :D

    Others?

    And BTW, the "official" -101 version still does not compile in OS/2...

    But your version does ;-)

    Yes, but it is compiled from the source of "the other fellow". Which seems to work ok.

    Not my problem, I said goodbye to OS/2 over two decades ago. ;-)

    So says the Windows XP man. :D

    Amyways, as long OS/2 is supported by the binkd team, it would be nice that the current source compiles in OS/2.

    'Tommi

    --- Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0
    * Origin: nntp://rbb.fidonet.fi - Lake Ylo - Finland (2:221/360.0)
  • From Michiel van der Vlist@2:280/5555 to Tommi Koivula on Sun Apr 19 21:16:53 2020
    Hello Tommi,

    On Sunday April 19 2020 17:53, you wrote to me:

    I use it in the configuration for nodes that connectby 6to4.

    (Not surprising since I was the one to request it in the first place)

    :D

    Others?

    You have tp ask those others. ;-)

    And BTW, the "official" -101 version still does not compile in
    OS/2...

    But your version does ;-)

    Yes, but it is compiled from the source of "the other fellow". Which
    seems to work ok.

    At least you have a working version...

    Amyways, as long OS/2 is supported by the binkd team, it would be nice that the current source compiles in OS/2.

    I agree.

    Cheers, Michiel

    --- GoldED+/W32-MSVC 1.1.5-b20170303
    * Origin: http://www.vlist.eu (2:280/5555)
  • From Alexey Fayans@2:5030/1997 to Tommi Koivula on Mon Apr 20 08:00:16 2020
    Hello Tommi!

    On Sun, 19 Apr 2020 at 17:53 +0300, you wrote to Michiel van der Vlist:

    Amyways, as long OS/2 is supported by the binkd team, it would be nice that the current source compiles in OS/2.

    It will compile, most probably, once https://github.com/pgul/binkd/pull/17 is merged.


    ... Music Station BBS | https://bbs.bsrealm.net | telnet://bbs.bsrealm.net
    --- GoldED+/W32-MSVC 1.1.5-b20180707
    * Origin: Music Station | https://ms.bsrealm.net (2:5030/1997)
  • From Max Vasilyev@2:5057/19.1919 to Alexey Fayans on Mon Apr 20 10:00:21 2020
    Hello, Alexey Fayans.
    On 20.04.2020 08:00 you wrote:

    Hello Tommi! On Sun, 19 Apr 2020 at 17:53 +0300, you wrote to
    Michiel van der Vlist:
    Amyways, as long OS/2 is supported by the binkd team, it would be
    nice that the current source compiles in OS/2.
    It will compile, most probably, once https://github.com/pgul/binkd/pull/17 is merged.
    This patch gives only partial solution - for one compiler. It should not be merged.
    --- Hotdoged/2.13.5/Android
    * Origin: Android device, Milky Way (2:5057/19.1919)
  • From Alexey Fayans@2:5030/1997 to Max Vasilyev on Mon Apr 20 10:08:50 2020
    Hello Max!

    On Mon, 20 Apr 2020 at 10:00, you wrote to me:

    Hello Tommi! On Sun, 19 Apr 2020 at 17:53 +0300, you wrote to
    Michiel van der Vlist:
    Amyways, as long OS/2 is supported by the binkd team, it would
    be nice that the current source compiles in OS/2.
    It will compile, most probably, once
    https://github.com/pgul/binkd/pull/17 is merged.
    This patch gives only partial solution - for one compiler. It should
    not be merged.

    Well, it is planned for merging at least. And it fixes compilation with MSVC.

    If this is not enough, a new PR should be submitted.


    ... Music Station BBS | https://bbs.bsrealm.net | telnet://bbs.bsrealm.net
    --- GoldED+/W32-MSVC 1.1.5-b20180707
    * Origin: Music Station | https://ms.bsrealm.net (2:5030/1997)
  • From Dan Cross@1:229/101 to Tommi Koivula on Tue Apr 21 20:57:48 2020
    On 19 Apr 2020, Tommi Koivula said the following...

    Amyways, as long OS/2 is supported by the binkd team, it would be nice that the current source compiles in OS/2.

    Probably the best way to get this done is to ping the
    pull request on github. It's been sitting there for
    months. Two weeks ago, I was asked to change it slightly.
    I did, but ... that was two weeks ago.

    I'm no longer running binkd myself; I wrote my own binkp
    mailer instead. I'm not sure I trust binkd.

    --- Mystic BBS v1.12 A46 2020/04/13 (Linux/64)
    * Origin: % disksh0p!bbs % bbs.diskshop.ca % SciNet ftn hq % (1:229/101)
  • From Dan Cross@1:229/101 to Max Vasilyev on Tue Apr 21 20:58:44 2020
    On 20 Apr 2020, Max Vasilyev said the following...

    This patch gives only partial solution - for one compiler. It should not be merged.

    If you have an improved patch, by all means submit
    a pull request.

    --- Mystic BBS v1.12 A46 2020/04/13 (Linux/64)
    * Origin: % disksh0p!bbs % bbs.diskshop.ca % SciNet ftn hq % (1:229/101)
  • From Wilfred van Velzen@2:280/464.112 to Dan Cross on Wed Apr 22 08:32:29 2020
    Hi Dan,

    On 21 Apr 20 20:57, Dan Cross wrote to Tommi Koivula:
    about: "Re: -64 and -46 option missing in 101":

    I'm no longer running binkd myself; I wrote my own binkp
    mailer instead. I'm not sure I trust binkd.

    That needs explaining!?

    Wilfred.

    --- FMail-W32 2.0.1.4
    * Origin: point@work (2:280/464.112)
  • From Dan Cross@1:229/101 to Wilfred van Velzen on Wed Apr 22 12:54:00 2020
    On 22 Apr 2020, Wilfred van Velzen said the following...

    On 21 Apr 20 20:57, Dan Cross wrote to Tommi Koivula:

    I'm no longer running binkd myself; I wrote my own binkp
    mailer instead. I'm not sure I trust binkd.

    That needs explaining!?

    Sure. Which part of it?

    --- Mystic BBS v1.12 A46 2020/04/13 (Linux/64)
    * Origin: % disksh0p!bbs % bbs.diskshop.ca % SciNet ftn hq % (1:229/101)
  • From Wilfred van Velzen@2:280/464 to Dan Cross on Wed Apr 22 19:10:58 2020
    Hi Dan,

    On 2020-04-22 12:54:00, you wrote to me:

    I'm no longer running binkd myself; I wrote my own binkp
    mailer instead. I'm not sure I trust binkd.

    That needs explaining!?

    Sure. Which part of it?

    Why you don't trust binkd.

    Bye, Wilfred.

    --- FMail-lnx64 2.1.0.18-B20170815
    * Origin: FMail development HQ (2:280/464)
  • From Dan Cross@3:770/100 to Wilfred van Velzen on Thu Apr 23 07:30:55 2020
    On 22 Apr 2020 at 07:10p, Wilfred van Velzen pondered and said...

    On 2020-04-22 12:54:00, you wrote to me:
    Sure. Which part of it?

    Why you don't trust binkd.

    Ah. It's a lot of code, it's exquisitely complex,
    and it's written in a weakly-typed, unsafe language.

    The first time I tried to run it, I ran into a
    memory corruption issue that had lain dormant for
    two decades. Another memory-out-of-bounds bug
    showed up when it was compiled with IPv6 support.
    A filesystem permissions problem caused an
    infinite loop with no diagnostic. On my system,
    it mysteriously crashes *inside the Perl
    interpreter* when parsing nodelists; I some
    sort of memory corruption issue in binkd that
    manifests itself inside the Perl shared object.

    Finally, I'm not at all sure how resilient it
    is to avoiding data corruption in the event of
    failure (either binkd or the system).

    At that point, I realized I was faced with a
    decision: do I double down on binkd and attempt
    to fix it, or do I write my own replacement?

    The former involves ensuring compatibility with
    all sorts of legacy environments that I'm neither
    equipped nor interested in supporting (OS/2 and
    Win9x with ancient compilers, for example: even
    if I wanted to support those -- and let me be
    clear, I do not -- I don't have a development
    environment for them and while I could set one
    up, I'm just not interested) and that require
    workarounds for lacking features available in
    modern standards. The whole suite has very
    little in the way of unit-level tests, let alone
    integration style tests.

    And how much effort do I really want to put into
    it, anyway?

    The other option means I can make a clean break
    from the past, write in a type- and memory-safe
    language (I chose Go), write as many tests as I
    like, and take advantage of built-in support for
    modern testing practices etc. Further, I'm
    beholden to no one but myself to maintain
    compatibility. Since this is all just for fun
    anyway, I chose that route.

    --- Mystic BBS v1.12 A46 2020/04/20 (Windows/32)
    * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (3:770/100)
  • From Benny Pedersen@2:230/0 to Dan Cross on Thu Apr 30 07:11:12 2020
    Hello Dan!

    22 Apr 2020 12:54, Dan Cross wrote to Wilfred van Velzen:

    On 22 Apr 2020, Wilfred van Velzen said the following...

    On 21 Apr 20 20:57, Dan Cross wrote to Tommi Koivula:

    I'm no longer running binkd myself; I wrote my own binkp
    mailer instead. I'm not sure I trust binkd.

    That needs explaining!?

    Sure. Which part of it?

    will it be possible to get the source ?


    Regards Benny

    ... there can only be one way of life, and it works :)

    --- Msged/LNX 6.1.2 (Linux/5.6.7-gentoo-x86_64 (x86_64))
    * Origin: I will always keep a PC running CPM 3.0 (2:230/0)
  • From Benny Pedersen@2:230/0 to Wilfred van Velzen on Thu Apr 30 07:12:20 2020
    Hello Wilfred!

    22 Apr 2020 19:10, Wilfred van Velzen wrote to Dan Cross:

    I'm no longer running binkd myself; I wrote my own binkp
    mailer instead. I'm not sure I trust binkd.

    That needs explaining!?

    Sure. Which part of it?

    Why you don't trust binkd.

    maybe sending passwords in clear text is one of them ?


    Regards Benny

    ... there can only be one way of life, and it works :)

    --- Msged/LNX 6.1.2 (Linux/5.6.7-gentoo-x86_64 (x86_64))
    * Origin: I will always keep a PC running CPM 3.0 (2:230/0)
  • From Oli@2:280/464.47 to Benny Pedersen on Thu Apr 30 10:13:11 2020

    Why you don't trust binkd.

    maybe sending passwords in clear text is one of them ?

    it usually sends encrypted passwords and it's also possible to enforce CRAM-MD5

    # * '-md' means "Must have CRAM-MD5". This works only with the nodes using
    # versions of binkd or argus supporting this method. Do not set it if
    # your link can use an old version of binkd.


    * Origin: kakistocracy (2:280/464.47)
  • From Benny Pedersen@2:230/0 to Oli on Thu Apr 30 08:54:44 2020
    Hello Oli!

    30 Apr 2020 10:13, Oli wrote to Benny Pedersen:

    Why you don't trust binkd.

    maybe sending passwords in clear text is one of them ?

    it usually sends encrypted passwords and it's also possible to enforce CRAM-MD5

    # * '-md' means "Must have CRAM-MD5". This works only with the nodes using # versions of binkd or argus supporting this method. Do not set it
    if
    # your link can use an old version of binkd.

    and this is not working, binkd c code must ensure no clear text passwords is default, or atleast let clients drop connection BEFORE its sent !


    Regards Benny

    ... there can only be one way of life, and it works :)

    --- Msged/LNX 6.1.2 (Linux/5.6.7-gentoo-x86_64 (x86_64))
    * Origin: I will always keep a PC running CPM 3.0 (2:230/0)
  • From mark lewis@1:3634/12 to Benny Pedersen on Thu Apr 30 06:56:47 2020
    Re: Re: -64 and -46 option missing in 101
    By: Benny Pedersen to Wilfred van Velzen on Thu Apr 30 2020 07:12:20


    Sure. Which part of it?

    Why you don't trust binkd.

    maybe sending passwords in clear text is one of them ?

    like 8 character passwords aren't already easily brute forced, eh?


    )\/(ark
    --- SBBSecho 3.11-Linux
    * Origin: SouthEast Star Mail HUB - SESTAR (1:3634/12)
  • From Michiel van der Vlist@2:280/5555 to mark lewis on Thu Apr 30 14:18:35 2020
    Hello mark,

    On Thursday April 30 2020 06:56, you wrote to Benny Pedersen:

    Why you don't trust binkd.

    maybe sending passwords in clear text is one of them ?

    like 8 character passwords aren't already easily brute forced, eh?

    The session password in binkd is not limited to 8 characters. I do not know what the limit is or if there is a limit, but a test with 24 characters passed. And BTW it is case
    sensitive.


    Cheers, Michiel

    --- GoldED+/W32-MSVC 1.1.5-b20170303
    * Origin: http://www.vlist.eu (2:280/5555)
  • From Alexey Fayans@2:5030/1997 to Benny Pedersen on Thu Apr 30 15:34:15 2020
    Hello Benny!

    On Thu, 30 Apr 2020 at 08:54 +0000, you wrote to Oli:

    and this is not working, binkd c code must ensure no clear text
    passwords is default, or atleast let clients drop connection BEFORE
    its sent !

    This is working. You just disabled it somehow. Probably by starting binkd with -m flag.


    ... Music Station BBS | https://bbs.bsrealm.net | telnet://bbs.bsrealm.net
    --- GoldED+/W32-MSVC 1.1.5-b20180707
    * Origin: Music Station | https://ms.bsrealm.net (2:5030/1997)
  • From Alexey Fayans@2:5030/1997 to Benny Pedersen on Thu Apr 30 15:36:01 2020
    Hello Benny!

    On Thu, 30 Apr 2020 at 08:54 +0000, you wrote to Oli:

    # * '-md' means "Must have CRAM-MD5". This works only with the
    nodes using # versions of binkd or argus supporting this
    method. Do not set it if # your link can use an old version
    of binkd.
    and this is not working,

    This is working. You just disabled it somehow. Probably by starting binkd with -m flag.

    binkd c code must ensure no clear text
    passwords is default

    defnode -md

    or atleast let clients drop connection BEFORE
    its sent !

    defnode -md


    ... Music Station BBS | https://bbs.bsrealm.net | telnet://bbs.bsrealm.net
    --- GoldED+/W32-MSVC 1.1.5-b20180707
    * Origin: Music Station | https://ms.bsrealm.net (2:5030/1997)
  • From Benny Pedersen@2:230/0 to mark lewis on Fri May 1 14:32:46 2020
    Hello mark!

    30 Apr 2020 06:56, mark lewis wrote to Benny Pedersen:

    like 8 character passwords aren't already easily brute forced, eh?

    another problem to solve

    openssl will not solve week passwords


    Regards Benny

    ... there can only be one way of life, and it works :)

    --- Msged/LNX 6.1.2 (Linux/5.6.7-gentoo-x86_64 (x86_64))
    * Origin: I will always keep a PC running CPM 3.0 (2:230/0)
  • From Benny Pedersen@2:230/0 to Michiel van der Vlist on Fri May 1 14:34:08 2020
    Hello Michiel!

    30 Apr 2020 14:18, Michiel van der Vlist wrote to mark lewis:

    like 8 character passwords aren't already easily brute forced, eh?

    MvdV> The session password in binkd is not limited to 8 characters. I do
    MvdV> not know what the limit is or if there is a limit, but a test with
    MvdV> 24 characters passed. And BTW it is case sensitive.

    where have Mark being missinformated ? :)

    lets hope binkd will support openssl soon, so we could close this problem of plain text passwords

    i have added defnode -md

    and none care of it


    Regards Benny

    ... there can only be one way of life, and it works :)

    --- Msged/LNX 6.1.2 (Linux/5.6.7-gentoo-x86_64 (x86_64))
    * Origin: I will always keep a PC running CPM 3.0 (2:230/0)
  • From Benny Pedersen@2:230/0 to Alexey Fayans on Fri May 1 14:36:28 2020
    Hello Alexey!

    30 Apr 2020 15:34, Alexey Fayans wrote to Benny Pedersen:

    This is working. You just disabled it somehow. Probably by starting
    binkd with -m flag.

    nope defnode is in my config # commented, so default in c code is default allow plain passwords


    Regards Benny

    ... there can only be one way of life, and it works :)

    --- Msged/LNX 6.1.2 (Linux/5.6.7-gentoo-x86_64 (x86_64))
    * Origin: I will always keep a PC running CPM 3.0 (2:230/0)
  • From Tommi Koivula@2:221/1.1 to Benny Pedersen on Fri May 1 18:09:10 2020
    Hi Benny.

    01 May 20 14:34:08, you wrote to Michiel van der Vlist:

    i have added defnode -md

    18:08 [24840] BEGIN, binkd/1.1a-104/CYGWIN_NT-6.1-7601 -pP 230/0 binkd.cfg
    18:08 [24840] creating a poll for 2:230/0@fidonet (`d' flavour)
    18:08 [24840] clientmgr started
    18:08 [24841] call to 2:230/0@fidonet
    18:08 [24841] trying f0.n230.z2.binkp.net. [2a01:7e01::f03c:91ff:fe0b:7bf9]..
    18:08 [24841] connected
    18:08 [24841] outgoing session with f0.n230.z2.binkp.net:24554 [2a01:7e01::f0
    18:08 [24841] SYS gentoo binkd node in region23
    18:08 [24841] ZYZ Benny Pedersen
    18:08 [24841] LOC Jersore, Danmark
    18:08 [24841] NDL 300,TCP,BINKP
    18:08 [24841] TIME Fri, 1 May 2020 15:08:20 +0000
    18:08 [24841] VER binkd/1.1a-101/Linux binkp/1.1
    18:08 [24841] addr: 2:230/0@fidonet
    18:08 [24841] addr: 2:230/38@fidonet
    18:08 [24841] addr: 39:14/0@Amiganet (n/a or busy)
    18:08 [24841] addr: 39:140/0@Amiganet (n/a or busy)
    18:08 [24841] addr: 39:140/127@Amiganet (n/a or busy)
    18:08 [24841] CRAM-MD5 is not supported by remote
    18:08 [24841] done (to 2:230/0@fidonet, failed, S/R: 0/0 (0/0 bytes))
    18:08 [24841] session closed, quitting...
    18:08 [24840] rc(24841)=0
    18:08 [24840] the queue is empty, quitting...

    Still "CRAM-MD5 is not supported by remote".

    Have a nice labour day!

    'Tommi

    ---
    * Origin: IPv6 Point at [2001:470:1f15:cb0:2:221:1:1] (2:221/1.1)
  • From Michiel van der Vlist@2:280/5555 to Benny Pedersen on Fri May 1 17:39:18 2020
    Hello Benny,

    On Friday May 01 2020 14:34, you wrote to me:

    lets hope binkd will support openssl soon, so we could close this
    problem of plain text passwords

    There is no problem with plain text passwords.


    Cheers, Michiel

    --- GoldED+/W32-MSVC 1.1.5-b20170303
    * Origin: http://www.vlist.eu (2:280/5555)
  • From Andrew Leary@1:320/219 to Michiel van der Vlist on Fri May 1 11:58:33 2020
    Hello Michiel!

    30 Apr 20 14:18, you wrote to mark lewis:

    The session password in binkd is not limited to 8 characters. I do not know what the limit is or if there is a limit, but a test with 24 characters passed. And BTW it is case sensitive.

    Correct. Session passwords in FTS-1/6 sessions are limited to 8 characters and are processed case insensitively. EMSI removes the 8 character limit, but still is case insensitive.

    Andrew

    --- GoldED+/LNX 1.1.5-b20180707
    * Origin: Phoenix BBS * phoenix.bnbbbs.net (1:320/219)
  • From Benny Pedersen@2:230/0 to Tommi Koivula on Fri May 1 18:02:58 2020
    Hello Tommi!

    01 May 2020 18:09, Tommi Koivula wrote to Benny Pedersen:

    18:08 [24841] VER binkd/1.1a-101/Linux binkp/1.1
    18:08 [24841] CRAM-MD5 is not supported by remote
    18:08 [24841] done (to 2:230/0@fidonet, failed, S/R: 0/0 (0/0 bytes))

    you enforce it to be there now so it failed ?

    Still "CRAM-MD5 is not supported by remote".

    how to enabled it is still unclear

    Have a nice labour day!

    its a rainy day, so its fucked :)


    Regards Benny

    ... there can only be one way of life, and it works :)

    --- Msged/LNX 6.1.2 (Linux/5.6.7-gentoo-x86_64 (x86_64))
    * Origin: I will always keep a PC running CPM 3.0 (2:230/0)
  • From Benny Pedersen@2:230/0 to Michiel van der Vlist on Fri May 1 18:04:40 2020
    Hello Michiel!

    01 May 2020 17:39, Michiel van der Vlist wrote to Benny Pedersen:

    lets hope binkd will support openssl soon, so we could close this
    problem of plain text passwords

    MvdV> There is no problem with plain text passwords.

    thanks for intrests of helping as always not usefull of solving it


    Regards Benny

    ... there can only be one way of life, and it works :)

    --- Msged/LNX 6.1.2 (Linux/5.6.7-gentoo-x86_64 (x86_64))
    * Origin: I will always keep a PC running CPM 3.0 (2:230/0)
  • From Benny Pedersen@2:230/0 to Andrew Leary on Fri May 1 18:06:54 2020
    Hello Andrew!

    01 May 2020 11:58, Andrew Leary wrote to Michiel van der Vlist:

    The session password in binkd is not limited to 8 characters. I do not
    know what the limit is or if there is a limit, but a test with 24
    characters passed. And BTW it is case sensitive.

    +1

    Correct. Session passwords in FTS-1/6 sessions are limited to 8 characters and are processed case insensitively.

    +1

    EMSI removes the 8 character limit, but
    still is case insensitive.

    limited intrest of make binkd better with openssl, it will break old front ends but changes can be ported to make it more secure then plain passwords, i remember amiga trapdoor support emsi and last one iemsi aswell so bbs login was automatic, only xenolink and if i remember it all zeus have stealed it from xenolink :)

    linux based front ends that support emsi or iemsi ?

    only one i know is qico that support emsi, but i dont know any that have iemsi, maybe mysticbbs ?


    Regards Benny

    ... there can only be one way of life, and it works :)

    --- Msged/LNX 6.1.2 (Linux/5.6.7-gentoo-x86_64 (x86_64))
    * Origin: I will always keep a PC running CPM 3.0 (2:230/0)
  • From mark lewis@1:3634/12 to Benny Pedersen on Fri May 1 14:14:08 2020
    Re: -64 and -46 option missing in 101
    By: Benny Pedersen to Michiel van der Vlist on Fri May 01 2020 14:34:08


    like 8 character passwords aren't already easily brute forced, eh?

    MvdV>> The session password in binkd is not limited to 8 characters. I do
    MvdV>> not know what the limit is or if there is a limit, but a test with
    MvdV>> 24 characters passed. And BTW it is case sensitive.

    where have Mark being missinformated ? :)

    i wasn't misinformed... i was thinking about mailers that validate inbound packet passwords with the session password based on traditional FTN methods... packets have max eight characters for passwords so there we are...


    )\/(ark
    --- SBBSecho 3.11-Linux
    * Origin: SouthEast Star Mail HUB - SESTAR (1:3634/12)
  • From Tommi Koivula@2:221/1.1 to mark lewis on Fri May 1 22:18:06 2020
    Hi mark.

    01 May 20 14:14:08, you wrote to Benny Pedersen:

    like 8 character passwords aren't already easily brute forced,
    eh?

    MvdV>>> The session password in binkd is not limited to 8 characters.
    MvdV>>> I do not know what the limit is or if there is a limit, but a
    MvdV>>> test with 24 characters passed. And BTW it is case sensitive.

    where have Mark being missinformated ? :)

    i wasn't misinformed... i was thinking about mailers that validate
    inbound packet passwords with the session password based on
    traditional FTN methods... packets have max eight characters for
    passwords so there we are...

    The best way is to set the same pkt and session password. Even if it is possible define all these seperately in binkd.

    node ... [{<inpwd>[,[<pktpwd>][,<outpwd>]]|-}

    'Tommi

    ---
    * Origin: IPv6 Point at [2001:470:1f15:cb0:2:221:1:1] (2:221/1.1)
  • From Alan Ianson@1:153/757 to Benny Pedersen on Fri May 1 12:51:40 2020
    Hello Benny,

    only one i know is qico that support emsi, but i dont know any that
    have iemsi, maybe mysticbbs ?

    No, Mystic only supports binkp/1.0, no emsi or iemsi.

    Ttyl :-),
    Al

    --- GoldED+/LNX
    * Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)
  • From mark lewis@1:3634/12 to Tommi Koivula on Fri May 1 16:01:19 2020
    Re: -64 and -46 option missing in 101
    By: Tommi Koivula to mark lewis on Fri May 01 2020 22:18:06


    i wasn't misinformed... i was thinking about mailers that validate
    inbound packet passwords with the session password based on
    traditional FTN methods... packets have max eight characters for
    passwords so there we are...

    The best way is to set the same pkt and session password.

    exactly and since the packet header has only eight characters allocated for the packet password, there we are ;)

    Even if it is possible define all these seperately in binkd.

    node ... [{<inpwd>[,[<pktpwd>][,<outpwd>]]|-}

    now that i wasn't aware of... interesting...


    )\/(ark
    --- SBBSecho 3.11-Linux
    * Origin: SouthEast Star Mail HUB - SESTAR (1:3634/12)
  • From Michiel van der Vlist@2:280/5555 to mark lewis on Fri May 1 22:20:56 2020
    Hello mark,

    On Friday May 01 2020 16:01, you wrote to Tommi Koivula:

    The best way is to set the same pkt and session password.

    exactly and since the packet header has only eight characters
    allocated for the packet password, there we are ;)

    Binkd does nothing with the packets. As you once said it is "just a filer". It is other software, such as a tosser that deals with the packets. There is nothing stopping sysops from having the binkd session password different from the tosser's packet password.

    In fact some say NOT having them the same increases security.


    Cheers, Michiel

    --- GoldED+/W32-MSVC 1.1.5-b20170303
    * Origin: http://www.vlist.eu (2:280/5555)
  • From mark lewis@1:3634/12 to Michiel van der Vlist on Fri May 1 16:41:00 2020
    Re: -64 and -46 option missing in 101
    By: Michiel van der Vlist to mark lewis on Fri May 01 2020 22:20:56


    The best way is to set the same pkt and session password.

    exactly and since the packet header has only eight characters
    allocated for the packet password, there we are ;)

    MvdV> Binkd does nothing with the packets. As you once said it is "just
    MvdV> a filer". It is other software, such as a tosser that deals with
    MvdV> the packets. There is nothing stopping sysops from having the
    MvdV> binkd session password different from the tosser's packet password.

    on the one hand, this is true... if one is talking about binkd... my part of the discussion was leaning more toward binkp, though...

    i'm not saying that it is correct for mailers to validate packets against the session password... i'm just saying that there are/were some that do/did...

    MvdV> In fact some say NOT having them the same increases security.

    yeah, i've heard that, too ;)


    )\/(ark
    --- SBBSecho 3.11-Linux
    * Origin: SouthEast Star Mail HUB - SESTAR (1:3634/12)
  • From Deon George@3:633/509 to Benny Pedersen on Sat May 2 10:43:06 2020
    Re: -64 and -46 option missing in 101
    By: Benny Pedersen to Andrew Leary on Fri May 01 2020 06:06 pm

    only one i know is qico that support emsi, but i dont know any that have iemsi, maybe mysticbbs ?

    Havent really followed this thread.

    But I have QICO (and IFCICO) working with DB, FD and POP...
    ...

    ... When you smell an odourless gas, it is probably carbon monoxide.
    --- SBBSecho 3.10-Linux
    * Origin: I'm playing with ANSI+videotex - wanna play too? (3:633/509)
  • From Tony Langdon@3:633/410 to Benny Pedersen on Sat May 2 15:58:00 2020
    On 05-01-20 18:06, Benny Pedersen wrote to Andrew Leary <=-

    only one i know is qico that support emsi, but i dont know any that
    have iemsi, maybe mysticbbs ?

    AFAIK, Mystic only supports BinkP.


    ... An alcoholic is someone you don't like who drinks as much as you do.
    === MultiMail/Win v0.51
    --- SBBSecho 3.10-Linux
    * Origin: Freeway BBS Bendigo,Australia freeway.apana.org.au (3:633/410)
  • From Tony Langdon@3:633/410 to Tommi Koivula on Sat May 2 16:00:00 2020
    On 05-01-20 22:18, Tommi Koivula wrote to mark lewis <=-

    The best way is to set the same pkt and session password. Even if it is possible define all these seperately in binkd.

    Why is that the best? Given the different capabilities, one could argue that it's better to use different passwords, so the session password can be stronger
    than the PKT password is capable of. Make use of BinkP's better password capabilities.


    ... "Kills millions of germs on contract"
    === MultiMail/Win v0.51
    --- SBBSecho 3.10-Linux
    * Origin: Freeway BBS Bendigo,Australia freeway.apana.org.au (3:633/410)
  • From Tony Langdon@3:633/410 to mark lewis on Sat May 2 16:17:00 2020
    On 05-01-20 16:41, mark lewis wrote to Michiel van der Vlist <=-

    i'm not saying that it is correct for mailers to validate packets
    against the session password... i'm just saying that there are/were
    some that do/did...

    Deal with those on a case by case basis.

    MvdV> In fact some say NOT having them the same increases security.

    yeah, i've heard that, too ;)

    And I happen to agree. Systems like Synchronet and Mystic can use different session and PKT passwords. I think (but could be wrong) that D-Bridge is one system that requires the session and PKT passwords to be the same. But as I said, that's something I deal with on a per link basis.


    ... There are always alternatives. Spock, The Galileo Seven, stardate 2822.3. === MultiMail/Win v0.51
    --- SBBSecho 3.10-Linux
    * Origin: Freeway BBS Bendigo,Australia freeway.apana.org.au (3:633/410)
  • From Michiel van der Vlist@2:280/5555 to mark lewis on Sat May 2 10:29:04 2020
    Hello mark,

    On Friday May 01 2020 16:41, you wrote to me:

    MvdV>> Binkd does nothing with the packets. As you once said it is "just a
    MvdV>> filer". It is other software, such as a tosser that deals with the
    MvdV>> packets. There is nothing stopping sysops from having the binkd
    MvdV>> session password different from the tosser's packet password.

    on the one hand, this is true... if one is talking about binkd...

    This is the binkd area. The word "binkd "appears twice in my above comment. The source of this subthread is Benny P. miouwing about an alleged "clear text password problem" in binkd. Of course I am talking about binkd.

    my part of the discussion was leaning more toward binkp, though...

    You neglected to inform the audience about that change of context...

    Plus that I see no mention of an 8 characer limitation on the password in the binkp docs...

    i'm not saying that it is correct for mailers to validate packets
    against the session password... i'm just saying that there are/were
    some that do/did...

    Irrelevant what some others do/did. We are not discussing those others, we are discussing session passwords in binkd.

    MvdV>> In fact some say NOT having them the same increases security.

    yeah, i've heard that, too ;)

    I agree with "some". A 24 byte non ASCII case sensitive password is harder to brute force than an 8 character case insensitive ASCII password. ==> increasd security.


    Cheers, Michiel

    --- Fmail, Binkd, Golded
    * Origin: http://www.vlist.eu (2:280/5555)
  • From Tommi Koivula@2:221/1.1 to Michiel van der Vlist on Sat May 2 12:33:30 2020
    Hi Michiel.

    01 May 20 22:20:56, you wrote to mark lewis:

    The best way is to set the same pkt and session password.

    exactly and since the packet header has only eight characters
    allocated for the packet password, there we are ;)

    Binkd does nothing with the packets.

    *YOUR* binkd perhaps does not, but Binkd *CAN* do some basic routing and .PKT checking.

    'Tommi

    ---
    * Origin: IPv6 Point at [2001:470:1f15:cb0:2:221:1:1] (2:221/1.1)
  • From Tommi Koivula@2:221/1.1 to Tony Langdon on Sat May 2 12:37:18 2020
    Hi Tony.

    02 May 20 16:00:00, you wrote to me:

    On 05-01-20 22:18, Tommi Koivula wrote to mark lewis <=-

    The best way is to set the same pkt and session password. Even
    if it is possible define all these seperately in binkd.

    Why is that the best?

    Ok, "best" may be wrong word. :)

    'Tommi

    ---
    * Origin: IPv6 Point at [2001:470:1f15:cb0:2:221:1:1] (2:221/1.1)
  • From Tony Langdon@3:633/410 to Tommi Koivula on Sat May 2 21:09:00 2020
    On 05-02-20 12:37, Tommi Koivula wrote to Tony Langdon <=-

    Why is that the best?

    Ok, "best" may be wrong word. :)

    Haha OK, so what was the appropriate word? Convenient?


    ... Hack the planet!
    === MultiMail/Win v0.51
    --- SBBSecho 3.10-Linux
    * Origin: Freeway BBS Bendigo,Australia freeway.apana.org.au (3:633/410)
  • From Tommi Koivula@2:221/0 to Tony Langdon on Sat May 2 15:09:02 2020
    Hello, Tony Langdon.
    On 02/05/2020 21.09 you wrote:

    On 05-02-20 12:37, Tommi Koivula wrote to Tony Langdon <=-
    Why is that the best?
    Ok, "best" may be wrong word. :)
    Haha OK, so what was the appropriate word? Convenient?

    Or 'maximum compatibility' :)

    Tommi

    ---
    * Origin: rbb.fidonet.fi (2:221/0)
  • From Alexey Fayans@2:5030/1997 to Benny Pedersen on Sat May 2 16:39:28 2020
    Hello Benny!

    On Fri, 01 May 2020 at 14:36 +0000, you wrote to me:

    This is working. You just disabled it somehow. Probably by
    starting binkd with -m flag.
    nope defnode is in my config # commented, so default in c code is
    default allow plain passwords

    Default Apache, nginx and most (all?) other web servers are configured for HTTP protocol, HTTPS is not even enabled in default installation.

    So either change defaults in source code to your likings or just create some sane configuration.


    ... Music Station BBS | https://bbs.bsrealm.net | telnet://bbs.bsrealm.net
    --- GoldED+/W32-MSVC 1.1.5-b20180707
    * Origin: Music Station | https://ms.bsrealm.net (2:5030/1997)
  • From Alexey Fayans@2:5030/1997 to Benny Pedersen on Sat May 2 16:39:57 2020
    Hello Benny!

    On Fri, 01 May 2020 at 18:02 +0000, you wrote to Tommi Koivula:

    Still "CRAM-MD5 is not supported by remote".
    how to enabled it is still unclear

    Since you never answered about the command line switches you are running binkd with, I suggest that you are running it with -m switch, which is the only way to disable CRAM-MD5.


    ... Music Station BBS | https://bbs.bsrealm.net | telnet://bbs.bsrealm.net
    --- GoldED+/W32-MSVC 1.1.5-b20180707
    * Origin: Music Station | https://ms.bsrealm.net (2:5030/1997)
  • From Dan Cross@3:770/100 to Benny Pedersen on Sun May 3 03:05:21 2020
    On 30 Apr 2020 at 07:12a, Benny Pedersen pondered and said...

    maybe sending passwords in clear text is one of them ?

    That's certainly bad, but that's a function of the
    protocol, not a specific software package.

    --- Mystic BBS v1.12 A46 2020/04/20 (Windows/32)
    * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (3:770/100)
  • From Dan Cross@3:770/100 to Benny Pedersen on Sun May 3 03:06:24 2020
    On 30 Apr 2020 at 07:11a, Benny Pedersen pondered and said...

    will it be possible to get the source ?

    Yeah sure; I'll throw it up on github. It's not complete,
    but I've been unable to work on it recently due to time
    constraints.

    --- Mystic BBS v1.12 A46 2020/04/20 (Windows/32)
    * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (3:770/100)
  • From Dan Cross@3:770/100 to Dan Cross on Sun May 3 03:52:38 2020
    On 03 May 2020 at 03:06a, Dan Cross pondered and said...

    Yeah sure; I'll throw it up on github. It's not complete,
    but I've been unable to work on it recently due to time
    constraints.

    So the current WIP is here: https://github.com/fat-dragon/ginko
    Like I said, it's not complete, but it reliably receives packets
    on fsxnet.

    --- Mystic BBS v1.12 A46 2020/04/20 (Windows/32)
    * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (3:770/100)
  • From Benny Pedersen@2:230/0 to Tommi Koivula on Sat May 2 19:11:36 2020
    Hello Tommi!

    02 May 2020 12:33, Tommi Koivula wrote to Michiel van der Vlist:

    *YOUR* binkd perhaps does not, but Binkd *CAN* do some basic routing
    and .PKT checking.

    only need perl hooks in binkd :)


    Regards Benny

    ... there can only be one way of life, and it works :)

    --- Msged/LNX 6.1.2 (Linux/5.6.7-gentoo-x86_64 (x86_64))
    * Origin: I will always keep a PC running CPM 3.0 (2:230/0)
  • From Benny Pedersen@2:230/0 to Alexey Fayans on Sat May 2 19:12:38 2020
    Hello Alexey!

    02 May 2020 16:39, Alexey Fayans wrote to Benny Pedersen:

    So either change defaults in source code to your likings or just
    create some sane configuration.

    i think why is binkd options supporting disable things that should not be global but could be more usefull in node ...

    anyway dont start binkd with -mr

    will make a new ebuild next week where this fail is solved

    in c code i could remove this shit :)


    Regards Benny

    ... there can only be one way of life, and it works :)

    --- Msged/LNX 6.1.2 (Linux/5.6.7-gentoo-x86_64 (x86_64))
    * Origin: I will always keep a PC running CPM 3.0 (2:230/0)
  • From Benny Pedersen@2:230/0 to Alexey Fayans on Sat May 2 19:15:24 2020
    Hello Alexey!

    02 May 2020 16:39, Alexey Fayans wrote to Benny Pedersen:

    Since you never answered about the command line switches you are
    running binkd with, I suggest that you are running it with -m switch, which is the only way to disable CRAM-MD5.

    all solved now


    Regards Benny

    ... there can only be one way of life, and it works :)

    --- Msged/LNX 6.1.2 (Linux/5.6.7-gentoo-x86_64 (x86_64))
    * Origin: I will always keep a PC running CPM 3.0 (2:230/0)
  • From Benny Pedersen@2:230/0 to Dan Cross on Sat May 2 19:16:18 2020
    Hello Dan!

    03 May 2020 03:06, Dan Cross wrote to Benny Pedersen:

    will it be possible to get the source ?

    Yeah sure; I'll throw it up on github. It's not complete,
    but I've been unable to work on it recently due to time
    constraints.

    super thanks, post link when its there, no hurry needed


    Regards Benny

    ... there can only be one way of life, and it works :)

    --- Msged/LNX 6.1.2 (Linux/5.6.7-gentoo-x86_64 (x86_64))
    * Origin: I will always keep a PC running CPM 3.0 (2:230/0)
  • From Tommi Koivula@2:221/6 to Benny Pedersen on Sat May 2 22:29:30 2020
    Hello, Benny Pedersen.
    On 02/05/2020 19:11 you wrote:

    Hello Tommi!
    02 May 2020 12:33, Tommi Koivula wrote to Michiel van der Vlist:
    *YOUR* binkd perhaps does not, but Binkd *CAN* do some basic routing
    and .PKT checking.
    only need perl hooks in binkd :)

    No.


    --
    Tommi

    ---
    * Origin: nntps://news.fidonet.fi (2:221/6.0)
  • From Dan Cross@3:770/100 to Benny Pedersen on Sun May 3 08:36:20 2020
    On 02 May 2020 at 07:16p, Benny Pedersen pondered and said...

    Yeah sure; I'll throw it up on github. It's not complete,
    but I've been unable to work on it recently due to time
    constraints.

    super thanks, post link when its there, no hurry needed

    Here you go: https://github.com/fat-dragon/ginko

    --- Mystic BBS v1.12 A46 2020/04/20 (Windows/32)
    * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (3:770/100)
  • From Kees van Eeten@2:280/5003.4 to Benny Pedersen on Sat May 2 23:17:54 2020
    Hello Benny!

    02 May 20 19:15, you wrote to Alexey Fayans:

    all solved now

    - 02 May 23:13:31 [13572] SYS gentoo binkd node in region23
    - 02 May 23:13:31 [13572] ZYZ Benny Pedersen
    - 02 May 23:13:31 [13572] LOC Jersore, Danmark
    - 02 May 23:13:31 [13572] NDL 300,TCP,BINKP
    - 02 May 23:13:31 [13572] TIME Sat, 2 May 2020 21:13:32 +0000
    - 02 May 23:13:31 [13572] VER binkd/1.1a-101/Linux binkp/1.1
    + 02 May 23:13:31 [13572] addr: 2:230/0@fidonet
    + 02 May 23:13:31 [13572] addr: 2:230/38@fidonet
    - 02 May 23:13:31 [13572] OPT NDA EXTCMD CRYPT GZ BZ2
    + 02 May 23:13:31 [13572] Remote requests CRYPT mode
    - 02 May 23:13:31 [13572] TRF 0 0
    + 02 May 23:13:31 [13572] Remote has 0b of mail and 0b of files for us
    + 02 May 23:13:31 [13572] pwd protected session (MD5)
    - 02 May 23:13:31 [13572] session in CRYPT mode

    Solved indeed.

    Kees

    --- GoldED+/LNX 1.1.5--b20180707
    * Origin: As for me, all I know is that, I know nothing. (2:280/5003.4)
  • From Benny Pedersen@2:230/0 to Kees van Eeten on Sat May 2 22:02:32 2020
    Hello Kees!

    02 May 2020 23:17, Kees van Eeten wrote to Benny Pedersen:

    + 02 May 23:13:31 [13572] pwd protected session (MD5)
    Solved indeed.

    good, thanks for notify me and long testing :)


    Regards Benny

    ... there can only be one way of life, and it works :)

    --- Msged/LNX 6.1.2 (Linux/5.6.7-gentoo-x86_64 (x86_64))
    * Origin: I will always keep a PC running CPM 3.0 (2:230/0)
  • From Tony Langdon@3:633/410 to Tommi Koivula on Sun May 3 13:50:00 2020
    On 05-02-20 15:09, Tommi Koivula wrote to Tony Langdon <=-

    Haha OK, so what was the appropriate word? Convenient?

    Or 'maximum compatibility' :)

    That does work for those few mailers that insist on them being the same. But as I said, I deal with those as needed. :)


    ... It's only a hobby ... only a hobby ... only a
    === MultiMail/Win v0.51
    --- SBBSecho 3.10-Linux
    * Origin: Freeway BBS Bendigo,Australia freeway.apana.org.au (3:633/410)
  • From Tommi Koivula@2:221/1 to Benny Pedersen on Sun May 3 10:25:46 2020

    02 May 20 19:15, Benny Pedersen wrote to Alexey Fayans:

    Since you never answered about the command line switches you are
    running binkd with, I suggest that you are running it with -m switch,
    which is the only way to disable CRAM-MD5.

    all solved now

    Yeah, no more insecure connections. :D

    === Cut ===
    10:24 [19245] creating a poll for 2:230/0@fidonet (`d' flavour)
    10:24 [19245] clientmgr started
    10:24 [19246] call to 2:230/0@fidonet
    10:24 [19246] trying f0.n230.z2.binkp.net. [2a01:7e01::f03c:91ff:fe0b:7bf9]..
    10:24 [19246] connection to 2:230/0@fidonet failed: Connection refused
    10:24 [19246] trying f0.n230.z2.binkp.net. [172.104.248.211]...
    10:24 [19246] connection to 2:230/0@fidonet failed: Connection refused
    10:24 [19246] holding 2:230/0@fidonet (2020/05/03 10:34:57)
    10:24 [19245] rc(19246)=0
    10:24 [19245] the queue is empty, quitting...
    === Cut ===

    'Tommi

    ---
    * Origin: rbb.fidonet.fi (2:221/1)
  • From Michiel van der Vlist@2:280/5555 to Tommi Koivula on Sun May 3 09:17:07 2020
    Hello Tommi,

    On Saturday May 02 2020 12:33, you wrote to me:

    Binkd does nothing with the packets.

    *YOUR* binkd perhaps does not, but Binkd *CAN* do some basic routing
    and .PKT checking.

    OK, I stand corrected. In my systemm, binkd does nothing with the packets other than move them from one system to another. I let the tosser handle the est. I see no added value in deploying binkd's very limited capavilities to do something with packets on top of that.

    I still say: there is no reason to limit the binkd session password to 8 characters just becasue the packet password has that limitation.


    Cheers, Michiel

    --- GoldED+/W32-MSVC 1.1.5-b20170303
    * Origin: http://www.vlist.eu (2:280/5555)
  • From Michiel van der Vlist@2:280/5555 to Tommi Koivula on Sun May 3 09:23:52 2020
    Hello Tommi,

    On Saturday May 02 2020 15:09, you wrote to Tony Langdon:

    Why is that the best?
    Ok, "best" may be wrong word. :)
    Haha OK, so what was the appropriate word? Convenient?

    Or 'maximum compatibility' :)

    Compatibility with what? Passwords are like keys. They are designed fo maximum uniqueness, NOT compatibility.


    Cheers, Michiel

    --- GoldED+/W32-MSVC 1.1.5-b20170303
    * Origin: http://www.vlist.eu (2:280/5555)
  • From Tommi Koivula@2:221/1 to Benny Pedersen on Sun May 3 10:42:50 2020

    02 May 20 22:02, Benny Pedersen wrote to Kees van Eeten:

    Hello Kees!

    02 May 2020 23:17, Kees van Eeten wrote to Benny Pedersen:

    + 02 May 23:13:31 [13572] pwd protected session (MD5)
    Solved indeed.

    good, thanks for notify me and long testing :)

    === Cut ===
    03 May 03:58:32 [51674] incoming session with region23.dk [172.104.248.211]
    03 May 03:58:32 [51674] pwd protected session (MD5)
    03 May 03:58:32 [51674] session in CRYPT mode
    03 May 03:58:32 [51674] done (from 2:230/0@fidonet, OK, S/R: 0/0 (0/0 bytes)) === Cut ===

    :)

    What was the solution?

    'Tommi

    ---
    * Origin: rbb.fidonet.fi (2:221/1)
  • From Tommi Koivula@2:221/1 to Michiel van der Vlist on Sun May 3 10:47:02 2020
    03 May 20 09:23, Michiel van der Vlist wrote to Tommi Koivula:

    Why is that the best?
    Ok, "best" may be wrong word. :)
    Haha OK, so what was the appropriate word? Convenient?

    Or 'maximum compatibility' :)

    Compatibility with what? Passwords are like keys. They are designed fo
    maximum
    uniqueness, NOT compatibility.

    Some all-in-one packages, like HotDogEd, use only one password for everything.

    Of course you can use as many diffrent passwords as you want. In fidonet I just don't see the point. ;)

    'Tommi

    ---
    * Origin: rbb.fidonet.fi (2:221/1)
  • From Tony Langdon@3:633/410 to Michiel van der Vlist on Sun May 3 18:19:00 2020
    On 05-03-20 09:23, Michiel van der Vlist wrote to Tommi Koivula <=-

    Compatibility with what? Passwords are like keys. They are designed fo maximum uniqueness, NOT compatibility.

    There is a minority of mailers that do requite things like PKT and session passwords to be idenbtical, but the majority of mailer/tosser combinations don't have that limitation.


    ... I luvs ya, but everyone else thinks you're an ass.
    === MultiMail/Win v0.51
    --- SBBSecho 3.10-Linux
    * Origin: Freeway BBS Bendigo,Australia freeway.apana.org.au (3:633/410)
  • From Michiel van der Vlist@2:280/5555 to Tommi Koivula on Sun May 3 10:55:25 2020
    Hello Tommi,

    On Sunday May 03 2020 10:47, you wrote to me:

    Compatibility with what? Passwords are like keys. They are
    designed fo maximum uniqueness, NOT compatibility.

    Some all-in-one packages, like HotDogEd, use only one password for everything.

    That is no reason to use one password for everything for all links. Passwords are a link specific thing anyway.

    Of course you can use as many diffrent passwords as you want.

    I use different paswords for diffent links...

    In fidonet I just don't see the point. ;)

    Longer session password increase security, no argument there. If the increased security is still really needed in Fidonet is another discussion. I lean towards not...

    Even more: I say binkds is an overkill.

    Cheers, Michiel

    --- GoldED+/W32-MSVC 1.1.5-b20170303
    * Origin: http://www.vlist.eu (2:280/5555)
  • From Michiel van der Vlist@2:280/5555 to Tony Langdon on Sun May 3 11:01:44 2020
    Hello Tony,

    On Sunday May 03 2020 18:19, you wrote to me:

    Compatibility with what? Passwords are like keys. They are
    designed fo maximum uniqueness, NOT compatibility.

    There is a minority of mailers that do requite things like PKT and
    session passwords to be idenbtical, but the majority of mailer/tosser combinations don't have that limitation.

    Like you do, I deal with that on a case by case.

    Because the neighbour has just one key that fits all locks in his house, does not mean I have to follow the same key system for my house...

    Cheers, Michiel

    --- GoldED+/W32-MSVC 1.1.5-b20170303
    * Origin: http://www.vlist.eu (2:280/5555)
  • From Alan Ianson@1:153/757 to Michiel van der Vlist on Sun May 3 02:43:04 2020
    Hello Michiel,

    Even more: I say binkds is an overkill.

    Binkp over TLS is secure and provides privacy in a new and robust way. It's a natural movement forward.

    It's not easy to do in all mailers, but if it was and it was supported and available by your links and your own mailer would you use it?

    Ttyl :-),
    Al

    --- GoldED+/LNX
    * Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)
  • From Tony Langdon@3:633/410 to Michiel van der Vlist on Sun May 3 19:57:00 2020
    On 05-03-20 11:01, Michiel van der Vlist wrote to Tony Langdon <=-

    Because the neighbour has just one key that fits all locks in his
    house, does not mean I have to follow the same key system for my
    house...

    I agree totally. Why be limited unnecessarily be a minority of systems, when you don't have to be.


    ... You don't know what you are, do you?
    === MultiMail/Win v0.51
    --- SBBSecho 3.10-Linux
    * Origin: Freeway BBS Bendigo,Australia freeway.apana.org.au (3:633/410)
  • From Michiel van der Vlist@2:280/5555 to Alan Ianson on Sun May 3 15:52:58 2020
    Hello Alan,

    On Sunday May 03 2020 02:43, you wrote to me:

    Even more: I say binkds is an overkill.

    Binkp over TLS is secure and provides privacy in a new and robust way.

    Security against what threats and privacy against which snooping eyes?

    The biggest potential invasion of privacy in Fidonet are sysops snooping om in transit mail. TLS does not protect against that. The best strategy against snooping governments is to not be of interest. I doubt TLS is safe against the resources of governments.

    It's a natural movement forward.

    Binkd already has build in encryption. I do not think the added value of TLS is worth the effort and overhead. Not for Fidonet...

    It's not easy to do in all mailers, but if it was and it was supported
    and available by your links and your own mailer would you use it?

    I don't know. If I'd have to go through the hassle of getting a certificate and pay for it and renew it every tweo years, probably not. And I do not trust LetsEncrypt.


    Cheers, Michiel

    --- GoldED+/W32-MSVC 1.1.5-b20170303
    * Origin: http://www.vlist.eu (2:280/5555)
  • From Alan Ianson@1:153/757 to Michiel van der Vlist on Sun May 3 11:39:54 2020
    Hello Michiel,

    Binkp over TLS is secure and provides privacy in a new and robust
    way.

    Security against what threats and privacy against which snooping eyes?

    Actually, TLS is not really new. It started as SSL from a bygone era and TLS is what we have today. It has and continues to evolve.

    Snooping eyes are everywhere. They are unseen doing I don't know what. We have the technology and I suggest we use it. It already exists so we don't have to develop anything at all, we just need to support it.

    The biggest potential invasion of privacy in Fidonet are sysops
    snooping om in transit mail. TLS does not protect against that.

    That is true. We could (and I'm surprised we haven't) develop a way to encrypt tansit mail if we wanted too.

    Mystic does this. It has support for this by using an AES256 encryption key between links. If Mystic operators use this feature netmail between nodes is encrypted. I think this all happens when tossing so it (or something like it) could be used in Fidonet generally if the software supports it. I'm not sure if that would be better implemeted in the mailer or tosser. Probably the tosser.

    The best strategy against snooping governments is to not be of
    interest. I doubt TLS is safe against the resources of governments.

    TLS is open source. Governments could outlaw it if they wanted to raise the ire of the people but I don't think that is going to happen.

    It's a natural movement forward.

    Binkd already has build in encryption. I do not think the added value
    of TLS is worth the effort and overhead. Not for Fidonet...

    That was a very good addition that the binkd developers added to binkd at the time. It was powerful and ahead of it's time. That must have been twenty years ago when SSL was not largely known or easy to implement.

    That algorithm was also cracked about 20 years ago. It's still better than nothing but TLS would be a good addition today. The crypt option does not provide security today.

    It's not easy to do in all mailers, but if it was and it was
    supported and available by your links and your own mailer would
    you use it?

    I don't know. If I'd have to go through the hassle of getting a certificate and pay for it and renew it every tweo years, probably
    not. And I do not trust LetsEncrypt.

    It's possible to use a self signed certificate. I don't know the ramifications of a self signed certificate vs letsencrypt but it might provide the security and privacy we need.

    Currently I use a certificate from letsencrypt.

    Ttyl :-),
    Al

    --- GoldED+/LNX
    * Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)
  • From Rob Swindell@1:103/705 to Michiel van der Vlist on Sun May 3 13:13:33 2020
    Re: Security
    By: Michiel van der Vlist to Alan Ianson on Sun May 03 2020 03:52 pm

    Hello Alan,

    On Sunday May 03 2020 02:43, you wrote to me:

    Even more: I say binkds is an overkill.

    Binkp over TLS is secure and provides privacy in a new and robust way.

    Security against what threats and privacy against which snooping eyes?

    If the threats/snooping-eyes announced their presence and intentions, they wouldn't be very effective, now would they?

    The biggest potential invasion of privacy in Fidonet are sysops snooping om in transit mail. TLS does not protect against that.

    The second sentence is true.

    The best strategy
    against snooping governments is to not be of interest.

    False. You're *already* being snooped on by governments and you're not interesting at all. You seem to be a very trusting person.

    I doubt TLS is safe against the resources of governments.

    It seems to be effective enough for data in-flight that they (resources of governments) usually go after the persistent data on either end of the transport instead.

    It's a natural movement forward.

    Binkd already has build in encryption.

    ... which is terrible.

    I do not think the added value of TL is worth the effort and overhead.

    It was very little effort and unnoticeable overhead.

    Not for Fidonet...

    For Fidonet proper, possibly true (though that depends on the content of your netmail messages). For FTN, likely false.

    It's not easy to do in all mailers, but if it was and it was supported and available by your links and your own mailer would you use it?

    I don't know. If I'd have to go through the hassle of getting a certificate and pay for it and renew it every tweo years, probably not.

    Free certs are available.

    And I do not trust LetsEncrypt.

    Now you don't sound like a very trusting person. That was a quick turn around.


    digital man

    Synchronet "Real Fact" #56:
    Synchronet Terminal Server introduced SecureShell (SSH) support w/v3.14a (2006).
    Norco, CA WX: 74.9F, 50.0% humidity, 11 mph ESE wind, 0.00 inches rain/24hrs --- SBBSecho 3.11-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Tony Langdon@3:633/410 to Alan Ianson on Mon May 4 08:36:00 2020
    On 05-03-20 02:43, Alan Ianson wrote to Michiel van der Vlist <=-

    Hello Michiel,

    Even more: I say binkds is an overkill.

    Binkp over TLS is secure and provides privacy in a new and robust way. It's a natural movement forward.

    Agreed, it's a logical step - using proven standard protocols to beef up security and privacy.

    It's not easy to do in all mailers, but if it was and it was supported
    and available by your links and your own mailer would you use it?

    I would use binkps if it was built in. I'm not interested in jumping through hoops with TLS proxies, however. :/


    ... Weeds! No, that is my vineyard! Ever heard of dandelion wine?
    === MultiMail/Win v0.51
    --- SBBSecho 3.10-Linux
    * Origin: Freeway BBS Bendigo,Australia freeway.apana.org.au (3:633/410)
  • From Tony Langdon@3:633/410 to Alan Ianson on Mon May 4 08:40:00 2020
    On 05-03-20 11:39, Alan Ianson wrote to Michiel van der Vlist <=-

    It's possible to use a self signed certificate. I don't know the ramifications of a self signed certificate vs letsencrypt but it might provide the security and privacy we need.

    Encryption will be fine, but self signed just means you can't trust the other end to be who they say they are. But that's a call the BBS networks have to make.

    Currently I use a certificate from letsencrypt.

    I'm not currently running binkps. It's been a moving target, and as I've said,
    I won't bother jumping through hoops and binkd doesn't yet support TLS natively
    (that I'm aware of).


    ... Skating away on the thin ice of a new day...
    === MultiMail/Win v0.51
    --- SBBSecho 3.10-Linux
    * Origin: Freeway BBS Bendigo,Australia freeway.apana.org.au (3:633/410)
  • From Oli@2:280/464.47 to Tony Langdon on Mon May 4 11:50:20 2020
    Tony wrote (2020-05-04):

    It's possible to use a self signed certificate. I don't know the
    ramifications of a self signed certificate vs letsencrypt but it
    might provide the security and privacy we need.

    Encryption will be fine, but self signed just means you can't trust the other end to be who they say they are.

    Works fine with SSH. Trust on first use (TOFU) works with TLS too. There is also DANE / TLSA-records to put the (hash of the) public key in DNS. You could also put it in the nodelist itself.

    But that's a call the BBS networks have to make.

    This is like: that's a call the Internet has to make.

    Currently I use a certificate from letsencrypt.

    I'm not currently running binkps. It's been a moving target, and as I've said, I won't bother jumping through hoops and binkd doesn't yet support TLS natively (that I'm aware of).

    Native support in binkd would be nice, on the other hand the workarounds are not that difficult.

    Outgoing connections are easy with binkd:

    node 5:6/7@fidonet -pipe "gnutls-cli --logfile /dev/null --no-ca-verification --strict-tofu --disable-sni *H:24553"

    Incoming connections with haproxy are three lines (works for every mailer):

    listen binkps
    bind :::24553 ssl crt fidonet.pem
    server binkd 127.0.0.1:24554

    Synchronet's BinkIT does support TLS already. But only jumping through hoops (with binkd) gives you TLS 1.3 connections.

    ---
    * Origin: (2:280/464.47)
  • From Alexey Fayans@2:5030/1997 to Alan Ianson on Mon May 4 13:26:10 2020
    Hello Alan!

    On Sun, 03 May 2020 at 02:43 -0700, you wrote to Michiel van der Vlist:

    Binkp over TLS is secure and provides privacy in a new and robust way. It's a natural movement forward.

    Why keep saying it is secure while it is not? It would only be secure if certificates could be verified. Otherwise it is zero security.


    ... Music Station BBS | https://bbs.bsrealm.net | telnet://bbs.bsrealm.net
    --- GoldED+/W32-MSVC 1.1.5-b20180707
    * Origin: Music Station | https://ms.bsrealm.net (2:5030/1997)
  • From Tony Langdon@3:633/410 to Oli on Mon May 4 21:22:00 2020
    On 05-04-20 11:50, Oli wrote to Tony Langdon <=-

    Works fine with SSH. Trust on first use (TOFU) works with TLS too.
    There is also DANE / TLSA-records to put the (hash of the) public key
    in DNS. You could also put it in the nodelist itself.

    Yep, I can see that working.

    node 5:6/7@fidonet -pipe "gnutls-cli --logfile /dev/null --no-ca-verification --strict-tofu --disable-sni *H:24553"

    Incoming connections with haproxy are three lines (works for every mailer):

    listen binkps
    bind :::24553 ssl crt fidonet.pem
    server binkd 127.0.0.1:24554

    Will need tweaking, because binkd doesn't listen on 127.0.0.1 (or ::1). :) I'll use the LAN IP binkd listens on. I assume all those tools support IPv6 these days too.

    Synchronet's BinkIT does support TLS already. But only jumping through hoops (with binkd) gives you TLS 1.3 connections.

    Fair enough. I may look into it further.


    ... It's people like you who make people like me above average.
    === MultiMail/Win v0.51
    --- SBBSecho 3.10-Linux
    * Origin: Freeway BBS Bendigo,Australia freeway.apana.org.au (3:633/410)
  • From Michiel van der Vlist@2:280/5555 to Alan Ianson on Tue May 5 09:45:25 2020
    Hello Alan,

    On Sunday May 03 2020 11:39, you wrote to me:

    Security against what threats and privacy against which snooping
    eyes?

    Actually, TLS is not really new. It started as SSL from a bygone era
    and TLS is what we have today. It has and continues to evolve.

    I know TLS is not new.

    Snooping eyes are everywhere. They are unseen doing I don't know what.
    We have the technology

    Do we? Or do we just think we have? If you do not know against what or who you are protecting, how do you know the defence is effective. Or if it is working at all?

    The biggest potential invasion of privacy in Fidonet are sysops
    snooping om in transit mail. TLS does not protect against that.

    That is true. We could (and I'm surprised we haven't) develop a way to encrypt tansit mail if we wanted too.

    We already have that for 25 years. I aleady used PGP to encrypt netmail in the mid nineties. I wrote a utility for it that scanned *.msg for cerain strings and call PGP to encrypt the text. The problem was that few sysops would route encrypted mail....

    Mystic does this. It has support for this by using an AES256
    encryption key between links. If Mystic operators use this feature
    netmail between nodes is encrypted. I think this all happens when
    tossing so it (or something like it) could be used in Fidonet
    generally if the software supports it. I'm not sure if that would be better implemeted in the mailer or tosser. Probably the tosser.

    Probably a dedicated utility like my IMCRYPT.

    The best strategy against snooping governments is to not be of
    interest. I doubt TLS is safe against the resources of governments.

    TLS is open source.

    These days open source is no guarantee that you know exactly what is going on. There is too much under the hood...

    Governments could outlaw it if they wanted to

    But they don't. so I suspect they heve already cracked it or have other ways to circumvent.

    raise the ire of the people but I don't think that is going to happen.

    It's a natural movement forward.

    Binkd already has build in encryption. I do not think the added
    value of TLS is worth the effort and overhead. Not for Fidonet...

    That was a very good addition that the binkd developers added to binkd
    at the time. It was powerful and ahead of it's time.
    [..]
    That algorithm was also cracked about 20 years ago. It's still better
    than nothing but TLS would be a good addition today. The crypt option
    does not provide security today.

    I know it is not perfect. But so are the locks on my house. They are not perfect. They will not stop a sufficiently equiped and determined intruder. But it will stop enough.

    It's not easy to do in all mailers, but if it was and it was
    supported and available by your links and your own mailer would
    you use it?

    I don't know. If I'd have to go through the hassle of getting a
    certificate and pay for it and renew it every tweo years,
    probably not. And I do not trust LetsEncrypt.

    It's possible to use a self signed certificate.

    That is the equivalent of someone saying "trust me". I never trust people who say that.

    I don't know the ramifications of a self signed certificate vs
    letsencrypt but it might provide the security and privacy we need.

    Currently I use a certificate from letsencrypt.

    I don't trust LetsEncrypt. For a variety of reasons. What is their bussines model? If ot sounds to good to be true it usually isn't. Plus that it is a US compamy, subject to the Patriot Act.

    A couple of years ago a Dutch company issuing certaificates was hacked. All the cerificates were compromised. Google for DigiNotar.

    Anyway, binkd over TLS is not on mt wish list. I'd prefer it if the developers spend theiir time and energy on other issues.

    Cheers, Michiel

    --- GoldED+/W32-MSVC 1.1.5-b20170303
    * Origin: http://www.vlist.eu (2:280/5555)
  • From Michiel van der Vlist@2:280/5555 to Rob Swindell on Tue May 5 10:34:03 2020
    Hello Rob,

    On Sunday May 03 2020 13:13, you wrote to me:

    Binkp over TLS is secure and provides privacy in a new and robust
    way.

    Security against what threats and privacy against which snooping
    eyes?

    If the threats/snooping-eyes announced their presence and intentions,
    they wouldn't be very effective, now would they?

    If you do not know who or what you are defending against, how do you know the defence is working at all?

    The biggest potential invasion of privacy in Fidonet are sysops
    snooping om in transit mail. TLS does not protect against that.

    The second sentence is true.

    We have had PGP to end to end encrypt mail for 25 years. We hardly used it because most sysops would not route encrypted mail.

    The best strategy against snooping governments is to not be of
    interest.

    False. You're *already* being snooped on by governments and you're not interesting at all. You seem to be a very trusting person.

    Things are not always what they seem. You conclusion is false.

    I doubt TLS is safe against the resources of governments.

    It seems to be effective enough for data in-flight that they
    (resources of governments) usually go after the persistent data on
    either end of the transport instead.

    So it is not effective against governments.

    It's a natural movement forward.

    Binkd already has build in encryption.

    ... which is terrible.

    So is the lock on my bathroom. It nevertheless serves a purpose.

    I do not think the added value of TL is worth the effort and
    overhead.

    It was very little effort and unnoticeable overhead.

    Not for Fidonet...

    For Fidonet proper, possibly true (though that depends on the content
    of your netmail messages). For FTN, likely false.

    I only use FTN for Fidonet.

    I don't know. If I'd have to go through the hassle of getting a
    certificate and pay for it and renew it every tweo years, probably
    not.

    Free certs are available.

    If it sounds to good to be true, it usually isn't.

    And I do not trust LetsEncrypt.

    Now you don't sound like a very trusting person. That was a quick turn around.

    No turn around, I have a very suspicious mind. A;ways had.


    Cheers, Michiel

    --- GoldED+/W32-MSVC 1.1.5-b20170303
    * Origin: http://www.vlist.eu (2:280/5555)
  • From Alan Ianson@1:153/757 to Alexey Fayans on Tue May 5 11:48:48 2020
    Hello Alexey,

    Binkp over TLS is secure and provides privacy in a new and robust
    way. It's a natural movement forward.

    Why keep saying it is secure while it is not?

    I say it is secure because it is! Arguing that it isn't is just plain silly.

    It would only be secure if certificates could be verified. Otherwise
    it is zero security.

    We could use some kind of in house certificates in fidonet. We would have to build and maintain all that.

    Ttyl :-),
    Al

    --- GoldED+/LNX
    * Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)
  • From Alexey Fayans@2:5030/1997 to Alan Ianson on Wed May 6 15:11:18 2020
    Hello Alan!

    On Tue, 05 May 2020 at 11:48 -0700, you wrote to me:

    Why keep saying it is secure while it is not?
    I say it is secure because it is! Arguing that it isn't is just plain silly.

    No it is not. Thinking that obfuscation equals security is silly.

    It would only be secure if certificates could be verified.
    Otherwise it is zero security.
    We could use some kind of in house certificates in fidonet. We would
    have to build and maintain all that.

    There are many options. For example, have centralized certificate issuer or have pubkeys in nodelist or DNS. The only problem is that there is no standard to implement.


    ... Music Station BBS | https://bbs.bsrealm.net | telnet://bbs.bsrealm.net
    --- GoldED+/W32-MSVC 1.1.5-b20180707
    * Origin: Music Station | https://ms.bsrealm.net (2:5030/1997)
  • From mark lewis@1:3634/12 to Alexey Fayans on Wed May 6 09:17:09 2020
    Re: -64 and -46 option missing in 101
    By: Alexey Fayans to Alan Ianson on Wed May 06 2020 15:11:18


    We could use some kind of in house certificates in fidonet. We would
    have to build and maintain all that.

    There are many options. For example, have centralized certificate
    issuer or have pubkeys in nodelist or DNS. The only problem is that
    there is no standard to implement.

    remember, too, that in fidonet/FTN, the protocol comes first... then the standard is written based on what is most widely used by the participants... if one must have a standard to start with, RFCs are available and then things can be modified to fit FTN methods from there...


    )\/(ark
    --- SBBSecho 3.11-Linux
    * Origin: SouthEast Star Mail HUB - SESTAR (1:3634/12)
  • From Alan Ianson@1:153/757 to Alexey Fayans on Wed May 6 13:34:00 2020
    Hello Alexey,

    I say it is secure because it is! Arguing that it isn't is just
    plain silly.

    No it is not. Thinking that obfuscation equals security is silly.

    What obfuscation and/or lack of security do you speak of?

    We could use some kind of in house certificates in fidonet. We
    would have to build and maintain all that.

    There are many options. For example, have centralized certificate
    issuer or have pubkeys in nodelist or DNS. The only problem is that
    there is no standard to implement.

    If you want that info in the nodelist then the nodelist standard comes into play. If the nodelist had that info we could look there but that is not the case.

    If my current certificate is not good enough then what would be and why?

    Ttyl :-),
    Al

    --- GoldED+/LNX
    * Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)
  • From Alexey Fayans@2:5030/1997 to Alan Ianson on Thu May 7 01:33:41 2020
    Hello Alan!

    On Wed, 06 May 2020 at 13:34 -0700, you wrote to me:

    I say it is secure because it is! Arguing that it isn't is just
    plain silly.
    No it is not. Thinking that obfuscation equals security is silly.
    What obfuscation and/or lack of security do you speak of?

    I think I already explained it. If you cannot verify certificate that was used for encryption, there is no security in this encryption, only obfuscation (it's harder to read/modify communication but still possible via MitM attach which will go unnoticed).

    We could use some kind of in house certificates in fidonet. We
    would have to build and maintain all that.
    There are many options. For example, have centralized certificate
    issuer or have pubkeys in nodelist or DNS. The only problem is
    that there is no standard to implement.
    If you want that info in the nodelist then the nodelist standard comes into play. If the nodelist had that info we could look there but that
    is not the case.

    I didn't say I wanted it there. It was just an option, one of many.

    If my current certificate is not good enough then what would be and
    why?

    You are using certificate issued by a trusted CA that matches your domain specified in nodelist, which is fine. If there would be a standard for binkps requiring INA to be present and contain a valid domain name, then mailers could verify certificates based on domain names and trusted CA, as web browsers do. But without a standard there is no security. If there will be an IP address in the INA field, how can you verify certificate validity?


    ... Music Station BBS | https://bbs.bsrealm.net | telnet://bbs.bsrealm.net
    --- GoldED+/W32-MSVC 1.1.5-b20180707
    * Origin: Music Station | https://ms.bsrealm.net (2:5030/1997)
  • From Oli@2:280/464.47 to Alexey Fayans on Thu May 7 12:34:27 2020
    Alexey wrote (2020-05-07):

    If my current certificate is not good enough then what would be and
    why?

    You are using certificate issued by a trusted CA that matches your domain specified in nodelist, which is fine. If there would be a standard for binkps requiring INA to be present and contain a valid domain name, then mailers could verify certificates based on domain names and trusted CA,
    as web browsers do. But without a standard there is no security. If there will be an IP address in the INA field, how can you verify certificate validity?

    and with FTS-5004 (binkp.net) it's also not really secure. we don't even have an informal agreement how to deal with these addresses does the binkp server have to offer a cert for it's binkp.net address? or should the binkp client verify the certificate based on the domain the CNAME / SRV record points to?

    of course it always can be treat like a self-signed cert.

    ---
    * Origin: (2:280/464.47)
  • From Benny Pedersen@2:230/0 to Tommi Koivula on Sat May 9 12:55:14 2020
    Hello Tommi!

    03 May 2020 10:42, Tommi Koivula wrote to Benny Pedersen:


    === Cut ===
    03 May 03:58:32 [51674] incoming session with region23.dk
    [172.104.248.211]
    03 May 03:58:32 [51674] pwd protected session (MD5)
    03 May 03:58:32 [51674] session in CRYPT mode
    03 May 03:58:32 [51674] done (from 2:230/0@fidonet, OK, S/R: 0/0 (0/0
    bytes))
    === Cut ===

    :)

    What was the solution?

    emerge -av net-fido/binkd


    i have updated it today, repoman is happy, so am i then


    Regards Benny

    ... there can only be one way of life, and it works :)

    --- Msged/LNX 6.1.2 (Linux/5.6.11-gentoo-x86_64 (x86_64))
    * Origin: I will always keep a PC running CPM 3.0 (2:230/0)
  • From Tommi Koivula@2:221/1 to Benny Pedersen on Sat May 9 19:41:38 2020
    Hi Benny.

    === Cut ===
    03 May 03:58:32 [51674] incoming session with region23.dk
    [172.104.248.211]
    03 May 03:58:32 [51674] pwd protected session (MD5)
    03 May 03:58:32 [51674] session in CRYPT mode
    03 May 03:58:32 [51674] done (from 2:230/0@fidonet, OK, S/R: 0/0 (0/0
    bytes))
    === Cut ===

    :)

    What was the solution?

    emerge -av net-fido/binkd

    Good for you! (I think ;))

    tommi@rpi:~$ emerge
    No command 'emerge' found, did you mean:
    Command 'fmerge' from package 'fhist' (universe)
    Command 'esmerge' from package 'tstools' (universe)
    Command 'vemerge' from package 'util-vserver' (universe)
    Command 'merge' from package 'rcs' (universe)
    emerge: command not found

    'Tommi

    --- GoldED+/LNX 1.1.5-b20180707
    * Origin: rpi.rbb.bbs.fi (2:221/1)
  • From Benny Pedersen@2:230/0 to Tommi Koivula on Sat May 9 23:50:10 2020
    Hello Tommi!

    09 May 2020 19:41, Tommi Koivula wrote to Benny Pedersen:

    emerge -av net-fido/binkd
    Good for you! (I think ;))

    yes its gentoo supported

    emerge -av eix
    eix-sync
    eix-remote update1

    eix -Rv binkd

    tommi@rpi:~$ emerge
    No command 'emerge' found, did you mean:
    Command 'fmerge' from package 'fhist' (universe)
    Command 'esmerge' from package 'tstools' (universe)
    Command 'vemerge' from package 'util-vserver' (universe)
    Command 'merge' from package 'rcs' (universe)
    emerge: command not found

    as you see debian is not so helpfull :)


    Regards Benny

    ... there can only be one way of life, and it works :)

    --- Msged/LNX 6.1.2 (Linux/5.6.11-gentoo-x86_64 (x86_64))
    * Origin: I will always keep a PC running CPM 3.0 (2:230/0)