Hello Martin!
** 09.02.20 - 11:36, Martin Foster wrote to August Abolins:
AA>> Which leads me to the security/bug/weakeness.
AA>> ..then anyone could arbitrarily send me a nodelist, and its
AA>> presence can screw up oxp (just like the presence of the old
AA>> nodelist/diffs that I still had in there did).
MF>It wasn't the presence of the old nodlists/diffs that was causing the
MF>problem :)
Correct. The main problem was having a Z1 nodelist and using a Z2 diff
update file. But the only way I managed to clear the lock up was to
delete the latent nodelist/nodediff files I still had in the incoming
/FILES directory.
MF>..The only files it takes action on are nodediffs/pointdiffs and if
MF>any of them are out of sequence, it just ignores them.
It was still taking action on the NODEDIFF that was in /FILES, even though
I had cleared out the nodelist config tables. The /FIDO directory was
empty!
The following settings marked "<==THIS" were probably enabled:
+- Configure Node/Pointlist ------------------------+
| |
| List name NODELIST.### Number 038 |
| |
| Format of list Nodelist ? |
| Zone/Address |
| |
| Update file NODEDIFF.### |
| Update archive NODEDIFF.Z## |
| |
| Process by |
| |
| [x] Use internal nodelist processor |<==THIS
| [x] Delete update after processing |
+- Fido Options ---------------------------------+
Ý Ý
Ý Int. dial prefix 00 Ý
Ý Nat. dial prefix 0 Ý
Ý Your dialing code 49-631 Ý
Ý Ý
Ý [x] Import nodelist updates automatically Ý<==THIS
Ý [ ] Delete empty messages Ý
Ý [x] Automatic TIC file processing Ý<==THIS?
Is it the presence of a .TIC file in /FILES that can trigger the "action"
too?
Maybe I am worried over nothing since OXP probably takes a more secure
process (ie acting on files only received from my Boss system via the TIC
information) before it acts on just anything that looks like a diff file
in the /FILES directory.
../|ug
--- OpenXP 5.0.43
* Origin: ....................... (2:221/1.58)
|