[archimedes] Re: Evt. Hackproblem

  • From: Thomas Milius <Thomas-Milius@xxxxxxxxxxxxxxx>
  • To: archimedes@xxxxxxxxxxxxx
  • Date: Tue, 28 May 2019 21:02:26 +0200

In message <92864fbb57.Alex@xxxxxxxxxx>
          Alexander Ausserstorfer <bavariasound@xxxxxxxxxxxxxxx> wrote:

In message <588386658.522011.1559040508695@xxxxxxxxxxxxxxxxxxxxxx>
          Steffen Huber <steffen@xxxxxxxxxxxx> wrote:

Alexander Ausserstorfer <bavariasound@xxxxxxxxxxxxxxx> hat am 27. Mai
2019 um 19:20 geschrieben:

Vor allem aber editiere ich viele Nachrichten nachträglich nochmals
mittels StrongEd. Kann StrongEd Unicode? Ich denke nicht. Jedenfalls
habe ich hier dann die komischten Zeichen auf dem Schirm. Könnte man
StrongEd ohne weiteres Unicode beibringen? Ich habe mich mit dem noch
nicht näher beschäftigt.

StrongEd ist nicht Unicde-fähig. Das Feature steht nicht mal auf der
offiziellen Wish List. Und es wäre ziemlich komplex, das dazuzubauen,
wenn ich eine Diskussion mit Fred richtig erinnere. Vor allem hat man
natürlich auch das übliche Font-Problem - man müsste sich auf die
"üblichen" ISO8859-Zeichen beschränken, und dann kann man gleich mit
diesem Encoding arbeiten.

Was ich bisher von den Unicode-"Fähigkeiten" von Messenger gehört
habe, muss zwingend der integrierte Editor verwendet werden.

Ich hatte zwar Unicode bei MessengerPro 8 abgeschaltet. Wenn ich die
bereits von MessengerPro "abgeschickten", also in der Schlange
befindlichen Nachrichten nochmals mittels !StrongEd nacharbeite, sind im
Nachrichtentext leider wieder jeweils zwei komische Zeichen statt der
Umlaute und dem scharfen S zu sehen (StrongEd_ohne_UTF8.jpg).

Wenn ich Unicode anschalte, sind beim Nacheditieren mittels StrongEd
zwar die Umlaute im Nachrichtentext sehbar. Dafür stimmen aber die
Zeichen in der Betreffzeile (Subject:) nicht.

Mit dem internen Editor ist es jedoch nur wenig besser:

Ist Unicode angeschaltet, scheint alles in Ordnung zu sein
(Edit_mit_UTF8/jpg). Ist Unicode abgeschaltet, werden jedoch die Umlaute
in der Betreffzeile falsch angezeigt (Edit_ohne_UTF8/jpg).

Ich weiß auch nicht, wie das gelöst worden ist. Vielleicht ist es so:
Der Editor, egal ob StrongEd oder der interne, erzeugen normale Umlaute
nach irgendeinem erweiterten ASCII-Standard. Nach dem "Absenden"
übersetzt MessengerPro dann die Sonderzeichen ins Unicode.

Wenn man jetzt die E-Mail nochmal nacharbeiten möchte, nachdem sie
bereits von MessengerPro für !Hermes, !POPStar usw. zum Verschicken
abgelegt wurde, hat man natürlich ein Problem. Das ist so blöd.

Auf jeden Fall funktioniert es nicht.


So doof es klingt, der einizge RISC OS Editor, der mit UTF-8 im beschränkten
Masse umgehen kann, ist der eingebaute !Edit der neueren RISC OS Versionen.
Man darf bzgl. Löschen von Zeichen etc. nicht zuviel erwarten, aber das Ding
kann es prinzipiell. Etwas dumm ist, daß dann sonst nicht mehr viel auf
der Mascahine geht :-(.

Ich denke, dass der Weg unter RISC OS eigentlich nur über den Anwender
ist. Wenn man keine Dienste am Laufen hat. Oder wie soll denn unter
RISC OS sonst jemand über das Netzwerk in den Computer "reinkommen"?
RISC OS macht von sich selbst aus ja schließlich nichts.

Sobald Du mit dem Internet verbunden bist, ist RISC OS höchst
verwundbar. Der IP-Stack stammt von einer uralten BSD-Version mit
vermutlich tausenden von bekannten Verwundbarkeiten. Sobald Pakete
übertragen werden, ist es aus mit der Sicherheit. Zumal unter
RISC OS ja jeder User automatisch Root-Rechte hat und auf der Maschine
alles darf.

Die Frage ist, was passieren kann. Der Rechner kann nur Daten senden und
empfangen. Ein Angriff kann nur über die empfangenen Daten geschehen.
Inwiefern können die bei RISC OS etwas auslösen, was gefährlich wäre?
Das wäre interessant zu wissen. Soweit ich weiß, gibt es keine
Fernsteuerung oder einen Mechanismus unter RISC OS, der empfangene Daten
automatisch startet. Zumindest von Haus aus. Aber ich habe mich bisher
nicht näher damit beschäftigt.

Ich würde es auch gerne wissen. Allerdings muß ich sagen, daß sich das Teil
bislang recht gut geschlagen hat, wenn ich mir Attacken seit Inbetriebnahme
so anschaue. BSD ist meiner Erfahrung nach früher wesentlich solider als
LINUX programmiert gewesen. Es ist ja auch nicht sicher, was da war. Die
bisherigen Checks haben bislang nichts Verwerfliches zu Tage gefördert,
aber ich bin noch nicht durch und das Erlebnis, wird mir Ansporn sein, die
Umgebung weiter zu abzusichern.

Ich denke, man kann durchaus sagen, daß solange Du keine
"Individualbehandlung" von Profis bekommst, RISC OS auch in älteren Versionen
recht gut abschneidet.

Nebenbei, bei meinem NAS bin ich auch so an einer Katastrophe vorbei
geschrammt. Die Geräte wurden, während ich Probleme mit dem Provider hattem
reihenweise gehackt. Grund war wohl ein Dienst, den man fürs Netz aktivieren
kann, was ich aber nie hatte. Es erwischt also auch LINUX "Profi"-Software.
Dabei wurde im NAS Fall die /etc/hosts geändert. Das ist nichts, was man mit
dem normalen Accounts machen kann.

Ich bin heil froh, daß RISC OS keine Parallelsitzungen kann. Wenn da im
Hintergrund erst was läuft, ist es ätzend schwierig es zu entdecken.

Thomas Milius



Other related posts: