[Dxspider-support] Dx-World and DxCluster

Mon Feb 13 12:36:25 GMT 2023

Why is 2FA necessary? With the simple use of ssh, via password or keys, the authentication problem is solved. 
It is more than proven and solves the node-to-node and node-to-user problem. It will increase the load on the node a bit, but there has to be some cost to security.

The initial work with the use of passwords is punctual. Especially if the access would be unique for all nodes, obviously updated.
It is very easy to generate a random password for each trusted user and mailing for the user to change the password when logging in4 for the first time.

Only those nodes that have configured the registration with a password can be considered "trustworthy", and the traffic originating from their node will have for example QOS=1, and the rest QSO=0. In other words, "credible" information and "dubious" information.

Kin EA3CV

-----Mensaje original-----
De: Dxspider-support <dxspider-support-bounces at tobit.co.uk> En nombre de JOSEPH REED via Dxspider-support
Enviado el: domingo, 12 de febrero de 2023 23:56
Para: The DXSpider Support list <dxspider-support at tobit.co.uk>
CC: JOSEPH REED <joe at n9jr.com>
Asunto: Re: [Dxspider-support] Dx-World and DxCluster

Mikel,

I thought that was very though provoking, I have been reading the posts and trying to find a middle ground in my mind 2FA won’t fly.  Thankfully I retired as a System Administrator on December 31, 2022 and no longer have to work with the 2FA hell and end users.  I am so happy.  But I don’t think 2FA is a viable answer.  I use the cluster to enhance what I am already tuning.  

Shoot, on Tuesday I will have a 20th anniversary with my wife, and I think I have at least 5 years of cluster operation with the previous wife.  A shout out to my multiple decade old old node peers K2LS and WB3FFV.

With all of Kin’s work and other submissions wouldn’t it made more sense to aggregate the code into a single repository and I’m kind of thinking Dirk’s git repo.

Joe N9JR

> On Feb 12, 2023, at 3:20 PM, Mikel EA2CW via Dxspider-support <dxspider-support at tobit.co.uk> wrote:
> 
> First of all, I beg your pardon for my bad english. It is not my mother language and I cannot express myself as well as I wanted to . That said, I am a bit surprised by some of the posts I've reading on both mail/group lists (cc-cluster & dx-spider).
> 
> I thought than Ham Radio was about tech innovation, experimenting, self-teaching, etc. Instead of these, I saw some colleagues who wish to keep all those old things without changes.
> 
> I expected, of course, some level of reactivity from those who have to make the bigger efforts (mainly two unfortunate soft developers, Lee and Dirk) and will confront the bigger part of the work (at least on the near future), but never from the people who -in a non-profit way- are mantaining the cluster system running.
> 
> We have a system that has been serving the ham community with information (more or less confidable) for a long time. Not only now, but going worse, we have to fight a 0.00001 percent of that users (probably the same who make DQRM during risk and cost dxpeditions) putting bad data into the info system. We have to better the system or it wil become -perhaps slowly but for sure- useless.
> 
> Of course, any change made on the cluster net will have consequences on the other systems connected to them. No doubt that some "reactive" measures has been adopted (badips, badnodes, badusers,etc.). Note I said "reactive".
> 
> Think for example in the bank system. As 99.9999% of the users are good people, let them use the ATMs without password. Or connect 3rd part systems (bizum, paypal, etc) with no security. It will be ok the 99.99999% of the time. If someone steal money, we will punish him, don't worry! Where is the need of "proactive" security measures, like passwords, cards, biometrics?
> 
> We are not proposing here a breaking change. We can mantain a low-level security network, where the users and client software will be able to be feeded by the cluster net, from any node, trusty or unsafe. Of course the quality of the info provided by the non-secured nodes will not be the same, as you must front the input of fake information, (allow me not to explain more about the security breaches that could exist in a near future, but we can see some symptoms on every major dxpedition or contest).
> 
> On the other hand, we can develope a 2nd level network that can be ONLY consulted by the 1st level nodes/users , but they will not be allowed to put information in. No security protocols, no passwords, no id requirements. This net should meet at least with these requirements, that can be more or less pregressively developed and in the best way to affect as less as possible to the existing net itself, the different node softwares, and then the "client" ones (loggers, contest tools, SDRs,...):
> 
> - Node safe identification. Every node should known each other, and secure the info running between them.
> - Client (dx hunter, contester, etc) identified to be able to upload information to the net. This should be filled by a per node policy or better, a shared system of SSO (single sign on) which allow any client to be identified by one node only and be able to id himself on any node. Each system has its pro/contras.
> - Interconnection with 3rd part nets (see RBN) as secure as possible. They will have to front its own security risks too.
> 
> - Tools enough to reject bad nodes, bad "clients" and bad data (fake spots mainly and then "badwords")
> 
> The result of these implementations will define the final quality of the information feeded to the system, and also, the quality of the information given to all those 3rd part systems as well. We all know about some systems running today where no serious dxer or contester will connect to. He will be given only trash. All the involved software developers will have to choose which source they want to be connected to.
> 
> Finally, don't forget than in a wide field of our "market" another big source of information already exists. I'm talking about RBN. Out of SSB, almost all other modes are fulfilled by it. Of course it has also its own problems of data reliability (we will not talk about the quality specs that sometimes are asked for to it, and then we -cluster nodes- don't accomplish with)
> 
> I know we know ham ops are getting more and more aged, and as good 3rd agers are proclive to reject changes, think on the old good times, but don't forget that we are here to learn, to experiment and to go forward, that has been our history from the very radio begginings. We don't do this for the money (I hope in 99.99999% of the cases), but for the joy. Don't let that 0.000001% of us to break the 99.0000% efforts because we don't want to change our mind a bit.
> 
> Please excuse me for the language, typos and other mistakes
> 
> As always, 73 & good radio
> Mikel EA2CW
> 
> (sent to cc-cluster discussion list too)
> 
> El 10/02/2023 a las 14:51, Luigi Carlotto IK5ZUK via Dxspider-support escribió:
>> Hello all,
>> please read carefully this article apperared today on Dx-World web site:
>> 
>> https://www.dx-world.net/unacceptable-behaviour-on-dx-clusters/
>> 
>> 73 Luigi IK5ZUK
>> 
>> _______________________________________________
>> Dxspider-support mailing list
>> Dxspider-support at tobit.co.uk
>> https://mailman.tobit.co.uk/mailman/listinfo/dxspider-support
> 
> -- 
> ea2cw at gautxori.com
> Bilbao, Bizkaia. IN83MG
> http://radio.gautxori.com
> http://qrz.com/db/ea2cw
> https://t.me/EA2CW
> 
> 
> _______________________________________________
> Dxspider-support mailing list
> Dxspider-support at tobit.co.uk
> https://mailman.tobit.co.uk/mailman/listinfo/dxspider-support

_______________________________________________
Dxspider-support mailing list
Dxspider-support at tobit.co.uk
https://mailman.tobit.co.uk/mailman/listinfo/dxspider-support