<div id="edo-message"><div><div>Hi, </div><div><br></div><div>A certain Luigi. Dirk and Lee are essential, and their experience invaluable.</div><div>It would be interesting to know your opinion. Everything evolves, and we...<br></div><div><br></div><div>Regards, </div><div><br></div><div>Kim</div><div><br></div><div id="edo-signature"><pre></pre></div></div></div><div id="edo-original"><div><blockquote type="cite" style="margin: 1ex 0 0 0 !important; border-left: 1px #ccc solid !important; padding-left: 0.4ex !important;"><div id="edo-meta">El 1 nov. 2022 en 22:29, Luigi Carlotto IK5ZUK <<a href="mailto:ik5zuk@tiscali.it">ik5zuk@tiscali.it</a>> escribió: <br><br></div><pre>Hello Kin,

<br>your proposal is very interesting!I think it should be a good idea to  

switch to a more secure network.

<br>

<br>BTW it is important to know the opinion of the two software's  

developers, Dirk and Lee...

<br>

<br>73 Luigi IK5ZUK

<br>

<br>Il 16/09/2022 09:40, Joaquin via Dxspider-support ha scritto:

<br>> Hi all,

<br>>

<br>> We have all seen the offensive spots that have been being sent to the  

<br>> Net. Others know that in WW contests, malicious spots are sent in  

<br>> order to cause the disqualification of an operator or team in that  

<br>> contest. We also know that if an authentication policy is not applied  

<br>> in our nodes, this will continue to happen and the sysops will always  

<br>> follow behind trying to block the alleged offenders, but not only are  

<br>> we late because the spot has already spread, in addition, the spotter  

<br>> is usually an unassigned callsign or worse still, from an operator  

<br>> that is not the one that actually sent that garbage. The bad thing is  

> that we block those operators without knowing if they are the cause.

<br>> We also know that many of the nodes are not updated, so new features  

<br>> and bug fixes are not applied to them. This makes it impossible for  

> the current network to evolve to a more secure and reliable one.

<br>>

<br>> How can progress be made without the collaboration of the sysops  

<br>> community? An answer to this question may be this draft:

<br>>

<br>> Let's say the current Network is v1.0 and the new one will be called  

<br>> v2.0.

<br>>

> The Network v1.0 remains as it is today.

<br>> The new Network v2.0 would be an evolution of v1.0 in such a way that  

<br>> a series of functions would be incorporated:

<br>> 1. Every connection (user-node, node-node) would be with  

<br>> login/password authentication to be able to use the sending of  

<br>> information.

<br>> 2. The information of all users and nodes will always be at least  

> username, password, email if they are registered/validated.

> 3. Passwords will be stored encrypted (eg in MD5).

<br>> 4. In order for a user registered/validated by a sysop on your node to  

<br>> access any other v2.0 Network, this information will be sent to all  

<br>> v2.0 nodes.

<br>> 5. In the case of DXSpider, the current logging mechanism should allow  

> sending an email to the sysop.

<br>> 6. A new command should be included that allows the sysop to send a  

<br>> message (email) indicating that a certain user who is registered in  

<br>> the v2.0 Network has broken the rules and that he proposes that he be  

> blocked/eliminated from the nodes.

<br>>

<br>> For both networks to cohexist initially:

<br>> v2.0 <-> v2.0. Network v2.0 nodes with other v2.0 nodes will send and  

> receive the same information as they do now.

<br>> v2.0 <-> v1.0. In the case of Network v1.0 nodes that connect to v2.0  

<br>> nodes, the former will continue to function as before, but v2.0 nodes  

<br>> will only maintain the link up, receiving the spots, ann, .. ., but  

> since v2.0 spots will not be sent, ann, ...

<br>> v1.0 <-> v1.0. The interconnection between nodes of the Network v1.0  

> was safe as before.

<br>>

<br>> The idea is that the v1.0 nodes converge on the v2.0 Network without  

<br>> being isolated, progressively disappearing when they realize that they  

> do not receive all the spots and their software is not updated.

<br>>

<br>> From a developer point of view, I think it would be possible to use  

<br>> newer PCxx and CCxx with less impact if current software can be  

<br>> adapted. And with some modifications for the current v1.0. But it is  

> still a job that takes time and effort.

<br>>

<br>> For this to work, the involvement of cluster developers and sysops is  

<br>> necessary, especially those that have more users and therefore can  

> exert indirect pressure to promote change.

<br>>

> What do you think of this proposal?

<br>> Possible improvements?

<br>> Infeasibility?

<br>> Alternatives?

<br>>

<br>> Regards.

<br>>

<br>> Kin EA3CV

<br>>

<br>> sysop EA3CV-2, EA4URE-2,3,5

<br>>

<br>>

<br>> _______________________________________________

<br>> Dxspider-support mailing list

<br>> Dxspider-support@<a href="tobit.co.uk">tobit.co.uk</a>

<br>> <a href="https://mailman.tobit.co.uk/mailman/listinfo/dxspider-support">https://mailman.tobit.co.uk/mailman/listinfo/dxspider-support</a>

<br>

<br></pre>  

 <br> </blockquote></div></div>