http://download.binkd.org
http://sites.google.com/site/vasilyevmax/fido
Sunday April 19 2020 01:14, I wrote to you:
The -64 and -46 options are missing in versions 101.
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:
Does anyone really need this option? :)
And BTW, the "official" -101 version still does not compile in OS/2...
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. ;-)
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 inOS/2...
But your version does ;-)
Yes, but it is compiled from the source of "the other fellow". Which
seems to work ok.
Amyways, as long OS/2 is supported by the binkd team, it would be nice that the current source compiles in OS/2.
Amyways, as long OS/2 is supported by the binkd team, it would be nice that the current source compiles in OS/2.
Hello Tommi! On Sun, 19 Apr 2020 at 17:53 +0300, you wrote toThis patch gives only partial solution - for one compiler. It should not be merged.
Michiel van der Vlist:
Amyways, as long OS/2 is supported by the binkd team, it would beIt will compile, most probably, once https://github.com/pgul/binkd/pull/17 is merged.
nice that the current source compiles in OS/2.
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, onceThis patch gives only partial solution - for one compiler. It should
https://github.com/pgul/binkd/pull/17 is merged.
not be merged.
Amyways, as long OS/2 is supported by the binkd team, it would be nice that the current source compiles in OS/2.
This patch gives only partial solution - for one compiler. It should not be merged.
I'm no longer running binkd myself; I wrote my own binkp
mailer instead. I'm not sure I trust binkd.
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!?
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?
On 2020-04-22 12:54:00, you wrote to me:
Sure. Which part of it?
Why you don't trust binkd.
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?
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.
Why you don't trust binkd.
maybe sending passwords in clear text is one of them ?
ifWhy 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
# your link can use an old version of binkd.
Sure. Which part of it?
Why you don't trust binkd.
maybe sending passwords in clear text is one of them ?
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?
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 !
# * '-md' means "Must have CRAM-MD5". This works only with theand this is not working,
nodes using # versions of binkd or argus supporting this
method. Do not set it if # your link can use an old version
of binkd.
binkd c code must ensure no clear text
passwords is default
or atleast let clients drop connection BEFORE
its sent !
like 8 character passwords aren't already easily brute forced, eh?
like 8 character passwords aren't already easily brute forced, eh?
This is working. You just disabled it somehow. Probably by starting
binkd with -m flag.
i have added defnode -md
lets hope binkd will support openssl soon, so we could close this
problem of plain text passwords
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.
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))
Still "CRAM-MD5 is not supported by remote".
Have a nice labour day!
lets hope binkd will support openssl soon, so we could close this
problem of plain text passwords
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.
like 8 character passwords aren't already easily brute forced, eh?
where have Mark being missinformated ? :)
like 8 character passwords aren't already easily brute forced,
eh?
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...
only one i know is qico that support emsi, but i dont know any that
have iemsi, maybe mysticbbs ?
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>]]|-}
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 ;)
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 ;)
only one i know is qico that support emsi, but i dont know any that have iemsi, maybe mysticbbs ?
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 ?
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.
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...
MvdV> In fact some say NOT having them the same increases security.
yeah, i've heard that, too ;)
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...
yeah, i've heard that, too ;)
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.
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?
On 05-02-20 12:37, Tommi Koivula wrote to Tony Langdon <=-
Why is that the best?
Ok, "best" may be wrong word. :)
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?
This is working. You just disabled it somehow. Probably bynope defnode is in my config # commented, so default in c code is
starting binkd with -m flag.
default allow plain passwords
Still "CRAM-MD5 is not supported by remote".how to enabled it is still unclear
maybe sending passwords in clear text is one of them ?
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.
*YOUR* binkd perhaps does not, but Binkd *CAN* do some basic routing
and .PKT checking.
So either change defaults in source code to your likings or just
create some sane configuration.
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.
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.
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 routingonly need perl hooks in binkd :)
and .PKT checking.
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
all solved now
+ 02 May 23:13:31 [13572] pwd protected session (MD5)
Solved indeed.
On 05-02-20 15:09, Tommi Koivula wrote to Tony Langdon <=-
Haha OK, so what was the appropriate word? Convenient?
Or 'maximum compatibility' :)
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
Binkd does nothing with the packets.
*YOUR* binkd perhaps does not, but Binkd *CAN* do some basic routing
and .PKT checking.
Why is that the best?
Ok, "best" may be wrong word. :)
Haha OK, so what was the appropriate word? Convenient?
Or 'maximum compatibility' :)
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 :)
maximumWhy 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
uniqueness, NOT compatibility.
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.
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. ;)
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.
Even more: I say binkds is an overkill.
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...
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?
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.
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 TL 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.
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.
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?
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.
Currently I use a certificate from 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.
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).
Binkp over TLS is secure and provides privacy in a new and robust way. It's a natural movement forward.
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.
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.
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
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 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.
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.
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.
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.
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.We could use some kind of in house certificates in fidonet. We would
Otherwise it is zero security.
have to build and maintain all that.
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.
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.
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.
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 certificateIf 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
issuer or have pubkeys in nodelist or DNS. The only problem is
that there is no standard to implement.
is not the case.
If my current certificate is not good enough then what would be and
why?
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?
=== Cut ===[172.104.248.211]
03 May 03:58:32 [51674] incoming session with region23.dk
03 May 03:58:32 [51674] pwd protected session (MD5)bytes))
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
=== Cut ===
:)
What was the solution?
=== 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
emerge -av net-fido/binkdGood 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
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 409 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 59:17:53 |
| Calls: | 8,572 |
| Calls today: | 2 |
| Files: | 13,225 |
| Messages: | 5,929,954 |