Chromium-Browser in "user"

[Lutz E. Cerning]

Hallo allerseits,
vorhin habe ich mir den aktuellwn Comium-Browser von
<https://chromium.woolyss.com/> installiert. Gefällt mir gut, nur:
Ist es ein Sicherheitsrisiko dass er sich in
...AppData\Local\Chromium\Application und *nicht* in den
Programme-Ordner installieren will?
Oder habe ich da nur etwas übersehen?

--
Grüße von LutzeC*54 aus
(ca.) 52.64736,13.550518

[Marco Moock]

Am Mittwoch, 03. August 2022, um 19:53:01 Uhr schrieb Lutz E. Cerning:

> Ist es ein Sicherheitsrisiko dass er sich in
> ...AppData\Local\Chromium\Application und *nicht* in den
> Programme-Ordner installieren will?
> Oder habe ich da nur etwas übersehen?

Sicherheitsrisiko nicht - aber je nach Installer ist das normal. Viele
bieten das an, sodass man auch ohne Adminrechte Software installieren
und nutzen kann.

Ob die von dir genannte Seite offiziell von Google ist weiß ich nicht.
Da würde ich mir mehr sorgen machen.

[Stefan Kanthak]

"Lutz E. Cerning" <luc...@gmail.com> schrieb:

> Ist es ein Sicherheitsrisiko dass er sich in
> ...AppData\Local\Chromium\Application und *nicht* in den
> Programme-Ordner installieren will?

Ja. Und obendrein STRUNZEND DUMM:
1) seit 50+ Jahren wird von allen ernst zu nehmenden Betruebssystem
ausfuehrbarer Code im Hauptspeicher nur NICHT-(ueber)schreibbar
geladen (<https://en.wikipedia.org/wiki/Code_segment> vs.
<https://en.wikipedia.org/wiki/Data_segment>);
2) seit 20 Jahren werden (ueber)schreibbare Daten NICHT-ausfuehrbar
geladen ("Write XOR Execute" <https://en.wikipedia.org/wiki/W%5EX>
alias "data execution prevention"
<https://msdn.microsoft.com/en-us/library/aa366553.aspx>)

> Oder habe ich da nur etwas übersehen?

Ja. Dass diese Trennung selbstverstaendlich auch im Dateisystem
vorgenommen (siehe
<https://msdn.microsoft.com/en-us/library/bb776776.aspx#installing-your-application-properly>)
und dann (beispielsweise) mittels SAFER effektiv durchgesetzt wird
(siehe <https://skanthak.homepage.t-online.de/SAFER.html>)

Stefan
--
<https://www.duden.de/rechtschreibung/Kanthaken>

[Arno Welzel]

Lutz E. Cerning, 2022-08-03 19:53:

> Hallo allerseits,
> vorhin habe ich mir den aktuellwn Comium-Browser von
> <https://chromium.woolyss.com/> installiert. Gefällt mir gut, nur:
> Ist es ein Sicherheitsrisiko dass er sich in
> ...AppData\Local\Chromium\Application und *nicht* in den
> Programme-Ordner installieren will?

Ja.

> Oder habe ich da nur etwas übersehen?

Nein.

Das ist leider bei etlichen Anwendungen mittlerweile üblich, weil man so
keine administrativen Rechte braucht - aber es ist eben auch unsicher,
weil so Malware natürlich die Daten ebenfalls leicht manipulieren kann.


--
Arno Welzel
https://arnowelzel.de

[Marco Moock]

Am Donnerstag, 04. August 2022, um 10:29:41 Uhr schrieb Arno Welzel:

> Das ist leider bei etlichen Anwendungen mittlerweile üblich, weil man
> so keine administrativen Rechte braucht - aber es ist eben auch
> unsicher, weil so Malware natürlich die Daten ebenfalls leicht
> manipulieren kann.

Das kann Malware aber auch ganze ohne die Installation in AppData.
Wer der Software nicht traut, sollte sie nicht auf dem Produktivsystem
ausführen.
Und mit Adminrechten kann man de facto auf alles im System zugreifen.

[Arno Welzel]

Marco Moock, 2022-08-04 11:48:

> Am Donnerstag, 04. August 2022, um 10:29:41 Uhr schrieb Arno Welzel:
>
>> Das ist leider bei etlichen Anwendungen mittlerweile üblich, weil man
>> so keine administrativen Rechte braucht - aber es ist eben auch
>> unsicher, weil so Malware natürlich die Daten ebenfalls leicht
>> manipulieren kann.
>
> Das kann Malware aber auch ganze ohne die Installation in AppData.

Wie genau soll Malware die Binaries installierter Anwendungen
modifizieren, wenn sie darauf keine Schreibrechte hat?

> Wer der Software nicht traut, sollte sie nicht auf dem Produktivsystem
> ausführen.

Und wer Software traut, sollte sie nicht so installieren, dass sie von
Malware jederzeit leicht verändert werden kann.

> Und mit Adminrechten kann man de facto auf alles im System zugreifen.

Malware hat aber üblicherweise keine Adminrechte.

[Marco Moock]

Am Donnerstag, 04. August 2022, um 18:47:15 Uhr schrieb Arno Welzel:

> Wie genau soll Malware die Binaries installierter Anwendungen
> modifizieren, wenn sie darauf keine Schreibrechte hat?

Die kann die Daten des ausführenden Users missbrauchen wie sie will -
ganz ohne Adminrechte.

> > Wer der Software nicht traut, sollte sie nicht auf dem
> > Produktivsystem ausführen.
>
> Und wer Software traut, sollte sie nicht so installieren, dass sie von
> Malware jederzeit leicht verändert werden kann.

ok, das macht Sinn, ändert aber nichts daran, dass Malware direkt auf
die Daten des Users zugreifen kann.

> > Und mit Adminrechten kann man de facto auf alles im System
> > zugreifen.
>
> Malware hat aber üblicherweise keine Adminrechte.

Und auch ohne die kann sie die Dateien des Users lesen und ändern.
Zudem führen viele Leute praktisch jede Software aus dem Internet
ungeprüft aus, auch wenn die UAC-Abfrage kommt.
Bei DAUs klappt das meist immer.

[Lutz E. Cerning]

Lutz E. Cerning schrieb :

> vorhin habe ich mir den aktuellwn Comium-Browser von
> <https://chromium.woolyss.com/> installiert. Gefällt mir gut, nur:

Ihr habt ja recht - habs wieder deinstalliert.
Warum machen die so was? Die sind doch nicht blöde, diese ganze Masse
von Leuten die an so einem (freien) Browser arbeiten, na ja...

[Stefan Kanthak]

"Lutz E. Cerning" <luc...@gmail.com> schrieb:

> Lutz E. Cerning schrieb :
>
>> vorhin habe ich mir den aktuellwn Comium-Browser von
>> <https://chromium.woolyss.com/> installiert. Gefällt mir gut, nur:
>
> Ihr habt ja recht - habs wieder deinstalliert.
> Warum machen die so was? Die sind doch nicht blöde,

Aber UNFAEHIG und SCHLAMPIG!
Das erkennst Du beispielsweise am XML-Tag
<maxversiontested Id="10.0.18362.0"/>
des in den ausfuehrbaren (IGITT!) Installationsprogrammen eingebetteten
Manifests: 10.0.18362.0 ist Windows 10 1903, das von Microsoft seit
ueber zwei Jahren NICHT mehr gepflegt wird.
Ausserdem am Missbrauch einer VERALTETEN Entwicklungsumgebung und
deren UNSICHEREN statischen libcmt.lib: die Programme wurden mit
LINK.exe 14.0 fuer Windows XP bzw. Windows 2003 als Zielsystem gebunden.

Alternativ daran, dass ADVAPI32.dll als "delay load" gebunden wurde:
das ist VOELLIGER SCHWACHSINN, denn ADVAPI32.dll ist seit Anbeginn der
eNTe eine "known DLL" (im Gegensatz zu dbghelp.dll, winmm.dll und
EINIGEN anderen DLLs, die diese AHNUNGSLOSEN Frickler aus dem
"application directory" laden lassen).
Und zu schlechterletzt noch daran, dass dieses DREXZEUX anfaellig fuer
DLL-Hijacking ist.

> diese ganze Masse von Leuten die an so einem (freien) Browser arbeiten,
> na ja...

"Viele Koeche verderben den Brei!"

EINMAL mit Profis arbeiten...
Stefan
--
<https://www.duden.de/rechtschreibung/Kanthaken>

[Arno Welzel]

Marco Moock, 2022-08-04 18:55:

> Am Donnerstag, 04. August 2022, um 18:47:15 Uhr schrieb Arno Welzel:
>
>> Wie genau soll Malware die Binaries installierter Anwendungen
>> modifizieren, wenn sie darauf keine Schreibrechte hat?
>
> Die kann die Daten des ausführenden Users missbrauchen wie sie will -
> ganz ohne Adminrechte.

Darum ging es aber nicht.

[...]

>> Und wer Software traut, sollte sie nicht so installieren, dass sie von
>> Malware jederzeit leicht verändert werden kann.
>
> ok, das macht Sinn, ändert aber nichts daran, dass Malware direkt auf
> die Daten des Users zugreifen kann.

Richtig. Ich sprach aber nicht von den Daten des Users sondern den
Dateien der Anwendung, die ja auch "Daten" sind.

>>> Und mit Adminrechten kann man de facto auf alles im System
>>> zugreifen.
>>
>> Malware hat aber üblicherweise keine Adminrechte.
>
> Und auch ohne die kann sie die Dateien des Users lesen und ändern.

Richtig. Aber um die Dateien ds Users ging es aber nicht.

> Zudem führen viele Leute praktisch jede Software aus dem Internet
> ungeprüft aus, auch wenn die UAC-Abfrage kommt.
> Bei DAUs klappt das meist immer.

Bei DAUs ist jede Diskuskussion über Sicherheitsmaßnahmen vollkommen
überflüssig. Und alle Anderen wissen ja, was sie tun und müssen nicht
mehr darüber reden. Also können wir uns die komplette Diskussion
eigentlich sparen.

[Arno Welzel]

Lutz E. Cerning, 2022-08-04 19:37:

> Lutz E. Cerning schrieb :
>
>> vorhin habe ich mir den aktuellwn Comium-Browser von
>> <https://chromium.woolyss.com/> installiert. Gefällt mir gut, nur:
>
> Ihr habt ja recht - habs wieder deinstalliert.
> Warum machen die so was? Die sind doch nicht blöde, diese ganze Masse
> von Leuten die an so einem (freien) Browser arbeiten, na ja...

Die Leute, die den Kern von Chromium entwickeln sind *nicht* die Leute,
die die Windows-Version daraus erstellen!

[Peter J. Holzer]

On 2022-08-04 16:03, Martin Gerdes <martin...@gmx.de> wrote:
> Andreas Kohlbach <a...@spamfence.net> schrieb:
>> Ich würde Chromium (oder jede andere Software) nur von Originalseiten
>> herunterladen.
>
> Das auch.

ACK.


> Das Sicherheitsrisiko liegt darin, daß ein ausführbares Programm in den
> Nutzerdatenbereich installiert und dort ausgeführt wird. Ich würde mal
> sagen: typisches Malwareverfahren, das bei der üblichen systematisch
> unsicheren Installationsmethode von Windows auch reibungslos
> funktioniert.
>
> Es hat etwas für sich, daß in Programmbereiche nur ein Administrator
> schreiben kann (dann kann der Normaluser sich seine Programme nicht (so
> leicht) zerschießen und auch keine eigenen Programme installieren). Dazu
> gehört aber auch, daß in Plattenbereichen, in die der Nutzer schreiben
> darf, keine Programme ausgeführt werden dürfen.

Die meisten User wären unglücklich, wenn sie ihre Excel-Files nicht
selbst beschreiben dürften.

Ja, ein Excel-File ist ein Programm. Es gibt keinen prinzipiellen
Unterschied zwischen einem Excel-File und einem Python-Script. Beide
enthalten Programmcode, der von einem Interpreter (excel.exe oder
python.exe) interpretiert wird. Ein Unterschied ist, dass Excel zwischen
"harmlosen" und "potenziell gefährlichen" Instruktionen unterscheidet
und optional die Ausführung von letzteren verweigern kann, während das
bei Python nicht vorgesehen ist. Aber das ist eher eine graduelle
Unterscheidung als eine prinzipielle.

In weiterer Folge ist auch der Unterschied zwischen einem Python-File
und einem EXE-File nur ein gradueller: Ersteres wird von einem anderen
Programm interpretiert, letzteres von der Hardware selbst (mit Hilfe von
Microcode (auch wieder ein Programm) und dem Betriebssystem (definitiv
ein Programm).

Das mit der Trennung von Programmen und Nicht-Programmen ist nicht so
einfach. Mal davon abgesehen, dass User mehr Programme schreiben sollten
und nicht weniger ...

hp

[Peter J. Holzer]

On 2022-08-05 08:07, Arno Welzel <use...@arnowelzel.de> wrote:
> Marco Moock, 2022-08-04 18:55:
>> Am Donnerstag, 04. August 2022, um 18:47:15 Uhr schrieb Arno Welzel:
>>> Wie genau soll Malware die Binaries installierter Anwendungen
>>> modifizieren, wenn sie darauf keine Schreibrechte hat?
>>
>> Die kann die Daten des ausführenden Users missbrauchen wie sie will -
>> ganz ohne Adminrechte.
>
> Darum ging es aber nicht.

Doch, im Endeffekt geht es genau darum. Die Programme auf einem PC sind
für sich nicht schützenswert - sie sind weder geheim noch schwer zu
ersetzen. Die Daten des Users hingegen sind es. Die Programme zu
schützen ist nur deshalb sinnvoll, weil sie für einen Angreifer einen
Weg zu den Userdaten bahnen können, und weil man annimmt, dass man durch
das Blockieren dieses Wegs die Userdaten schützt. Wenn es einen
direkteren Weg gibt, ist diese Annahme zumindest zweifelhaft.

hp

[Arno Welzel]

Peter J. Holzer, 2022-08-05 12:38:

[...]

> Die meisten User wären unglücklich, wenn sie ihre Excel-Files nicht
> selbst beschreiben dürften.
>
> Ja, ein Excel-File ist ein Programm. Es gibt keinen prinzipiellen

Aber kein Binary was direkten Zugriff auf beliebige Dateien des
Computers hat und API-Calls ausführen darf. Und die Ausführung von
Makros kann man wirksam unterbinden.

> Unterschied zwischen einem Excel-File und einem Python-Script. Beide
> enthalten Programmcode, der von einem Interpreter (excel.exe oder
> python.exe) interpretiert wird. Ein Unterschied ist, dass Excel zwischen
> "harmlosen" und "potenziell gefährlichen" Instruktionen unterscheidet
> und optional die Ausführung von letzteren verweigern kann, während das
> bei Python nicht vorgesehen ist. Aber das ist eher eine graduelle
> Unterscheidung als eine prinzipielle.

Deswegen würde man auch die Ausführung von Pyhton-Scripten, die der
Benutzer selber beschreiben darf, nicht zulassen, wenn man Sicherheit
ernstnmmt.

> Das mit der Trennung von Programmen und Nicht-Programmen ist nicht so
> einfach. Mal davon abgesehen, dass User mehr Programme schreiben sollten
> und nicht weniger ...

Doch, das ist sehr einfach.

[Arno Welzel]

Peter J. Holzer, 2022-08-05 13:12:

> On 2022-08-05 08:07, Arno Welzel <use...@arnowelzel.de> wrote:
>> Marco Moock, 2022-08-04 18:55:
>>> Am Donnerstag, 04. August 2022, um 18:47:15 Uhr schrieb Arno Welzel:
>>>> Wie genau soll Malware die Binaries installierter Anwendungen
>>>> modifizieren, wenn sie darauf keine Schreibrechte hat?
>>>
>>> Die kann die Daten des ausführenden Users missbrauchen wie sie will -
>>> ganz ohne Adminrechte.
>>
>> Darum ging es aber nicht.
>
> Doch, im Endeffekt geht es genau darum. Die Programme auf einem PC sind
> für sich nicht schützenswert - sie sind weder geheim noch schwer zu
> ersetzen. Die Daten des Users hingegen sind es. Die Programme zu

Falsch. *Alles* auf dem Computer ist schützenswert, nicht nur die Daten
des Users.

Beispiel:

Ein Browser, der z.B. für den Zugang auf Websites mit privaten Daten
genutzt wird, soll keine Hintertüren für Angreifer haben, die ihnen die
Daten, die er anzeigt, im Klartext zusenden oder die die Anzeige verfälscht.

Malware kann aber den Browser beliebig verändern oder gleich komplett
austausdchen, wenn die Installation keine administrativen Rechte
erfordert hat.

Ja, man kann auch so argumentieren, dass man ohnehin verloren hat,
sobald Malware zur Ausführung kommt und es dann auch egal ist, was die
Malware dann konkret macht. Dann kann man sich aber die Trennung
zwischen Administratorrechten und Benutzerrechten auf privat genutzten
Computern auch ganz sparen und das lediglich im Firmenumfeld so
handhaben, weil man da u.U. nicht möchte, dass Mitarbeiter an den
installierten Anwendungen etwas ändern.

[Peter J. Holzer]

On 2022-08-06 08:58, Arno Welzel <use...@arnowelzel.de> wrote:
> Peter J. Holzer, 2022-08-05 12:38:

>> Die meisten User wären unglücklich, wenn sie ihre Excel-Files nicht
>> selbst beschreiben dürften.
>>
>> Ja, ein Excel-File ist ein Programm. Es gibt keinen prinzipiellen
>
> Aber kein Binary was direkten Zugriff auf beliebige Dateien des
> Computers hat und API-Calls ausführen darf.

Ob Binary oder nicht ist völlig irrelevant (wie mein Python-Beispiel
demonstrieren sollte). Wichtig ist, welche Aktionen das Programm
ausführen kann.

> Und die Ausführung von Makros kann man wirksam unterbinden.

Dass man die Aktionen, die ein Excel-File ausführen kann, einschränken
kann, habe ich bereits geschrieben. Du erzählst da nichts Neues.
Trotzdem bleibt es ein Programm, und ob alles, was es noch tun kann,
harmlos ist, hängt von der Konfiguration, der Implementation (da gab es
immer wieder mal sehr interessante Edge-Cases) und auch vom Kontext ab.

Und das "Unterbinden von potentiell gefährlichen Aktionen" funktioniert
natürlich für Binaries und traditionelle Script-Sprachen genauso:
Praktisch jedes Betriebssystem der letzten 20 Jahre hat ein
Berechtigungssystem zumindest auf User-Basis. Etwas neuer aber IMHO auch
recht verbreitet sind Container-Systeme, die einzelne Applikationen
einschließen (primär zu erwähnen wären da die App-Systeme von iOS und
Android, aber es geht darüber hinaus. In Ubuntu 22.04 z.B. haben die
Browser (angeblich) nur sehr eingeschränkten Zugriff auf das Filesystem).

Also keine prinzipiellen Unterschiede. In allen Fällen hängt es von der
Umgebung (Interpreter, Betriebssystem, Hardware) ab, was ein Programm
tun kann.

> Deswegen würde man auch die Ausführung von Pyhton-Scripten, die der
> Benutzer selber beschreiben darf, nicht zulassen, wenn man Sicherheit
> ernstnmmt.

Diese Einstellung finde ich sehr bedauerlich. Der Benutzer wird damit
zum Knöpferldrücker degradiert, der das Potential eines Geräts, dessen
Stärke darin liegt, repetitive Aufgaben zu automatisieren, nicht
ausnützen kann. Das ist der hehren Klasse der Programmierer vorbehalten.

hp

[Peter J. Holzer]

On 2022-08-06 09:05, Arno Welzel <use...@arnowelzel.de> wrote:
> Peter J. Holzer, 2022-08-05 13:12:

>> Doch, im Endeffekt geht es genau darum. Die Programme auf einem PC sind
>> für sich nicht schützenswert - sie sind weder geheim noch schwer zu
>> ersetzen. Die Daten des Users hingegen sind es. Die Programme zu
>
> Falsch. *Alles* auf dem Computer ist schützenswert, nicht nur die Daten
> des Users.
>
> Beispiel:

Warum schneidest Du den Teil des Absatzes weg, in dem ich genau auf
dieses Argument eingegangen bin?

hp

[Peter J. Holzer]

On 2022-08-06 13:45, Martin Gerdes <martin...@gmx.de> wrote:
> "Peter J. Holzer" <hjp-u...@hjp.at> schrieb:

>> Ja, ein Excel-File ist ein Programm.
>

> Nein, natürlich nicht. Es ist denkbar, daß eine Excel-Datei aktive
> Inhalte enthält (meine tun das sämtlich nicht), aber zwingend ist das
> nicht.

Ein Excel-File ist vom Prinzip her ein Programm. Jede Zelle enthält
ausführbaren Code. Der Code mag nur langweilige Sachen machen wie die
Summe von zwei anderen Zellen berechnen, aber Du kannst auch in Python
ein Programm schreiben, das nur
print(1+2)
enthält, und niemand wird behaupten, dass das kein Programm sei.

Du kannst jetzt einwenden, dass damit ja nur die Inhalte des Excel-Files
selbst geändert werden können, aber auch eine Turing-Maschine kann nur
ihr eigenes Band beschreiben. Das ist also kein Kriterium, um zwischen
Programmen und Nicht-Programmen zu unterscheiden.

(Und wenn wir von Turing-Maschinen sprechen: Excel war lange Zeit nicht
turing-vollständig (ein Merkmal "richtiger" Programmiersprachen, wenn
auch IMHO ein eher theoretisches), diese Lücke wurde aber wenn ich mich
recht erinnere vor etlichen Jahren durch die Einführung rekursiver
Funktionen geschlossen.)

hp

[Lars Gebauer]

Am 06.08.2022 um 21:37 schrieb Peter J. Holzer:
> On 2022-08-06 13:45, Martin Gerdes <martin...@gmx.de> wrote:
>> "Peter J. Holzer" <hjp-u...@hjp.at> schrieb:
>>> Ja, ein Excel-File ist ein Programm.
>>
>> Nein, natürlich nicht. Es ist denkbar, daß eine Excel-Datei aktive
>> Inhalte enthält (meine tun das sämtlich nicht), aber zwingend ist das
>> nicht.
>
> Ein Excel-File ist vom Prinzip her ein Programm.

Nein. Mit einem Excel-File wird der Excel-Interpreter parametrisiert.
Das macht das File noch langer nicht zum Programm.

> Jede Zelle enthält ausführbaren Code.

Der ohne den Interpreter überhaupt nichts macht.

> Der Code mag nur langweilige Sachen machen wie die
> Summe von zwei anderen Zellen berechnen, aber Du kannst auch in Python
> ein Programm schreiben, das nur
> print(1+2)
> enthält, und niemand wird behaupten, dass das kein Programm sei.

Doch, ich.

Auch das Python-Skript ist kein Programm. Es mag umgangssprachlich so
genannt werden - ist aber trotzdem keins.

Das Skript entält lediglich eine Reihe von Anweisungen die den
Python-Interpreter dazu bewegen, irgendwas zu tun. So, wie das
Excel-File. Ohne Interpreter sind beide nutzlos.

Goethes Faust als ASCII-File ist auch kein Programm. Ebenso wenig, wie
Schillers Glocke. Aber mit beiden kann der Text-Betrachter/Editor (=
Interpreter) zu irgendwas bewegt (= parametrisiert) werden. Den Text am
Bildschirm anzuzeigen, bspw. Oder ihn an den Drucker zu schicken.

Mit Goethes Faust als html geht das sogar in hübsch. Aber weder das html
noch das dazugehörige css sind Programme. Der Browser, der den Kram
interpretiert, der ist das Programm. Füge ich zum Faust noch etwas
Javascript hinzu, wirds immer noch kein Programm. Lediglich der Browser
bekommt mehr zum Interpretieren.

Meine Kamera erzeugt keine Programme - sondern .jpgs. Mit diesen
wiederum kann der Bildbetrachter parametrisiert werden, so daß am
Bildschirm ein Bild angezeigt wird.

Umgangssprachlich mag man Python-, Javascript-, Perl- und was weiß ich
-Skripte als Programme bezeichnen. Ist auch kein Problem weil allgemein
klar ist, was gemeint ist. Dennoch dienen die nur dazu, Programme zu
parametrisieren.
--
"Nein, ich habe keine Angst vor der Klimakrise, also vor der Zukunft.
Wir sind ja mittendrin. Es ist doch nicht so, dass die Welt eine ganz
andere sein wird, sobald wir 1,5 Grad Erderhitzung erreichen."
--Friederike Otto

[Laurenz Trossel]

On 2022-08-06, Lars Gebauer <lgeb...@live.de> wrote:

> Meine Kamera erzeugt keine Programme - sondern .jpgs. Mit diesen
> wiederum kann der Bildbetrachter parametrisiert werden, so daß am
> Bildschirm ein Bild angezeigt wird.

.. oder das enthaltene Programm ausgeführt wird.

https://www.securityweek.com/google-says-nso-pegasus-zero-click-most-technically-sophisticated-exploit-ever-seen

[Peter J. Holzer]

On 2022-08-06 20:24, Lars Gebauer <lgeb...@live.de> wrote:
> Auch das Python-Skript ist kein Programm. Es mag umgangssprachlich so
> genannt werden - ist aber trotzdem keins.
>
> Das Skript entält lediglich eine Reihe von Anweisungen die den
> Python-Interpreter dazu bewegen, irgendwas zu tun. So, wie das
> Excel-File. Ohne Interpreter sind beide nutzlos.

Ohne Interpreter ist jedes Programm nutzlos. Auch ein x86-Binary tut
ohne Interpreter (Prozessor oder Emulator) gar nichts.

Ich empfehle Andrew S. Tanenbaum: "Structured Computer Organization"
(1976) zu diesem Thema.

hp

[Lars Gebauer]

Am 07.08.2022 um 09:11 schrieb Peter J. Holzer:
> On 2022-08-06 20:24, Lars Gebauer <lgeb...@live.de> wrote:
>> Auch das Python-Skript ist kein Programm. Es mag umgangssprachlich so
>> genannt werden - ist aber trotzdem keins.
>>
>> Das Skript entält lediglich eine Reihe von Anweisungen die den
>> Python-Interpreter dazu bewegen, irgendwas zu tun. So, wie das
>> Excel-File. Ohne Interpreter sind beide nutzlos.
>
> Ohne Interpreter ist jedes Programm nutzlos.

Eben. Aber weder Goethes Faust noch Schillers Handschuh sind Programme.
Obwohl sie sich in ihrer Wirkungsweise auf den Interpreter kaum vom
Python-Skript unterscheiden.

[Peter J. Holzer]

On 2022-08-07 08:01, Lars Gebauer <lgeb...@live.de> wrote:
> Am 07.08.2022 um 09:11 schrieb Peter J. Holzer:
>> On 2022-08-06 20:24, Lars Gebauer <lgeb...@live.de> wrote:
>>> Auch das Python-Skript ist kein Programm. Es mag umgangssprachlich so
>>> genannt werden - ist aber trotzdem keins.
>>>
>>> Das Skript entält lediglich eine Reihe von Anweisungen die den
>>> Python-Interpreter dazu bewegen, irgendwas zu tun. So, wie das
>>> Excel-File. Ohne Interpreter sind beide nutzlos.
>>
>> Ohne Interpreter ist jedes Programm nutzlos.
>
> Eben. Aber weder Goethes Faust noch Schillers Handschuh sind Programme.

Richtig.

> Obwohl sie sich in ihrer Wirkungsweise auf den Interpreter kaum vom
> Python-Skript unterscheiden.

Aber nicht deswegen (auch ein Binary Executable unterscheidet sich in
seiner Wirkungsweise auf den Prozessor nicht wesentlich.)

Ein Programm ist ein in einer Programmiersprache notierter Algorithmus.

Faust und Handschuh spezifizieren aber keinen Algorithmus[1], und sie
sind in keiner Programmiersprache geschrieben. US-ASCII oder HTML sind
keine Programmiersprachen, weil sich in ihnen keine Algorithmen
beschreiben lassen (manche Leute sind noch strikter und verlangen, dass
eine Programmiersprache alle Algorithmen abbilden können muss - mir
reicht es, wenn es ein brauchbares Subset gibt). Maschinencode,
Assembler, C, Python, PostScript und Brainfuck sind zweifellos
Programmiersprachen, sogar turing-vollständige. Excel mag für manche das
Kriterium der Sprache nicht erfüllen, aber für jemanden, der mal ein
paar Theoretische-Informatik-Vorlesungen besucht hat, ist jedes
Fileformat eine formale Sprache, und man kann darin Algorithmen
spezifizieren, also ist es eine Programmiersprache (vielleicht nicht
turing-vollständig).

JavaScript ist ebenfalls eindeutig eine Programmiersprache. CSS ist ein
interessanter Grenzfall: Es wurde gezeigt, dass CSS ausreicht, um einen
Schritt einer Turing-Maschine zu implementieren. In einem Browser
braucht man dann noch einen externen Taktgeber (einen Menschen, der
immer auf den "Weiter"-Button klickt, oder ein JavaScript-Programm, das
das macht), aber eine Implementation, in der das automatisch passiert,
wäre leicht denkbar. Aber auch ohne das erlaubt CSS die Implementation
interessanter Algorithmen zur Transformation von HTML in gerenderten
Output. Im Zweifelsfall würde ich das daher auch als Programmiersprache
ansehen.

hp

[1] Jedenfalls für Informatiker. Ich überlasse es den
Theaterwissenschaftlern, ob sie den geschriebenen Text eines
Theaterstück als Algorithmus für die Schauspieler auffassen wollen.

[Lars Gebauer]

Am 07.08.2022 um 13:50 schrieb Peter J. Holzer:
> Ein Programm ist ein in einer Programmiersprache notierter Algorithmus.

Nö. Das mag man ja umgangssprachlich "Programm" nennen - aber streng
genommen ist es nur ein Notat, oft irgendein Skript.

Ich könnte auch jede Interpreter-Anweisung einzeln interaktiv an der
Konsole eingeben.

Aber a) würde ich beizeiten die Übersicht verlieren, b) wäre das ein
sehr fehlerträchtiges Verfahren, c) würde das viel zu lange dauern und
d) würde ich mich der Möglichkeit der Wiederverwendung berauben.

Deswegen macht man das nur bei sehr kleinen, sehr wenig komplexen und
vergleichsweise sehr selten vorkommenden Aufgaben.

Deswegen ist es allermeist viel sinnvoller, sämtliche Anweisungen zu
notieren[sic!] und dieses Notat dem Interpreter zu Abarbeitung en bloc
zu übergeben.

> Faust und Handschuh spezifizieren aber keinen Algorithmus[1], und sie
> sind in keiner Programmiersprache geschrieben. US-ASCII oder HTML sind
> keine Programmiersprachen, weil sich in ihnen keine Algorithmen
> beschreiben lassen (manche Leute sind noch strikter und verlangen, dass
> eine Programmiersprache alle Algorithmen abbilden können muss - mir
> reicht es, wenn es ein brauchbares Subset gibt).

Ich habe auch nie behauptet, daß es Programme wären. Obwohl ich es
könnte, würde ich Deine Definition akzeptieren. Aber nach Deiner
Definition gäbe es ja nur und ausschließlich Programme - weswegen ich
die für wenig sinnvoll halte.

Der Interpreter, der ist das Programm. Alles andere - Notat, Skript,
Quellcode, Excel-File etc.pp. - parametrisiert lediglich dieses Programm
und ist ohne dieses Programm wertlos.

[Peter J. Holzer]

On 2022-08-07 14:21, Lars Gebauer <lgeb...@live.de> wrote:
> Am 07.08.2022 um 13:50 schrieb Peter J. Holzer:
>> Ein Programm ist ein in einer Programmiersprache notierter Algorithmus.
>
> Nö. Das mag man ja umgangssprachlich "Programm" nennen - aber streng
> genommen ist es nur ein Notat, oft irgendein Skript.

Nach deiner Privat-Definition. Mag sein. Du kennst die Geschichte "Ein
Tisch ist ein Tisch" von Peter Bichsel?

hp

[Lars Gebauer]

Nein.

[Arno Welzel]

Peter J. Holzer, 2022-08-06 13:26:

> On 2022-08-06 08:58, Arno Welzel <use...@arnowelzel.de> wrote:

[...]

>> Deswegen würde man auch die Ausführung von Pyhton-Scripten, die der
>> Benutzer selber beschreiben darf, nicht zulassen, wenn man Sicherheit
>> ernstnmmt.
>
> Diese Einstellung finde ich sehr bedauerlich. Der Benutzer wird damit
> zum Knöpferldrücker degradiert, der das Potential eines Geräts, dessen
> Stärke darin liegt, repetitive Aufgaben zu automatisieren, nicht
> ausnützen kann. Das ist der hehren Klasse der Programmierer vorbehalten.

Korrekt! Genau das *SOLL* auch so sein, wenn SICHERHEIT im Vordergrund
steht!

Du willst ganz sicher nicht, dass z.B. Mitarbeiter einer Bank, eines
Arztes oder eines Krankenhauses auf dem Computer, der als Arbeitsmittel
dient, irgendwelche Scripte ausführt, nur weil ihm die Arbeit mit der
von der bereitgestellten Software zu umständlich ist. Genau dabei könnte
selbst ohne Malware auch viel schief laufen, wenn der jeweilige Mensch
nicht genau aufpasst, dass seine "Automatisierung" nicht versehentlich
irgend einen Mist baut.

[Peter J. Holzer]

On 2022-08-08 10:29, Martin Gerdes <martin...@gmx.de> wrote:
> "Peter J. Holzer" <hjp-u...@hjp.at> schrieb:

>|Die meisten Netizens wären unglücklich, wenn sie keine Haare mehr
>|spalten dürften.
>
> Das gilt offensichtlich speziell für Dich.

Ich habe schon beim ersten Mal verstanden, dass Du mich meinst.

Aber tatsächlich mache ich genau das Gegenteil. Ich spalte nicht ein
Haar, ich betrachte den ganzen Pelz.


> Meinen Einwand mit der Verringerung der Exposition durch Ausschluß
> eindeutig ausführbarer Programme hast Du nonchalant gesnippt.
> Offensichtlich hast Du kein gutes Argument dagegen.

Ich habe keine belastbaren Statistiken bzw. bin zu faul, welche zu
suchen. Es würde also meine unbelegte Meinung gegen deine unbelegte
Meinung stehen. Dafür ist mir meine Zeit zu schade.

hp

[Peter J. Holzer]

On 2022-08-08 15:48, Arno Welzel <use...@arnowelzel.de> wrote:
> Peter J. Holzer, 2022-08-06 13:26:
>> On 2022-08-06 08:58, Arno Welzel <use...@arnowelzel.de> wrote:
>>> Deswegen würde man auch die Ausführung von Pyhton-Scripten, die der
>>> Benutzer selber beschreiben darf, nicht zulassen, wenn man Sicherheit
>>> ernstnmmt.
>>
>> Diese Einstellung finde ich sehr bedauerlich. Der Benutzer wird damit
>> zum Knöpferldrücker degradiert, der das Potential eines Geräts, dessen
>> Stärke darin liegt, repetitive Aufgaben zu automatisieren, nicht
>> ausnützen kann. Das ist der hehren Klasse der Programmierer vorbehalten.
>
> Korrekt! Genau das *SOLL* auch so sein, wenn SICHERHEIT im Vordergrund
> steht!
>
> Du willst ganz sicher nicht, dass z.B. Mitarbeiter einer Bank, eines
> Arztes oder eines Krankenhauses auf dem Computer, der als Arbeitsmittel
> dient, irgendwelche Scripte ausführt, nur weil ihm die Arbeit mit der
> von der bereitgestellten Software zu umständlich ist.

Zwei Seelen wohnen ach in meiner Brust. Einerseits ist der Wildwuchs an
von Usern geschriebenen Scripts (sprich: Excel-Files und
Access-Datenbanken) in vielen Betrieben tatsächlich ein Problem.
Andererseits ist der Mangel an Automatisierung auch eines - repetitive
Handlungen sind nicht nur geisttötend sondern auch fehleranfällig. Die
Lösung besteht vermutlich in mehr und nicht weniger.

> Genau dabei könnte selbst ohne Malware auch viel schief laufen, wenn
> der jeweilige Mensch nicht genau aufpasst, dass seine
> "Automatisierung" nicht versehentlich irgend einen Mist baut.

Die baut dann wenigstens reproduzierbar Mist. Der Mensch hingegen
zufällig.

hp

[Arno Welzel]

Peter J. Holzer, 2022-08-08 23:53:

> On 2022-08-08 15:48, Arno Welzel <use...@arnowelzel.de> wrote:

[...]

>> Du willst ganz sicher nicht, dass z.B. Mitarbeiter einer Bank, eines
>> Arztes oder eines Krankenhauses auf dem Computer, der als Arbeitsmittel
>> dient, irgendwelche Scripte ausführt, nur weil ihm die Arbeit mit der
>> von der bereitgestellten Software zu umständlich ist.
>
> Zwei Seelen wohnen ach in meiner Brust. Einerseits ist der Wildwuchs an
> von Usern geschriebenen Scripts (sprich: Excel-Files und
> Access-Datenbanken) in vielen Betrieben tatsächlich ein Problem.
> Andererseits ist der Mangel an Automatisierung auch eines - repetitive
> Handlungen sind nicht nur geisttötend sondern auch fehleranfällig. Die
> Lösung besteht vermutlich in mehr und nicht weniger.

Wenn bei täglichen Aufgaben immer wieder Dinge gemacht werden, die man
auch automatisieren könnte, wäre es Aufgabe der Verwantwortlichen, genau
dafür zu sorgen, um dadurch verursachte Fehler zu vermeiden.

>> Genau dabei könnte selbst ohne Malware auch viel schief laufen, wenn
>> der jeweilige Mensch nicht genau aufpasst, dass seine
>> "Automatisierung" nicht versehentlich irgend einen Mist baut.
>
> Die baut dann wenigstens reproduzierbar Mist. Der Mensch hingegen
> zufällig.

Ich arbeite selber seit gut 30 Jahren in der Softwareentwicklung -
"reproduzierbar" gilt nur, wenn auch die Umstände genau bekannt sind. Ob
ein von einem reinen Anwender selbst gebautes Script immer für alle
Fälle hinreichend getestet ist, wage ich zu bezweifeln. Dann ist das
Ergebnis im Fehlerfall mitunter auch "zufällig", weil niemand genau
weiß, unter welchem Umständen ein Script fehlerhaft arbeitet.

[Peter J. Holzer]

On 2022-08-09 13:33, Arno Welzel <use...@arnowelzel.de> wrote:
> Peter J. Holzer, 2022-08-08 23:53:
>> On 2022-08-08 15:48, Arno Welzel <use...@arnowelzel.de> wrote:
>>> Du willst ganz sicher nicht, dass z.B. Mitarbeiter einer Bank, eines
>>> Arztes oder eines Krankenhauses auf dem Computer, der als Arbeitsmittel
>>> dient, irgendwelche Scripte ausführt, nur weil ihm die Arbeit mit der
>>> von der bereitgestellten Software zu umständlich ist.
>>
>> Zwei Seelen wohnen ach in meiner Brust. Einerseits ist der Wildwuchs an
>> von Usern geschriebenen Scripts (sprich: Excel-Files und
>> Access-Datenbanken) in vielen Betrieben tatsächlich ein Problem.
>> Andererseits ist der Mangel an Automatisierung auch eines - repetitive
>> Handlungen sind nicht nur geisttötend sondern auch fehleranfällig. Die
>> Lösung besteht vermutlich in mehr und nicht weniger.
>
> Wenn bei täglichen Aufgaben immer wieder Dinge gemacht werden, die man
> auch automatisieren könnte, wäre es Aufgabe der Verwantwortlichen, genau
> dafür zu sorgen, um dadurch verursachte Fehler zu vermeiden.

Skaliert halt nicht. Und die Leute machen was auch immer notwendig ist,
um den Job zu erledigen. Wenn man ihnen geeignete Werkzeuge verweigert,
verwenden sie halt ungeeignete (oder verabschieden sich in die "innere
Emigration", wie das ein Kollege mal genannt hat).

>>> Genau dabei könnte selbst ohne Malware auch viel schief laufen, wenn
>>> der jeweilige Mensch nicht genau aufpasst, dass seine
>>> "Automatisierung" nicht versehentlich irgend einen Mist baut.
>>
>> Die baut dann wenigstens reproduzierbar Mist. Der Mensch hingegen
>> zufällig.
>
> Ich arbeite selber seit gut 30 Jahren in der Softwareentwicklung -

Ähnlich. Und fast 30 Jahre Systemadministration (gleichzeitig, nicht
hintereinander - der Schwerpunkt hat sich im Lauf der Zeit geändert).

> "reproduzierbar" gilt nur, wenn auch die Umstände genau bekannt sind. Ob
> ein von einem reinen Anwender selbst gebautes Script immer für alle
> Fälle hinreichend getestet ist, wage ich zu bezweifeln.

Natürlich nicht.

> Dann ist das Ergebnis im Fehlerfall mitunter auch "zufällig", weil
> niemand genau weiß, unter welchem Umständen ein Script fehlerhaft
> arbeitet.

Es lässt sich zumindest nachvollziehen, was passiert ist. Im Gegensatz
zu "ich habe gar nichts gemacht" oder "ich habe sicher X, Y und Z in
dieser Reihenfolge gemacht und es gab keine Fehlermeldung".
Kein Vorwurf. Passiert mir auch gelegentlich, dass sich die
Shell-History nicht mir meiner Erinnerung deckt, oder dass da drei
Kommandos weiter oben eine Fehlermeldung prangt, die ich absolut nicht
wahrgenommen habe. (Und ja, die täglichen Cron-Jobs, bei denen ein
halbes Jahr lang niemandem auffällt, dass sie nicht mehr funktionieren,
gibt es natürlich auch - Automatisierung hilft nicht immer.)

hp

[Arno Welzel]

Peter J. Holzer, 2022-08-09 22:40:

> On 2022-08-09 13:33, Arno Welzel <use...@arnowelzel.de> wrote:

[...]

>> Dann ist das Ergebnis im Fehlerfall mitunter auch "zufällig", weil
>> niemand genau weiß, unter welchem Umständen ein Script fehlerhaft
>> arbeitet.
>
> Es lässt sich zumindest nachvollziehen, was passiert ist. Im Gegensatz
> zu "ich habe gar nichts gemacht" oder "ich habe sicher X, Y und Z in
> dieser Reihenfolge gemacht und es gab keine Fehlermeldung".

Nö. Dann wird halt gesagt "ich habe Script X benutzt, hat sonst immer
funktioniert".

Und das selbe Script X nochmal auszuführen, zeigt den Fehler aber eben
nicht erneut, weil die vom Script angefassten Daten bereits verändert
wurden und daher der Fehler nicht mehr reproduzierbar ist. Welche Daten
vorher vorlagen, weiß der Anwender aber nicht mehr, weil er ja ein
Script dafür hat, damit er eben *nicht* die Daten selber anfassen muss.

[Arno Welzel]

Peter J. Holzer, 2022-08-06 21:37:

[...]

> (Und wenn wir von Turing-Maschinen sprechen: Excel war lange Zeit nicht
> turing-vollständig (ein Merkmal "richtiger" Programmiersprachen, wenn
> auch IMHO ein eher theoretisches), diese Lücke wurde aber wenn ich mich
> recht erinnere vor etlichen Jahren durch die Einführung rekursiver
> Funktionen geschlossen.)

Wenn man keine Makros zulässt, gibt es in Excel keine rekursiven Funktionen.

Excel ohne Makros ist genauso wenig eine "Programmiersprache" wie HTML
ohne JavaScript.

[Arno Welzel]

Lars Gebauer, 2022-08-06 22:24:

> Am 06.08.2022 um 21:37 schrieb Peter J. Holzer:

[...]

>> Der Code mag nur langweilige Sachen machen wie die
>> Summe von zwei anderen Zellen berechnen, aber Du kannst auch in Python
>> ein Programm schreiben, das nur
>> print(1+2)
>> enthält, und niemand wird behaupten, dass das kein Programm sei.
>
> Doch, ich.
>
> Auch das Python-Skript ist kein Programm. Es mag umgangssprachlich so
> genannt werden - ist aber trotzdem keins.

Es ist.

> Das Skript entält lediglich eine Reihe von Anweisungen die den
> Python-Interpreter dazu bewegen, irgendwas zu tun. So, wie das
> Excel-File. Ohne Interpreter sind beide nutzlos.

In bei Binaries ist eben die CPU der Interpreter. Oftmals nicht mal das,
weil die vermeintlichen "Binaries" tatsächlich Bytecode einer Runtime
wie C# oder Java sind, die aber vollen Zugriff auf das System-API hat
und damit genauso viel Schaden anrichten kann, wie ein "echtes" Binary.

Umgekehrt kann man auch "echte" Binaries in eine Sandbox stecken und den
Zugriff auf Daten außerhalb der Sandbox einschränken.

Der entscheidende Punkt ist, ob man es *vorgesehen* ist, mit den
Anweisungen Daten außerhalb der ausführenden Anwendung zu beeinflussen.
Ob das dann mit einem "echten" Binary passiert oder "nur" mit einem
Script, macht im Ergebnis keinen Unterschied.

[Arno Welzel]

Peter J. Holzer, 2022-08-06 13:31:

Weil ich die Aussage dieses Arguments nicht teile:

"Die Programme zu schützen ist nur deshalb sinnvoll, weil sie für einen
Angreifer einen Weg zu den Userdaten bahnen können, und weil man
annimmt, dass man durch das Blockieren dieses Wegs die Userdaten
schützt. Wenn es einen direkteren Weg gibt, ist diese Annahme zumindest
zweifelhaft."

Einen direkteren Weg als über die Programme gibt es halt nicht. Und ja,
auch "Malware als Datei abspeichern und dann ausführen", muss ein
*Programm* ermöglichen. Nur weil bei Windows jeder Müll, den man per
Browser herunterlädt, ausführbar sein darf, ändert nichts am Grundprinzip.

[Lars Gebauer]

Am 11.08.2022 um 18:22 schrieb Arno Welzel:
> Lars Gebauer, 2022-08-06 22:24:
>> Am 06.08.2022 um 21:37 schrieb Peter J. Holzer:
>>> Der Code mag nur langweilige Sachen machen wie die
>>> Summe von zwei anderen Zellen berechnen, aber Du kannst auch in Python
>>> ein Programm schreiben, das nur
>>> print(1+2)
>>> enthält, und niemand wird behaupten, dass das kein Programm sei.
>>
>> Doch, ich.
>>
>> Auch das Python-Skript ist kein Programm. Es mag umgangssprachlich so
>> genannt werden - ist aber trotzdem keins.
>
> Es ist.

Wie schon geschrieben: Dann ist jede Trennung Daten vs. Programme
aufgehoben. Meine Kamera erzeugt dann keine Bilder mehr sondern kleine
Programme. Jeder Knipser wird so zum Programmierer.

[Arno Welzel]

Lars Gebauer, 2022-08-11 20:27:

> Am 11.08.2022 um 18:22 schrieb Arno Welzel:
>> Lars Gebauer, 2022-08-06 22:24:
>>> Am 06.08.2022 um 21:37 schrieb Peter J. Holzer:
>>>> Der Code mag nur langweilige Sachen machen wie die
>>>> Summe von zwei anderen Zellen berechnen, aber Du kannst auch in Python
>>>> ein Programm schreiben, das nur
>>>> print(1+2)
>>>> enthält, und niemand wird behaupten, dass das kein Programm sei.
>>>
>>> Doch, ich.
>>>
>>> Auch das Python-Skript ist kein Programm. Es mag umgangssprachlich so
>>> genannt werden - ist aber trotzdem keins.
>>
>> Es ist.
>
> Wie schon geschrieben: Dann ist jede Trennung Daten vs. Programme
> aufgehoben. Meine Kamera erzeugt dann keine Bilder mehr sondern kleine
> Programme. Jeder Knipser wird so zum Programmierer.

Du scheinst eine sehr eigenwillige Auffassung zu haben, was
"Programmiersprache" bedeutet.

Die Bilder denier Kamera enthalten ja keine Befehle sondern nur die
Information zur Repräsentation von Bildern. Damit kannst Du weder
Dateien erzeugen lassen noch Programme starten.

Python dagegen besteht aus konkreten Befehlen, was der Computer tun
soll, was auch das Lesen und Schreiben von Dateien oder den Start
anderer Programme beinhaltet. Dass ein Interpreter nötig ist, damit der
Computer dieser Befehle ausführen kann, ändert nichts daran, dass es
dennoch ein Programm ist.

Andernfalls müsstest Du auch sagen, dass Programme mit Binärcode für
eine bestimmte CPU-Architektur keine Programme sind, weil sie auf einer
anderen CPU-Architektur nicht ausführbar sind ohne Emulation.

Alles, was mit einer Programmiersprache erstellt wird, ist ein Programm.
Und auch Python ist eine Progammiersprache. Ob zur Ausführung des
Programms der Quelltext compiliert oder interpretiert wird, ist dafür
völlig unterheblich. Das legt nur die Form fest, in der das Programm
vorliegt - eben als Quelltext, Bytecode oder Binary.

Auf mobilen Plattformen wie Android sind echte Binaries eher die
Ausnahme. Java und Kotlin erzeugen Bytecode - und das will man da auch
so, damit man nicht für jede CPU-Architektur ein angepasstes Binary
bereitstellen muss.

[Lars Gebauer]

Am 12.08.2022 um 17:29 schrieb Arno Welzel:
> Lars Gebauer, 2022-08-11 20:27:
>> Am 11.08.2022 um 18:22 schrieb Arno Welzel:
>>> Lars Gebauer, 2022-08-06 22:24:
>>>> Am 06.08.2022 um 21:37 schrieb Peter J. Holzer:
>>>>> Der Code mag nur langweilige Sachen machen wie die
>>>>> Summe von zwei anderen Zellen berechnen, aber Du kannst auch in Python
>>>>> ein Programm schreiben, das nur
>>>>> print(1+2)
>>>>> enthält, und niemand wird behaupten, dass das kein Programm sei.
>>>>
>>>> Doch, ich.
>>>>
>>>> Auch das Python-Skript ist kein Programm. Es mag umgangssprachlich so
>>>> genannt werden - ist aber trotzdem keins.
>>>
>>> Es ist.
>>
>> Wie schon geschrieben: Dann ist jede Trennung Daten vs. Programme
>> aufgehoben. Meine Kamera erzeugt dann keine Bilder mehr sondern kleine
>> Programme. Jeder Knipser wird so zum Programmierer.
>
> Du scheinst eine sehr eigenwillige Auffassung zu haben, was
> "Programmiersprache" bedeutet.

Äh, nein. :)

Es ging um Programme vs. Daten. Und meine Auffassung läuft darauf
hinaus, daß Daten Programme parametrisieren, selbst aber keine Programme
sind.

Die jpgs aus meiner Kamera parametrisieren den Bildbetrachter, der dann
ein Bild am Monitor anzeigt. Hierzu interpretiert der Bildbetrachter die
von der Kamera gelieferten Daten.

Mit Programmier*sprachen* hat das soviel erst mal nichts zu tun. (Bitte
keine (dümmliche) Ablenkerei probieren.)

[Peter J. Holzer]

On 2022-08-11 16:31, Arno Welzel <use...@arnowelzel.de> wrote:
> Peter J. Holzer, 2022-08-06 13:31:
>> On 2022-08-06 09:05, Arno Welzel <use...@arnowelzel.de> wrote:
>>> Peter J. Holzer, 2022-08-05 13:12:
>>>> Doch, im Endeffekt geht es genau darum. Die Programme auf einem PC sind
>>>> für sich nicht schützenswert - sie sind weder geheim noch schwer zu
>>>> ersetzen. Die Daten des Users hingegen sind es. Die Programme zu
>>>
>>> Falsch. *Alles* auf dem Computer ist schützenswert, nicht nur die Daten
>>> des Users.
>>>
>>> Beispiel:
>>
>> Warum schneidest Du den Teil des Absatzes weg, in dem ich genau auf
>> dieses Argument eingegangen bin?
>
> Weil ich die Aussage dieses Arguments nicht teile:

Das ist halt schwer zu erkennen, wenn Du so tust, als ob es gar nicht
geschrieben worden wäre. So hat es nur nach dem Wiederholen eines
bereits widerlegten (oder zumindest bestrittenen) Arguments ausgesehen.

> "Die Programme zu schützen ist nur deshalb sinnvoll, weil sie für einen
> Angreifer einen Weg zu den Userdaten bahnen können, und weil man
> annimmt, dass man durch das Blockieren dieses Wegs die Userdaten
> schützt. Wenn es einen direkteren Weg gibt, ist diese Annahme zumindest
> zweifelhaft."
>
> Einen direkteren Weg als über die Programme gibt es halt nicht.

Doch. Der Weg über vorhandene Programme ist nämlich immer ein
indirekter. Um die zu überschreiben, muss bereits Schadcode auf dem
angegriffenen Rechner laufen.[1] Der kann aber auch direkt seine
Tätigkeit durchführen, und muss nicht seine Payload irgendwo ablegen und
darauf warten/hoffen, dass sie der Benutzer irgendwann später ausführt.

Es kann durchaus Gründe geben, warum der indirekte Ansatz über
Executables sinnvoll oder sogar notwendig ist, aber es bleibt ein
indirekter Ansatz. Und wenn der direkte Weg (oder ein anderer indirekter
Weg, das ist ja nicht der einzige) möglich ist, dann bringt es halt
nicht viel, den indirekten zu blockieren.

hp

[1] Den Fall, dass man den Benutzer dazu bringt, das Executable selbst
zu überschreiben, ignoriere ich hier. Im Fall des Privat-PCs hat der
Benutzer ja Admin-Rechte und darf das (wenn auch mit einem weiteren
Schritt). Ebenso ignoriere ich mit dem Internet gesharte C-Laufwerke
und ähnliche Konfigurationsfehler.

[Marcel Mueller]

Am 03.08.22 um 19:53 schrieb Lutz E. Cerning:
> Hallo allerseits,
> vorhin habe ich mir den aktuellwn Comium-Browser von
> <https://chromium.woolyss.com/> installiert. Gefällt mir gut, nur:
> Ist es ein Sicherheitsrisiko dass er sich in
> ...AppData\Local\Chromium\Application und *nicht* in den
> Programme-Ordner installieren will?

Das liegt daran, dass es nur für einen User und nicht für alle
installiert wird. Dafür braucht man für die Installation keine Admin-Rechte.

Tatsächlich ist der Nachteil, dass der User darauf natürlich immer
Schreibrechte hat. Damit greift die Sicherheitsprüfung bei Veränderungen
von Dateien durch zwielichtige Programme nicht.

Andererseits kann eine Installation mit Userrechten eben auch keine
Administrativen Eingriffe in das System vornehmen, um selbiges
Benutzerübergreifend zu infizieren.
Das ist vor allem dann interessant, wenn man etwas von irgendwelchen
willkürlichen Webseiten installiert. Das ist mit Abstand das größte
Sicherheitsrisiko, egal wohin installiert wird.


Marcel

[Arno Welzel]

Lars Gebauer, 2022-08-12 18:23:

> Am 12.08.2022 um 17:29 schrieb Arno Welzel:
>> Lars Gebauer, 2022-08-11 20:27:
>>> Am 11.08.2022 um 18:22 schrieb Arno Welzel:
>>>> Lars Gebauer, 2022-08-06 22:24:
>>>>> Am 06.08.2022 um 21:37 schrieb Peter J. Holzer:
>>>>>> Der Code mag nur langweilige Sachen machen wie die
>>>>>> Summe von zwei anderen Zellen berechnen, aber Du kannst auch in Python
>>>>>> ein Programm schreiben, das nur
>>>>>> print(1+2)
>>>>>> enthält, und niemand wird behaupten, dass das kein Programm sei.
>>>>>
>>>>> Doch, ich.
>>>>>
>>>>> Auch das Python-Skript ist kein Programm. Es mag umgangssprachlich so
>>>>> genannt werden - ist aber trotzdem keins.
>>>>
>>>> Es ist.
>>>
>>> Wie schon geschrieben: Dann ist jede Trennung Daten vs. Programme
>>> aufgehoben. Meine Kamera erzeugt dann keine Bilder mehr sondern kleine
>>> Programme. Jeder Knipser wird so zum Programmierer.
>>
>> Du scheinst eine sehr eigenwillige Auffassung zu haben, was
>> "Programmiersprache" bedeutet.
>
> Äh, nein. :)
>
> Es ging um Programme vs. Daten. Und meine Auffassung läuft darauf
> hinaus, daß Daten Programme parametrisieren, selbst aber keine Programme
> sind.

Ein Python-Script ist aber ein Programm und keine "Daten". Und nein,
auch wenn ein Programm in Form eines Textes mit geschrieben Befehlen
vorliegt, ist es immer noch ein Programm.

Abgesehen davon ist die strikte Trennung des Arbeitsspeichers einers
Computers in Programm- und Datenspeicher schon seit mehreren Jahrzehnten
nicht mehr üblich. Statt dessen kennzeichnet man nur Teile des
Speicherhinhalt als "nicht ausführbar" für die CPU. Weiterhin ist auch
die Ausführung von einem Binärcode durch eine hartverdrahtete CPU auch
schon seit Jahrzehnten nicht mehr üblich. Verwendet wird Microcode, der
x86-Befehle interpretiert. Deiner Lesart nach, wären dann auch
x86-Binaries keine Programme, sondern nur Daten, die erst durch die CPU
interpretiert und durch Microcode ausgeführt wird.

> Die jpgs aus meiner Kamera parametrisieren den Bildbetrachter, der dann
> ein Bild am Monitor anzeigt. Hierzu interpretiert der Bildbetrachter die
> von der Kamera gelieferten Daten.

Nein, Bilddaten sind auch keine "Parameter", sondern einfach nur Daten.

> Mit Programmier*sprachen* hat das soviel erst mal nichts zu tun. (Bitte
> keine (dümmliche) Ablenkerei probieren.)

Mit der dümmlichen Ablenkerei hast *Du* angefangen.

[Lars Gebauer]

Am 16.08.2022 um 13:40 schrieb Arno Welzel:
> Lars Gebauer, 2022-08-12 18:23:

>> Es ging um Programme vs. Daten. Und meine Auffassung läuft darauf
>> hinaus, daß Daten Programme parametrisieren, selbst aber keine Programme
>> sind.
>
> Ein Python-Script ist aber ein Programm und keine "Daten". Und nein,
> auch wenn ein Programm in Form eines Textes mit geschrieben Befehlen
> vorliegt, ist es immer noch ein Programm.

Jetzt hast Du aber tüchtig mit dem Fuß aufgestampft. Ich bin beeindruckt!

Aber gut: Dann produziert meine Kamera eben lauter Programme. Kann ich
mit leben, ist mir nicht so wichtig.

>> Die jpgs aus meiner Kamera parametrisieren den Bildbetrachter, der dann
>> ein Bild am Monitor anzeigt. Hierzu interpretiert der Bildbetrachter die
>> von der Kamera gelieferten Daten.
>
> Nein, Bilddaten sind auch keine "Parameter", sondern einfach nur Daten.

Ja, Daten die ein Programm parametrisieren. So, wie ein Python-Skript.

--
"Das Problem ist nicht, dass eine relativ kleine Gruppe von Verrückten
behauptet, dass zwei plus zwei fünf ergibt, dass es zwölf verschiedene
Geschlechter gibt oder dass man bei der Energieversorgung die Gesetze
der Thermodynamik ignorieren kann. Das Problem ist, daß sich die große
Gruppe der Normalos künstlich dumm stellt und den selben Quatsch
behauptet, weil sie von den Verrückten nicht als verrückt bezeichnet
werden wollen."
--Vince Ebert

[Arno Welzel]

Lars Gebauer, 2022-08-16 15:21:

> Am 16.08.2022 um 13:40 schrieb Arno Welzel:
>> Lars Gebauer, 2022-08-12 18:23:
>>> Es ging um Programme vs. Daten. Und meine Auffassung läuft darauf
>>> hinaus, daß Daten Programme parametrisieren, selbst aber keine Programme
>>> sind.
>>
>> Ein Python-Script ist aber ein Programm und keine "Daten". Und nein,
>> auch wenn ein Programm in Form eines Textes mit geschrieben Befehlen
>> vorliegt, ist es immer noch ein Programm.
>
> Jetzt hast Du aber tüchtig mit dem Fuß aufgestampft. Ich bin beeindruckt!
>
> Aber gut: Dann produziert meine Kamera eben lauter Programme. Kann ich
> mit leben, ist mir nicht so wichtig.

Jetzt hast Du deine Ignoranz endgültig demonstriert. Dann eben nicht.

>
>>> Die jpgs aus meiner Kamera parametrisieren den Bildbetrachter, der dann
>>> ein Bild am Monitor anzeigt. Hierzu interpretiert der Bildbetrachter die
>>> von der Kamera gelieferten Daten.
>>
>> Nein, Bilddaten sind auch keine "Parameter", sondern einfach nur Daten.
>
> Ja, Daten die ein Programm parametrisieren. So, wie ein Python-Skript.

Nein, ein Python-Skript "parametrisiert" exakt gar nichts. Das *ist* ein
Programm.

Wenn Du etablierte Begrifflichkeiten der Informatik nicht magst, auch
gut. Aber bitte höre auf, so einen hochgradigen Unsinn zu verbreiten.

[Arno Welzel]

Peter J. Holzer, 2022-08-12 20:48:

> On 2022-08-11 16:31, Arno Welzel <use...@arnowelzel.de> wrote:

[..]

>> Einen direkteren Weg als über die Programme gibt es halt nicht.
>
> Doch. Der Weg über vorhandene Programme ist nämlich immer ein
> indirekter. Um die zu überschreiben, muss bereits Schadcode auf dem
> angegriffenen Rechner laufen.[1] Der kann aber auch direkt seine

[...]

Wofür wiederum ein Programm nötig ist, was es erlaubt, den Schadcode auf
den Rechner zu bekommen.

[Lars Gebauer]

Am 17.08.2022 um 14:56 schrieb Arno Welzel:
> Lars Gebauer, 2022-08-16 15:21:
>> Am 16.08.2022 um 13:40 schrieb Arno Welzel:
>>> Lars Gebauer, 2022-08-12 18:23:
>>>> Es ging um Programme vs. Daten. Und meine Auffassung läuft darauf
>>>> hinaus, daß Daten Programme parametrisieren, selbst aber keine Programme
>>>> sind.
>>>
>>> Ein Python-Script ist aber ein Programm und keine "Daten". Und nein,
>>> auch wenn ein Programm in Form eines Textes mit geschrieben Befehlen
>>> vorliegt, ist es immer noch ein Programm.
>>
>> Jetzt hast Du aber tüchtig mit dem Fuß aufgestampft. Ich bin beeindruckt!
>>
>> Aber gut: Dann produziert meine Kamera eben lauter Programme. Kann ich
>> mit leben, ist mir nicht so wichtig.
>
> Jetzt hast Du deine Ignoranz endgültig demonstriert. Dann eben nicht.

Wenn ich Dir Recht gebe, nölst Du. Hast Du Probleme mit Dir selbst?

>>>> Die jpgs aus meiner Kamera parametrisieren den Bildbetrachter, der dann
>>>> ein Bild am Monitor anzeigt. Hierzu interpretiert der Bildbetrachter die
>>>> von der Kamera gelieferten Daten.
>>>
>>> Nein, Bilddaten sind auch keine "Parameter", sondern einfach nur Daten.
>>
>> Ja, Daten die ein Programm parametrisieren. So, wie ein Python-Skript.
>
> Nein, ein Python-Skript "parametrisiert" exakt gar nichts.

Schon gar nicht den Python-Interpreter. Ist ja schon gut.

[Peter J. Holzer]

Aber dieses Programm muss schon da sein, es kann nicht durch den
Schadcode erst angelegt/überschrieben werden.

hp

[Arno Welzel]

Lars Gebauer, 2022-08-17 16:55:

> Am 17.08.2022 um 14:56 schrieb Arno Welzel:
>> Lars Gebauer, 2022-08-16 15:21:
>>> Am 16.08.2022 um 13:40 schrieb Arno Welzel:
>>>> Lars Gebauer, 2022-08-12 18:23:
>>>>> Es ging um Programme vs. Daten. Und meine Auffassung läuft darauf
>>>>> hinaus, daß Daten Programme parametrisieren, selbst aber keine Programme
>>>>> sind.
>>>>
>>>> Ein Python-Script ist aber ein Programm und keine "Daten". Und nein,
>>>> auch wenn ein Programm in Form eines Textes mit geschrieben Befehlen
>>>> vorliegt, ist es immer noch ein Programm.
>>>
>>> Jetzt hast Du aber tüchtig mit dem Fuß aufgestampft. Ich bin beeindruckt!
>>>
>>> Aber gut: Dann produziert meine Kamera eben lauter Programme. Kann ich
>>> mit leben, ist mir nicht so wichtig.
>>
>> Jetzt hast Du deine Ignoranz endgültig demonstriert. Dann eben nicht.
>
> Wenn ich Dir Recht gebe, nölst Du. Hast Du Probleme mit Dir selbst?

Nein, Du hast mir nicht Recht gegeben. Ich habe nicht behauptet, dass
Bilddaten Programme wären.

>> Nein, ein Python-Skript "parametrisiert" exakt gar nichts.
>
> Schon gar nicht den Python-Interpreter. Ist ja schon gut.

Korrekt. Ein Interpreter wird durch Programmcode nicht parametrisiert,
sondern interpretritiert den Code. Deswegen nennt man das Ding auch
"Interpreter" und nicht "parametrisierbare Anwendung".

[Arno Welzel]

Peter J. Holzer, 2022-08-18 17:38:

Was am Ergebnis nichts ändert - an dem, was in einem Computer vorgeht,
sind *immer* Programme beteiligt.

[Lars Gebauer]

Am 20.08.2022 um 02:58 schrieb Arno Welzel:
> Lars Gebauer, 2022-08-17 16:55:
>> Am 17.08.2022 um 14:56 schrieb Arno Welzel:
>>> Lars Gebauer, 2022-08-16 15:21:

>>>> Aber gut: Dann produziert meine Kamera eben lauter Programme. Kann ich
>>>> mit leben, ist mir nicht so wichtig.
>>>
>>> Jetzt hast Du deine Ignoranz endgültig demonstriert. Dann eben nicht.
>>
>> Wenn ich Dir Recht gebe, nölst Du. Hast Du Probleme mit Dir selbst?
>
> Nein, Du hast mir nicht Recht gegeben. Ich habe nicht behauptet, dass
> Bilddaten Programme wären.

Das ist aber die Konsequenz, wenn man Deiner Argumentation folgt.

Produziert Deine Argumentation Ergebnisse, die Dir nicht gefallen? Dann
solltest Du sie vielleicht überdenken.

>>> Nein, ein Python-Skript "parametrisiert" exakt gar nichts.
>>
>> Schon gar nicht den Python-Interpreter. Ist ja schon gut.
>
> Korrekt. Ein Interpreter wird durch Programmcode nicht parametrisiert,

Richtig. Da werden keinerlei Parameter wie Konstanten oder Variablen
übergeben.

> sondern interpretritiert den Code.

So, wie ein Bildinterpreter.

[Peter J. Holzer]

Das hat auch niemand bestritten. Die Frage war, ob die Installation
eines Programms unter einer anderen User-Id als der, mit der der User
normalerweise arbeitet, die Sicherheit des Gesamtsystems wesentlich
erhöht.

hp

[Takvorian]

Peter J. Holzer schrieb:

> Die Frage war, ob die Installation
> eines Programms unter einer anderen User-Id als der, mit der der User
> normalerweise arbeitet, die Sicherheit des Gesamtsystems wesentlich
> erhöht.

Alberne Frage, denn selbstverständlich erhöht Rechtetrennung die Sicherheit
des Systems und auch der Anwenderdaten erheblich.

[Peter J. Holzer]

On 2022-08-20 06:23, Lars Gebauer <lgeb...@live.de> wrote:
> Am 20.08.2022 um 02:58 schrieb Arno Welzel:
>> Lars Gebauer, 2022-08-17 16:55:
>>> Am 17.08.2022 um 14:56 schrieb Arno Welzel:
>>>> Lars Gebauer, 2022-08-16 15:21:
>>>>> Aber gut: Dann produziert meine Kamera eben lauter Programme. Kann ich
>>>>> mit leben, ist mir nicht so wichtig.
>>>>
>>>> Jetzt hast Du deine Ignoranz endgültig demonstriert. Dann eben nicht.
>>>
>>> Wenn ich Dir Recht gebe, nölst Du. Hast Du Probleme mit Dir selbst?
>>
>> Nein, Du hast mir nicht Recht gegeben. Ich habe nicht behauptet, dass
>> Bilddaten Programme wären.
>
> Das ist aber die Konsequenz, wenn man Deiner Argumentation folgt.

Nein. Nur wenn man deiner Dichotomie folgt:

Entweder:
1) Programme und Daten sind fundamental unterschiedlich. Etwas ist
entweder Daten oder Programm
oder:
2) Daten und Programme sind das gleiche. Alle Daten sind Programme und
umgekehrt,

Aber warum sollte man das tun? Das wäre, wie wenn man argumentieren
würde, dass Forellen keine Fische sein können, weil sonst alle Fische
Forellen wären.

Programme sind Daten[1], aber nicht die einzigen Daten.

>> sondern interpretritiert den Code.
>
> So, wie ein Bildinterpreter.
>

Es gibt Programme, die verarbeiten Bilder und es gibt welche, die
verarbeiten Töne. Heißt das, dass Bilder Töne sind? Nein. Bilder sind
eine andere Art von Daten als Töne. Programme sind wieder eine andere
und es gibt noch hunderte weitere.

(Es gibt natürlich auch Überschneidungen: PostScript z.B. ist eine
Programmiersprache. Aber sehr wenige Leute verwenden sie, um beliebige
Anwendungen zu schreiben, die allermeisten PostScript-Programme
produzieren fixen, graphischen Output)

hp

[1] Ich verwende "Daten" hier sehr weit. Ein Programm ist auch ein
Programm, wenn es auf Papier gedruckt oder mit Kreide auf eine Tafel
geschrieben ist.

[Peter J. Holzer]

Als selbstverständlich sollte man in IT-Security gar nichts ansehen. Man
muss sich immer überlegen, wie die Angriffsszenarien aussehen und welche
Maßnahmen für diese Szenarien effektiv sind. (Wird leider in der Praxis
oft nicht gemacht - Cargo-Culting ist weit verbreitet und oft werden
noch Maßnahmen neu eingeführt, die in der Literatur schon seit 10-15
Jahren als kontraproduktiv gelten.)

Auf einem Multiuser-System ist ein Angriffsszenario, dass ein User Daten
eines anderen unberechtigt lesen oder ändern möchte. Das lässt sich mit
einem Berechtigungssystem auf (User, File)-Basis effektiv verhindern.

Auf einem Single-User-System aber existiert dieses Szenario nicht.
Dafür gibt es ein paar andere:
* Eine Applikation gibt unberechtigt Daten nach außen
* Daten aus externer Quelle führen dazu, dass Programme unerwünschtes
Verhalten zeigen
* Beobachtung des Systems offenbart kritische Informationen

Etc.

Es ist jedenfalls nicht offensichtlich, dass die Trennung in
"System+Programme" und "Daten" und die Vergabe von Rechten für zwei
User-Ids ("Admin" und "User") in diesen Szenarien effektiv schützt.

Das müsstest Du also belegen. Idealerweise an Hand realer Beispiele.

hp

[Takvorian]

Peter J. Holzer schrieb:

> On 2022-08-20 07:06, Takvorian <tak...@gmx.de> wrote:
>> Peter J. Holzer schrieb:
>>> Die Frage war, ob die Installation eines Programms unter einer
>>> anderen User-Id als der, mit der der User normalerweise arbeitet, die
>>> Sicherheit des Gesamtsystems wesentlich erhöht.
>>
>> Alberne Frage, denn selbstverständlich erhöht Rechtetrennung die
>> Sicherheit des Systems und auch der Anwenderdaten erheblich.
>
> Als selbstverständlich sollte man in IT-Security gar nichts ansehen. Man
> muss sich immer überlegen, wie die Angriffsszenarien aussehen und welche
> Maßnahmen für diese Szenarien effektiv sind.

Hat man ja getan, das Ergebnis ist in modernen OSen deutlich sichtbar.

> (Wird leider in der Praxis
> oft nicht gemacht - Cargo-Culting ist weit verbreitet und oft werden
> noch Maßnahmen neu eingeführt, die in der Literatur schon seit 10-15
> Jahren als kontraproduktiv gelten.)

Rechtetrennung gehört nicht dazu.

> Auf einem Multiuser-System ist ein Angriffsszenario, dass ein User Daten
> eines anderen unberechtigt lesen oder ändern möchte. Das lässt sich mit
> einem Berechtigungssystem auf (User, File)-Basis effektiv verhindern.
>
> Auf einem Single-User-System aber existiert dieses Szenario nicht.
> Dafür gibt es ein paar andere:
> * Eine Applikation gibt unberechtigt Daten nach außen
> * Daten aus externer Quelle führen dazu, dass Programme unerwünschtes
> Verhalten zeigen
> * Beobachtung des Systems offenbart kritische Informationen
> Etc.

Insbesondere die Daten aus externer Quelle, die man als Malware bezeichnet,
können durch Rechtetrennung recht effektiv abgewehrt werden.

> Es ist jedenfalls nicht offensichtlich, dass die Trennung in
> "System+Programme" und "Daten" und die Vergabe von Rechten für zwei
> User-Ids ("Admin" und "User") in diesen Szenarien effektiv schützt.
> Das müsstest Du also belegen. Idealerweise an Hand realer Beispiele.

Nun, das beweist sich doch täglich im praktischen Einsatz. Ein System, so
konfiguriert wie hier z.B. vorgeschlagen
https://skanthak.homepage.t-online.de/SAFER.html
ist erheblich sicherer als ohne diese Konfiguration.
Und via Whitelisting kann man zusätzlich noch sämtlichen Programmen den
Zugriff auf wichtige Daten verweigern, außer den erlaubten. Dazu muss ich
doch nichts belegen.

[Lars Gebauer]

Am 20.08.2022 um 09:25 schrieb Peter J. Holzer:
> On 2022-08-20 06:23, Lars Gebauer <lgeb...@live.de> wrote:
>> Am 20.08.2022 um 02:58 schrieb Arno Welzel:
>>> Nein, Du hast mir nicht Recht gegeben. Ich habe nicht behauptet, dass
>>> Bilddaten Programme wären.
>>
>> Das ist aber die Konsequenz, wenn man Deiner Argumentation folgt.
>
> Nein. Nur wenn man deiner Dichotomie folgt:
>
> Entweder:
> 1) Programme und Daten sind fundamental unterschiedlich. Etwas ist
> entweder Daten oder Programm
> oder:
> 2) Daten und Programme sind das gleiche. Alle Daten sind Programme und
> umgekehrt,
>
> Aber warum sollte man das tun?

Genau das. Ich frage mich schon die ganze Zeit, warum Ihr das tut.

Ausgangspunkt war Deine Behauptung, daß ein Excel-File ein Programm sei,
genauso wie ein Python-Skript. Und daß das wohl "niemand bezweifeln" würde.

Mal ganz davon abgesehen, daß derartige Aussagen ("wird niemand
bezweifeln") häufig nur den Auftakt zu gröberem Unfug darstellen, kann
es ja durchaus sein, daß Du Recht hast.

Dann aber drängt sich (mir zumindest) die Frage auf, worin sich
eigentlich das Excel-File oder das Python-Skipt von einer Text-, Bild-
oder sonstigen Datei unterscheiden. Schließlich enthalten alle diese
Files lediglich Daten, die durch einen Interpreter weiter verarbeitet
werden, mithin also den Interpreter parametrisieren. Da ist dann einfach
kein erkennbarer Unterschied.

Diese Frage konnten bisher weder Du noch Arno schlüssig beantworten.
Außer "isso, fußaufstampf" kam da bisher nichts. Mag ja sein, daß diese
Erklärung für Dich und Arno völlig ausreichend ist - bei mir ezeugt sie
eher Belustigung.

> Das wäre, wie wenn man argumentieren
> würde, dass Forellen keine Fische sein können, weil sonst alle Fische
> Forellen wären.

Zwischen einer Forelle und einem Karpfen gibt es erkenn- und benennbare
Unterschiede.

Bei Programmen und Daten gibt es (für mich) diese Unterschiede
ebenfalls: Programme interpretieren und verarbeiten Daten. Aber nicht
umgekehrt.

Folglich interpretieren und verarbeiten Bildinterpreter Bild-Files.
Folglich interpretieren und verarbeiten Textinterpreter Text-Files.
Folglich interpretieren und verarbeiten Excelinterpreter Excel-Files.

...

Folglich interpretieren und verarbeiten Pythoninterpreter Python-Files.

Folglich bestehen zwischen Python-, Excel-, Text- und Bild-Files
insofern keine Unterschiede. Daß manche dieser Daten-Files komplexer
aufgebaut sind als andere, kann ja sein. Aber das ist nur ein
quantitativer und kein qualitativer Unterschied.

> Es gibt Programme, die verarbeiten Bilder und es gibt welche, die
> verarbeiten Töne.

Und es gibt Programme, die verarbeiten Python-Skripte.

> Heißt das, dass Bilder Töne sind?

Macht das daß Skript zu einem Programm?

[Peter J. Holzer]

On 2022-08-20 09:02, Takvorian <tak...@gmx.de> wrote:
> Peter J. Holzer schrieb:
>> On 2022-08-20 07:06, Takvorian <tak...@gmx.de> wrote:
>>> Peter J. Holzer schrieb:
>>>> Die Frage war, ob die Installation eines Programms unter einer
>>>> anderen User-Id als der, mit der der User normalerweise arbeitet, die
>>>> Sicherheit des Gesamtsystems wesentlich erhöht.
>>>
>>> Alberne Frage, denn selbstverständlich erhöht Rechtetrennung die
>>> Sicherheit des Systems und auch der Anwenderdaten erheblich.
>>
>> Als selbstverständlich sollte man in IT-Security gar nichts ansehen. Man
>> muss sich immer überlegen, wie die Angriffsszenarien aussehen und welche
>> Maßnahmen für diese Szenarien effektiv sind.
>
> Hat man ja getan, das Ergebnis ist in modernen OSen deutlich sichtbar.
>
>> (Wird leider in der Praxis
>> oft nicht gemacht - Cargo-Culting ist weit verbreitet und oft werden
>> noch Maßnahmen neu eingeführt, die in der Literatur schon seit 10-15
>> Jahren als kontraproduktiv gelten.)
>
> Rechtetrennung gehört nicht dazu.

Richtig, weil Multi-User-Systeme verbreitet sind, und die Rechtetrennung
dort (für einige, aber nicht alle Szenarien) effektiv ist.

Aber es gibt halt auch Single-User-Systeme. Vom durchschnittlichen
privaten Laptop bis zu Smartphones.

Und da ist die Trennung in zwei Bereiche IMHO zumindest zweifelhaft.

Und bei Smartphones z.B. sieht die Berechtigungsstruktur daher auch
deutlich anders aus: Da wird nicht zwischen "Admin" und "User"
unterschieden, sondern jede App bekommt ihre eigenen Berechtigungen.

>> Auf einem Multiuser-System ist ein Angriffsszenario, dass ein User Daten
>> eines anderen unberechtigt lesen oder ändern möchte. Das lässt sich mit
>> einem Berechtigungssystem auf (User, File)-Basis effektiv verhindern.
>>
>> Auf einem Single-User-System aber existiert dieses Szenario nicht.
>> Dafür gibt es ein paar andere:
>> * Eine Applikation gibt unberechtigt Daten nach außen
>> * Daten aus externer Quelle führen dazu, dass Programme unerwünschtes
>> Verhalten zeigen
>> * Beobachtung des Systems offenbart kritische Informationen
>> Etc.
>
> Insbesondere die Daten aus externer Quelle, die man als Malware bezeichnet,
> können durch Rechtetrennung recht effektiv abgewehrt werden.

[citation needed]

Eben das bezweifle ich. Ich bin in der Windows-Welt nicht so zuhause,
aber was ich über diverse im Umlauf befindliche Malware lese, scheint
mir das eben nicht sonderlich effektiv zu sein (d.h. die Malware
verbreitet sich trotzdem).

Aber Du kannst gerne der Behauptung Daten folgen lassen: Such Dir eine
Handvoll aktueller Malware heraus, erkläre den Einfallsvektor und wie
die Zweiteilung der Berechtigungen diesen effektiv unterbindet (und ja,
mir ist klar, dass ich Dir mit "such dir ..." einen riesigen
Heimvorteil verschafft habe).

>> Es ist jedenfalls nicht offensichtlich, dass die Trennung in
>> "System+Programme" und "Daten" und die Vergabe von Rechten für zwei
>> User-Ids ("Admin" und "User") in diesen Szenarien effektiv schützt.
>> Das müsstest Du also belegen. Idealerweise an Hand realer Beispiele.
>
> Nun, das beweist sich doch täglich im praktischen Einsatz. Ein System, so
> konfiguriert wie hier z.B. vorgeschlagen
> https://skanthak.homepage.t-online.de/SAFER.html
> ist erheblich sicherer als ohne diese Konfiguration.

Auch das ist erstmal nur eine Behauptung, die zu belegen wäre. Abgesehen
davon geht das aber deutlich über den Ausgangspunkt der Diskussion
hinaus.

> Und via Whitelisting kann man zusätzlich noch sämtlichen Programmen den
> Zugriff auf wichtige Daten verweigern, außer den erlaubten. Dazu muss ich
> doch nichts belegen.

Wenn ich mich recht erinnere, hatte ich das schon in die Diskussion
eingebracht, ja.

hp

[Peter J. Holzer]

On 2022-08-20 09:06, Lars Gebauer <lgeb...@live.de> wrote:
> Am 20.08.2022 um 09:25 schrieb Peter J. Holzer:
>> On 2022-08-20 06:23, Lars Gebauer <lgeb...@live.de> wrote:
>>> Am 20.08.2022 um 02:58 schrieb Arno Welzel:
>>>> Nein, Du hast mir nicht Recht gegeben. Ich habe nicht behauptet, dass
>>>> Bilddaten Programme wären.
>>>
>>> Das ist aber die Konsequenz, wenn man Deiner Argumentation folgt.
>>
>> Nein. Nur wenn man deiner Dichotomie folgt:
>>
>> Entweder:
>> 1) Programme und Daten sind fundamental unterschiedlich. Etwas ist
>> entweder Daten oder Programm
>> oder:
>> 2) Daten und Programme sind das gleiche. Alle Daten sind Programme und
>> umgekehrt,
>>
>> Aber warum sollte man das tun?
>
> Genau das. Ich frage mich schon die ganze Zeit, warum Ihr das tut.

Wir tun es eh nicht. Du erwartest offenbar von uns, dass wir es tun
sollen und bist irritiert, dass wir nicht zum dem Schluss gelangen, zu
dem das führen würde.

> Ausgangspunkt war Deine Behauptung, daß ein Excel-File ein Programm sei,
> genauso wie ein Python-Skript. Und daß das wohl "niemand bezweifeln" würde.
>
> Mal ganz davon abgesehen, daß derartige Aussagen ("wird niemand
> bezweifeln") häufig nur den Auftakt zu gröberem Unfug darstellen, kann
> es ja durchaus sein, daß Du Recht hast.
>
> Dann aber drängt sich (mir zumindest) die Frage auf, worin sich
> eigentlich das Excel-File oder das Python-Skipt von einer Text-, Bild-
> oder sonstigen Datei unterscheiden.

Im Zweck. Eine Bild-Datei repräsentiert ein Bild. Eine Sound-Datei eine
Folge von Geräuschen. Eine Programm-Datei ein Programm.

Auf der untersten Ebene sind alle nur Folgen von Bytes und haben absolut
keine intrinsische Bedeutung. Die bekommen sie erst dadurch, dass sie
verarbeitet werden.

> Schließlich enthalten alle diese Files lediglich Daten, die durch
> einen Interpreter weiter verarbeitet werden, mithin also den
> Interpreter parametrisieren. Da ist dann einfach kein erkennbarer
> Unterschied.

Selbes gilt für Exe-Files. Die "parametrisieren" (ich glaube, Du
verwendest das Wort auch etwas anders als üblich) nur den in der CPU
eingebauten Interpreter (typischerweise als Mischung von Microcode (ein
Programm!) und festverdrahteter Hardware implementiert).

> Diese Frage konnten bisher weder Du noch Arno schlüssig beantworten.
> Außer "isso, fußaufstampf" kam da bisher nichts. Mag ja sein, daß diese
> Erklärung für Dich und Arno völlig ausreichend ist - bei mir ezeugt sie
> eher Belustigung.

Immerhin habe ich eine Definiton gepostet, was ein Programm ist. Von Dir
habe ich sowas bisher noch nicht gelesen (vielleicht habe ich es
übersehen), nur die wiederholte Behauptungen, was alles kein Programm
sei, und die Abqualifizierung der üblichen Bedeutung von "Programm" als
"umgangssprachlich".

>> Das wäre, wie wenn man argumentieren würde, dass Forellen keine
>> Fische sein können, weil sonst alle Fische Forellen wären.
>
> Zwischen einer Forelle und einem Karpfen gibt es erkenn- und benennbare
> Unterschiede.

Ja, aber beides sind Fische. Du kannst nicht behaupten, wenn eine
Forelle ein Fisch ist, dann ist ein Karpfen auch eine Forelle. Das ist
einfach ein fundamentaler Logik-Fehler. Bei Deiner
Programm/Daten-Argumentation machst Du aber genau diesen Fehler (ein
bisschen versteckt dadurch, dass Du weder "Programm" noch "Daten" jemals
definiert hast und man somit (anders als bei "Forelle" und "Karpfen")
nicht sicher sein kann, wovon Du eigentlich redest (eigentlich kann ich
das bei Forelle und Karpfen auch nicht wissen - ich traue Dir durchaus
zu, dass Du da auch Privatdefinitionen hast)).

hp

[Lars Gebauer]

Am 20.08.2022 um 12:36 schrieb Peter J. Holzer:
> On 2022-08-20 09:06, Lars Gebauer <lgeb...@live.de> wrote:
>> Am 20.08.2022 um 09:25 schrieb Peter J. Holzer:
>>> Nein. Nur wenn man deiner Dichotomie folgt:
>>>
>>> Entweder:
>>> 1) Programme und Daten sind fundamental unterschiedlich. Etwas ist
>>> entweder Daten oder Programm
>>> oder:
>>> 2) Daten und Programme sind das gleiche. Alle Daten sind Programme und
>>> umgekehrt,
>>>
>>> Aber warum sollte man das tun?
>>
>> Genau das. Ich frage mich schon die ganze Zeit, warum Ihr das tut.
>
> Wir tun es eh nicht.

Ich allerdings auch nicht. Deswegen gibt es ja "meine Dichotomie" gar nicht.

> Du erwartest offenbar von uns, dass wir es tun
> sollen und bist irritiert, dass wir nicht zum dem Schluss gelangen, zu
> dem das führen würde.

Nönö. Ich erwarte gar nichts.

>> Ausgangspunkt war Deine Behauptung, daß ein Excel-File ein Programm sei,
>> genauso wie ein Python-Skript. Und daß das wohl "niemand bezweifeln" würde.
>>
>> Mal ganz davon abgesehen, daß derartige Aussagen ("wird niemand
>> bezweifeln") häufig nur den Auftakt zu gröberem Unfug darstellen, kann
>> es ja durchaus sein, daß Du Recht hast.
>>
>> Dann aber drängt sich (mir zumindest) die Frage auf, worin sich
>> eigentlich das Excel-File oder das Python-Skipt von einer Text-, Bild-
>> oder sonstigen Datei unterscheiden.
>
> Im Zweck.

Ach geh', das wird jetzt aber völlig humorisch. Dinge (auch
immaterielle) /haben/ keinen Zweck. Ein Zweck wird ihnen immer nur von
An-/Verwender gegeben.

> Eine Bild-Datei repräsentiert ein Bild. Eine Sound-Datei eine
> Folge von Geräuschen. Eine Programm-Datei ein Programm.

:)

Dabei sollte man immer bedenken, daß die Zweckvergabe meist nur wenigen
Einschränkungen unterliegt und allgemein arg willkürlich ist.

Mithin ist dann ein Programm ein Programm wenn Du sagst, daß es ein
Programm sei. Soweit waren wir aber schon.

>> Schließlich enthalten alle diese Files lediglich Daten, die durch
>> einen Interpreter weiter verarbeitet werden, mithin also den
>> Interpreter parametrisieren. Da ist dann einfach kein erkennbarer
>> Unterschied.
>
> Selbes gilt für Exe-Files.

Natürlich: Programme können auch Programme verarbeiten. Aber Daten
können keine Programme verarbeiten.

>> Diese Frage konnten bisher weder Du noch Arno schlüssig beantworten.
>> Außer "isso, fußaufstampf" kam da bisher nichts. Mag ja sein, daß diese
>> Erklärung für Dich und Arno völlig ausreichend ist - bei mir ezeugt sie
>> eher Belustigung.
>
> Immerhin habe ich eine Definiton gepostet, was ein Programm ist.

Naja. :)

> Von Dir
> habe ich sowas bisher noch nicht gelesen (vielleicht habe ich es
> übersehen), nur die wiederholte Behauptungen, was alles kein Programm
> sei,

Dann hast Du die Herleitung meiner Behauptung übersehen.

Auch in dem Posting, auf das Du hier gerade beantwortet hast, habe ich
versucht, das darzustellen.

Aber Du wolltest Dich damit nicht weiter auseinander setzen.

> und die Abqualifizierung der üblichen Bedeutung von "Programm" als
> "umgangssprachlich".

Das hat überhaupt nichts mit Abqualifizierung zu tun sondern ist eine
einfache Erfahrungssache. Häufig werden Dinge als etwas bezeichnet, was
sie eigentlich gar nicht sind. Das ist gar nicht weiter schlimm sondern
dient der Vereinfachung.

>>> Das wäre, wie wenn man argumentieren würde, dass Forellen keine
>>> Fische sein können, weil sonst alle Fische Forellen wären.
>>
>> Zwischen einer Forelle und einem Karpfen gibt es erkenn- und benennbare
>> Unterschiede.
>
> Ja, aber beides sind Fische. Du kannst nicht behaupten, wenn eine
> Forelle ein Fisch ist, dann ist ein Karpfen auch eine Forelle.

Tue ich ja auch gar nicht.

> Das ist
> einfach ein fundamentaler Logik-Fehler. Bei Deiner
> Programm/Daten-Argumentation machst Du aber genau diesen Fehler (ein
> bisschen versteckt dadurch, dass Du weder "Programm" noch "Daten" jemals
> definiert hast

Doch, tat ich. In dem Teil des Postings, auf den Du nicht näher eingehen
wolltest.

> und man somit (anders als bei "Forelle" und "Karpfen")
> nicht sicher sein kann, wovon Du eigentlich redest

Du wüßtest es, wenn Du den gelöschten Teil auch gelesen hättest.
Abgesehen davon, daß ich das auch hier nicht zum ersten Mal tat.

[Takvorian]

Peter J. Holzer schrieb:

> Immerhin habe ich eine Definiton gepostet, was ein Programm ist.

Die hier genügt nicht?
https://en.wikipedia.org/wiki/Computer_program

[Takvorian]

Peter J. Holzer schrieb:

> On 2022-08-20 09:02, Takvorian <tak...@gmx.de> wrote:
>> Peter J. Holzer schrieb:
>>> On 2022-08-20 07:06, Takvorian <tak...@gmx.de> wrote:
>>>> Peter J. Holzer schrieb:
>>>>> Die Frage war, ob die Installation eines Programms unter einer
>>>>> anderen User-Id als der, mit der der User normalerweise arbeitet, die
>>>>> Sicherheit des Gesamtsystems wesentlich erhöht.
>>>>
>>>> Alberne Frage, denn selbstverständlich erhöht Rechtetrennung die
>>>> Sicherheit des Systems und auch der Anwenderdaten erheblich.
>>>
>>> Als selbstverständlich sollte man in IT-Security gar nichts ansehen. Man
>>> muss sich immer überlegen, wie die Angriffsszenarien aussehen und welche
>>> Maßnahmen für diese Szenarien effektiv sind.
>>
>> Hat man ja getan, das Ergebnis ist in modernen OSen deutlich sichtbar.
>>
>>> (Wird leider in der Praxis
>>> oft nicht gemacht - Cargo-Culting ist weit verbreitet und oft werden
>>> noch Maßnahmen neu eingeführt, die in der Literatur schon seit 10-15
>>> Jahren als kontraproduktiv gelten.)
>>
>> Rechtetrennung gehört nicht dazu.
>
> Richtig, weil Multi-User-Systeme verbreitet sind, und die Rechtetrennung
> dort (für einige, aber nicht alle Szenarien) effektiv ist.
>
> Aber es gibt halt auch Single-User-Systeme. Vom durchschnittlichen
> privaten Laptop bis zu Smartphones.
> Und da ist die Trennung in zwei Bereiche IMHO zumindest zweifelhaft.

Gerade auch für diese ist
https://skanthak.homepage.t-online.de/SAFER.html
extrem wichtig, da hier meist DAUs und ONUs am Werke sind. Man kann Systeme
auf die Weise recht effektiv versiegeln.

> Und bei Smartphones z.B. sieht die Berechtigungsstruktur daher auch
> deutlich anders aus: Da wird nicht zwischen "Admin" und "User"
> unterschieden, sondern jede App bekommt ihre eigenen Berechtigungen.

Der Smartphone-Bereich ist eh ein Grauen für sich.

>>> Auf einem Multiuser-System ist ein Angriffsszenario, dass ein User Daten
>>> eines anderen unberechtigt lesen oder ändern möchte. Das lässt sich mit
>>> einem Berechtigungssystem auf (User, File)-Basis effektiv verhindern.
>>>
>>> Auf einem Single-User-System aber existiert dieses Szenario nicht.
>>> Dafür gibt es ein paar andere:
>>> * Eine Applikation gibt unberechtigt Daten nach außen
>>> * Daten aus externer Quelle führen dazu, dass Programme unerwünschtes
>>> Verhalten zeigen
>>> * Beobachtung des Systems offenbart kritische Informationen
>>> Etc.
>>
>> Insbesondere die Daten aus externer Quelle, die man als Malware bezeichnet,
>> können durch Rechtetrennung recht effektiv abgewehrt werden.
>
> [citation needed]
>
> Eben das bezweifle ich. Ich bin in der Windows-Welt nicht so zuhause,
> aber was ich über diverse im Umlauf befindliche Malware lese, scheint
> mir das eben nicht sonderlich effektiv zu sein (d.h. die Malware
> verbreitet sich trotzdem).

Wenn alle Systeme von Microsoft OOBE so eingestellt wären wie im obigen Link
beschrieben, würde sich das sehr deutlich ändern. Leider macht Microsoft das
Gegenteil: es unterstützt sogar noch lausigen Schrott, der sich nicht an die
Windows-Regeln hält, durch Wirrtualisierung. Und Schlangenöl ist kein
Schutz, sondern macht Systeme eher unsicherer als sie vorher waren.

> Aber Du kannst gerne der Behauptung Daten folgen lassen: Such Dir eine
> Handvoll aktueller Malware heraus, erkläre den Einfallsvektor und wie
> die Zweiteilung der Berechtigungen diesen effektiv unterbindet (und ja,
> mir ist klar, dass ich Dir mit "such dir ..." einen riesigen
> Heimvorteil verschafft habe).

Das ergibt sich ja schon aus dem Lesen der Seite und der INFs, deren Inhalt
genau beschreibt, was Malware dann nicht mehr kann. Und auch gegen
E-Mail-Malware:
https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2003/cc740025(v=ws.10)?redirectedfrom=MSDN

>>> Es ist jedenfalls nicht offensichtlich, dass die Trennung in
>>> "System+Programme" und "Daten" und die Vergabe von Rechten für zwei
>>> User-Ids ("Admin" und "User") in diesen Szenarien effektiv schützt.
>>> Das müsstest Du also belegen. Idealerweise an Hand realer Beispiele.
>>
>> Nun, das beweist sich doch täglich im praktischen Einsatz. Ein System, so
>> konfiguriert wie hier z.B. vorgeschlagen
>> https://skanthak.homepage.t-online.de/SAFER.html
>> ist erheblich sicherer als ohne diese Konfiguration.
>
> Auch das ist erstmal nur eine Behauptung, die zu belegen wäre. Abgesehen
> davon geht das aber deutlich über den Ausgangspunkt der Diskussion
> hinaus.

Effektive Rechtetrennung ist halt wesentlich mehr als nur die Existenz eines
Admin- und eines User-Kontos, die nur die Grundvoraussetzung, das Fundament
darstellen. Sieht man recht schön, wenn man sich den Inhalt der INFs
anschaut.

[Arno Welzel]

Lars Gebauer, 2022-08-20 08:23:

> Am 20.08.2022 um 02:58 schrieb Arno Welzel:
>> Lars Gebauer, 2022-08-17 16:55:
>>> Am 17.08.2022 um 14:56 schrieb Arno Welzel:
>>>> Lars Gebauer, 2022-08-16 15:21:
>>>>> Aber gut: Dann produziert meine Kamera eben lauter Programme. Kann ich
>>>>> mit leben, ist mir nicht so wichtig.
>>>>
>>>> Jetzt hast Du deine Ignoranz endgültig demonstriert. Dann eben nicht.
>>>
>>> Wenn ich Dir Recht gebe, nölst Du. Hast Du Probleme mit Dir selbst?
>>
>> Nein, Du hast mir nicht Recht gegeben. Ich habe nicht behauptet, dass
>> Bilddaten Programme wären.
>
> Das ist aber die Konsequenz, wenn man Deiner Argumentation folgt.

Nein, ist es nicht.

Meine Argumentation war, dass Programme nicht ausschliesslich in binärer
Form vorliegen müssen, sondern auch aus Befehlen in Textform bestehen
können, und zur Ausführung noch einenn Interpreter oder Compiler
benötigen. Das ändert aber nichts daran, dass es Programme sind und
keine Kochrezepte oder Bilder, wie z.B. SVG, was auch in Textform vorliegt.

> Produziert Deine Argumentation Ergebnisse, die Dir nicht gefallen? Dann
> solltest Du sie vielleicht überdenken.

Produziert deine Ignoranz Ergebnisse, die Dir nicht gefallen? Dann

solltest Du sie vielleicht überdenken.

>>>> Nein, ein Python-Skript "parametrisiert" exakt gar nichts.
>>>
>>> Schon gar nicht den Python-Interpreter. Ist ja schon gut.
>>
>> Korrekt. Ein Interpreter wird durch Programmcode nicht parametrisiert,
>
> Richtig. Da werden keinerlei Parameter wie Konstanten oder Variablen
> übergeben.

Auch Konstanten oder Variablen sind keine "Parametrisierung".

>> sondern interpretritiert den Code.
>
> So, wie ein Bildinterpreter.

Das Programm, was eine JPEG-Datei liest und diese dann auf dem
Bildschirm angezeigt oder ausdruckt, ist aber kein "Interpreter".

Bevor hier noch weiteren Unsinn verbreitest, soltest Du wenigstens
Begrifflichkeiten korrekt verwenden.

[Arno Welzel]

Lars Gebauer, 2022-08-20 11:06:

> Am 20.08.2022 um 09:25 schrieb Peter J. Holzer:
>> On 2022-08-20 06:23, Lars Gebauer <lgeb...@live.de> wrote:
>>> Am 20.08.2022 um 02:58 schrieb Arno Welzel:
>>>> Nein, Du hast mir nicht Recht gegeben. Ich habe nicht behauptet, dass
>>>> Bilddaten Programme wären.
>>>
>>> Das ist aber die Konsequenz, wenn man Deiner Argumentation folgt.
>>
>> Nein. Nur wenn man deiner Dichotomie folgt:
>>
>> Entweder:
>> 1) Programme und Daten sind fundamental unterschiedlich. Etwas ist
>> entweder Daten oder Programm
>> oder:
>> 2) Daten und Programme sind das gleiche. Alle Daten sind Programme und
>> umgekehrt,
>>
>> Aber warum sollte man das tun?
>
> Genau das. Ich frage mich schon die ganze Zeit, warum Ihr das tut.

Das tue ich nicht!

Programme und Daten *SIND* fundamental unterschiedlich.

Deswegen ist ein Python-Script ein *Programm* und nicht nur "Daten".

> Ausgangspunkt war Deine Behauptung, daß ein Excel-File ein Programm sei,
> genauso wie ein Python-Skript. Und daß das wohl "niemand bezweifeln" würde.

Es kann sein, dass in einem Excel-File Makros enthalten sind, die in VBA
o.Ä. geschrieben sind - *das* sind dann zweifellos Programme.

Aber ein Excel-File ohne Makros ist zweifellos *kein* Programm!

> Dann aber drängt sich (mir zumindest) die Frage auf, worin sich
> eigentlich das Excel-File oder das Python-Skipt von einer Text-, Bild-
> oder sonstigen Datei unterscheiden. Schließlich enthalten alle diese

Sie unterscheiden sich dadurch, wofür sie *vorgesehen* sind.

Ein Python-Skipt enthält Anweisungen in einer Programmiersprache.

Ein Excel-File - wenn man Makros mal außen vorlässt - dagegen nur Zahlen
und Formeln.

> Files lediglich Daten, die durch einen Interpreter weiter verarbeitet
> werden, mithin also den Interpreter parametrisieren. Da ist dann einfach
> kein erkennbarer Unterschied.

Auf einem Computer wird *jedes* Programm interpretiert. Es ist völlig
egal, in welcher Form es vorliegt - es ist *immer* ein Interpreter
vorhanden, ggf. eben der Interpreter für x86-Befehle in der CPU, den der
Hersteller in Microcode geschrieben hat.

> Diese Frage konnten bisher weder Du noch Arno schlüssig beantworten.
> Außer "isso, fußaufstampf" kam da bisher nichts. Mag ja sein, daß diese
> Erklärung für Dich und Arno völlig ausreichend ist - bei mir ezeugt sie
> eher Belustigung.

Dann definiere bitte, was FÜR DICH ein "Programm" ist und was "Daten".

[Arno Welzel]

Peter J. Holzer, 2022-08-20 08:24:

> On 2022-08-20 01:01, Arno Welzel <use...@arnowelzel.de> wrote:

[...]

>> Was am Ergebnis nichts ändert - an dem, was in einem Computer vorgeht,
>> sind *immer* Programme beteiligt.
>
> Das hat auch niemand bestritten. Die Frage war, ob die Installation
> eines Programms unter einer anderen User-Id als der, mit der der User
> normalerweise arbeitet, die Sicherheit des Gesamtsystems wesentlich
> erhöht.

Das kommt auf das System an und wie es Rechtetrennung durchsetzt.

[Arno Welzel]

Takvorian, 2022-08-20 09:06:

Nicht zwangsläufig.

Wenn man unter Windows ein Programm startet, hat es erstmal Zugriff auf
*alle* Daten des User, der es gestartet hat. Das ändert sich auch nicht,
wenn zur Installation Administrationsrecht nötig sind. Es hängt
wesentlich vom Programm ab, ob es keine bösen Dinge tut.

Allerdings: wenn man weiß, dass ein Programm vertrauenswürdig ist und
keine ausnutzbaren Sicherslücken hat, sollte man dafür sorgen, dass auch
Malware daran nichts ändern kann. Und das wiederum ist einfacher, wenn
die Programmdateien nicht ohne administrative Rechte verändert werden
dürfen. Ebenfalls hilfreich für die Sicherheit ist es dann auch, wenn
man überhaupt gar keine Programme starten kann, die nicht explizit
vorher mit administrativen Rechten an den dafür vorgesehenen Stellen
eingerichtet wurden. Windows bietet dafür mit SAFER Möglichkeiten an,
Linux mit SELinux. Und bei Systemen wie Android geht man noch einen
Schritt weiter und erlaubt Programmen gar keinen Zugriff mehr außer auf
ihre eigenen Daten und APIs, die der Benutzer aber explizit freigeben muss.

[Lars Gebauer]

Am 21.08.2022 um 17:00 schrieb Arno Welzel:
> Programme und Daten *SIND* fundamental unterschiedlich.

Schreibe ich doch schon die ganze Zeit.

> Deswegen ist ein Python-Script ein *Programm* und nicht nur "Daten".

Nein. /Deswegen/ nun ganz bestimmt nicht.

>> Ausgangspunkt war Deine Behauptung, daß ein Excel-File ein Programm sei,
>> genauso wie ein Python-Skript. Und daß das wohl "niemand bezweifeln" würde.
>
> Es kann sein, dass in einem Excel-File Makros enthalten sind, die in VBA
> o.Ä. geschrieben sind - *das* sind dann zweifellos Programme.

Genau das bezweifele ich schon die ganze Zeit. Ganz besonders bezweifele
ich das "zweifellos". Und bisher ist es weder Dir noch Peter gelungen,
mich davon zu überzeugen.

> Aber ein Excel-File ohne Makros ist zweifellos *kein* Programm!

Na, ob der Peter Dir das glaubt?

>> Dann aber drängt sich (mir zumindest) die Frage auf, worin sich
>> eigentlich das Excel-File oder das Python-Skipt von einer Text-, Bild-
>> oder sonstigen Datei unterscheiden. Schließlich enthalten alle diese
>
> Sie unterscheiden sich dadurch, wofür sie *vorgesehen* sind.

Gewiß nicht. Eine Zweckbestimmung wird immer erst durch den
An-/Verwender gegeben und kann sehr willkürlich sein.

> Ein Python-Skipt enthält Anweisungen in einer Programmiersprache.

Richtig. Was es allerdings nicht zu einem Programm macht sondern nur den
Interpreter (= das Programm) parametrisiert.

>> Diese Frage konnten bisher weder Du noch Arno schlüssig beantworten.
>> Außer "isso, fußaufstampf" kam da bisher nichts. Mag ja sein, daß diese
>> Erklärung für Dich und Arno völlig ausreichend ist - bei mir ezeugt sie
>> eher Belustigung.
>
> Dann definiere bitte, was FÜR DICH ein "Programm" ist und was "Daten".

Bitte lies meine Postings. Insbesondere die, auf die Du antwortest.

[Lars Gebauer]

Am 21.08.2022 um 16:54 schrieb Arno Welzel:
> Meine Argumentation war, dass Programme nicht ausschliesslich in binärer
> Form vorliegen müssen, sondern auch aus Befehlen in Textform bestehen
> können, und zur Ausführung noch einenn Interpreter oder Compiler
> benötigen. Das ändert aber nichts daran, dass es Programme sind und
> keine Kochrezepte oder Bilder, wie z.B. SVG, was auch in Textform vorliegt.

Dann erkläre mal den Unterschied zwischen bspw. einem Python-Script und
einer Bilddatei. Die Bilddatei taugt nämlich ohne Interpreter auch nichts.

>> Produziert Deine Argumentation Ergebnisse, die Dir nicht gefallen? Dann
>> solltest Du sie vielleicht überdenken.
>
> Produziert deine Ignoranz Ergebnisse, die Dir nicht gefallen?

Überhaupt nicht. Ganz im Gegenteil bin ich mit den Ergebnissen
hochgradig zufrieden.

> Dann solltest Du sie vielleicht überdenken.

Dazu besteht überhaupt kein Anlaß.

>>>>> Nein, ein Python-Skript "parametrisiert" exakt gar nichts.
>>>>
>>>> Schon gar nicht den Python-Interpreter. Ist ja schon gut.
>>>
>>> Korrekt. Ein Interpreter wird durch Programmcode nicht parametrisiert,
>>
>> Richtig. Da werden keinerlei Parameter wie Konstanten oder Variablen
>> übergeben.
>
> Auch Konstanten oder Variablen sind keine "Parametrisierung".

Nun ist aber langsam gut. Was sollen Konstanten und Variablen denn sonst
sein, wenn keine Parameter, die an den Interpreter übergeben werden?

>>> sondern interpretritiert den Code.
>>
>> So, wie ein Bildinterpreter.
>
> Das Programm, was eine JPEG-Datei liest und diese dann auf dem
> Bildschirm angezeigt oder ausdruckt, ist aber kein "Interpreter".

Aber natürlich ist es einer! Was soll es denn sonst sein, wenn kein
Interpreter?

> Bevor hier noch weiteren Unsinn verbreitest, soltest Du wenigstens
> Begrifflichkeiten korrekt verwenden.

Das tue ich die ganze Zeit. Genau damit begann die Diskussion.

Allerdings beschleicht mich bei Dir zunehmend das Gefühl, daß es Dir am
strukturierten und konsequenten Denken mangelt. Da hat sich wohl über
die Zeit eine gewisse Schlampigkeit etabliert. Das ist gar nicht weiter
schlimm; nur solltest Du Dir dessen bewußt sein.

[Arno Welzel]

Lars Gebauer, 2022-08-21 19:27:

> Am 21.08.2022 um 17:00 schrieb Arno Welzel:
>> Programme und Daten *SIND* fundamental unterschiedlich.
>
> Schreibe ich doch schon die ganze Zeit.
>
>> Deswegen ist ein Python-Script ein *Programm* und nicht nur "Daten".
>
> Nein. /Deswegen/ nun ganz bestimmt nicht.
>
>>> Ausgangspunkt war Deine Behauptung, daß ein Excel-File ein Programm sei,
>>> genauso wie ein Python-Skript. Und daß das wohl "niemand bezweifeln" würde.
>>
>> Es kann sein, dass in einem Excel-File Makros enthalten sind, die in VBA
>> o.Ä. geschrieben sind - *das* sind dann zweifellos Programme.
>
> Genau das bezweifele ich schon die ganze Zeit. Ganz besonders bezweifele
> ich das "zweifellos". Und bisher ist es weder Dir noch Peter gelungen,
> mich davon zu überzeugen.

Na dann schau hier:

<https://docs.microsoft.com/de-de/office/vba/library-reference/concepts/getting-started-with-vba-in-office>

Ja, ich ahne schon - für Dich sind das sicher nur wieder Daten, die halt
speziell interpretiert werden.

>> Aber ein Excel-File ohne Makros ist zweifellos *kein* Programm!
>
> Na, ob der Peter Dir das glaubt?

Das ist mir egal.

>>> Dann aber drängt sich (mir zumindest) die Frage auf, worin sich
>>> eigentlich das Excel-File oder das Python-Skipt von einer Text-, Bild-
>>> oder sonstigen Datei unterscheiden. Schließlich enthalten alle diese
>>
>> Sie unterscheiden sich dadurch, wofür sie *vorgesehen* sind.
>
> Gewiß nicht. Eine Zweckbestimmung wird immer erst durch den
> An-/Verwender gegeben und kann sehr willkürlich sein.

Falsch. Die Zweckbestimmung legt sehr genau fest, wofür die Daten
vorgesehen ist. Ein Programm ist immer ein Programm, egal ob Du als
Anwender den Quelltext dazu ausdruckst oder es durch einen Interpreter
oder Compiler zur Ausführung bringst.

Genau deshalb gibt es für Shells die shebang-Zeilen, damit klar ist, wie
etwas in der Konsole ausgeführt werden soll. Für Dich als Nutzer ist es
daher völlig wurscht, ob die Eingabe eines Kommandos direkt ein Binary
startet.

>> Ein Python-Skipt enthält Anweisungen in einer Programmiersprache.
>
> Richtig. Was es allerdings nicht zu einem Programm macht sondern nur den
> Interpreter (= das Programm) parametrisiert.

Wieder falsch. Das Python-Skipt *ist* das Programm.

Aber wenn für Dich "muss ein Interpreter ausführen" automatisch
bedeutet, dass etwas kein Programm mehr ist, dann gibt es keine
Programme! Denn *alles* was ein Computer ausführt muss *ausnahmslos*
*immer* interpretiert werden. Auch x86-Befehle müssen von der CPU
interpretiert werden.

[...]

>> Dann definiere bitte, was FÜR DICH ein "Programm" ist und was "Daten".
>
> Bitte lies meine Postings. Insbesondere die, auf die Du antwortest.

Habe ich. Ich habe keine Definition von Dir dafür gefunden. Kannst Du
mir die Message-ID nennen, wo Du das getan hast?

[Arno Welzel]

Lars Gebauer, 2022-08-21 19:46:

> Am 21.08.2022 um 16:54 schrieb Arno Welzel:
>> Meine Argumentation war, dass Programme nicht ausschliesslich in binärer
>> Form vorliegen müssen, sondern auch aus Befehlen in Textform bestehen
>> können, und zur Ausführung noch einenn Interpreter oder Compiler
>> benötigen. Das ändert aber nichts daran, dass es Programme sind und
>> keine Kochrezepte oder Bilder, wie z.B. SVG, was auch in Textform vorliegt.
>
> Dann erkläre mal den Unterschied zwischen bspw. einem Python-Script und
> einer Bilddatei. Die Bilddatei taugt nämlich ohne Interpreter auch nichts.

Die Bilddatei kann den Computer nicht zu beliebigen Aktionen
veranlassen, sondern kann nur benutzt werden, um Bilder zu speichern

>>> Produziert Deine Argumentation Ergebnisse, die Dir nicht gefallen? Dann
>>> solltest Du sie vielleicht überdenken.
>>
>> Produziert deine Ignoranz Ergebnisse, die Dir nicht gefallen?
>
> Überhaupt nicht. Ganz im Gegenteil bin ich mit den Ergebnissen
> hochgradig zufrieden.

Troll....

[Lars Gebauer]

Am 21.08.2022 um 20:24 schrieb Arno Welzel:
> Lars Gebauer, 2022-08-21 19:27:
>> Am 21.08.2022 um 17:00 schrieb Arno Welzel:
>>> Es kann sein, dass in einem Excel-File Makros enthalten sind, die in VBA
>>> o.Ä. geschrieben sind - *das* sind dann zweifellos Programme.
>>
>> Genau das bezweifele ich schon die ganze Zeit. Ganz besonders bezweifele
>> ich das "zweifellos". Und bisher ist es weder Dir noch Peter gelungen,
>> mich davon zu überzeugen.
>
> Na dann schau hier:
>
> <https://docs.microsoft.com/de-de/office/vba/library-reference/concepts/getting-started-with-vba-in-office>
>
> Ja, ich ahne schon - für Dich sind das sicher nur wieder Daten, die halt
> speziell interpretiert werden.

Womit Du vollkommen Recht hast. Ich sehe, wir nähern uns der Sache an.

>>>> Dann aber drängt sich (mir zumindest) die Frage auf, worin sich
>>>> eigentlich das Excel-File oder das Python-Skipt von einer Text-, Bild-
>>>> oder sonstigen Datei unterscheiden. Schließlich enthalten alle diese
>>>
>>> Sie unterscheiden sich dadurch, wofür sie *vorgesehen* sind.
>>
>> Gewiß nicht. Eine Zweckbestimmung wird immer erst durch den
>> An-/Verwender gegeben und kann sehr willkürlich sein.
>
> Falsch.

Nein.

> Die Zweckbestimmung legt sehr genau fest, wofür die Daten
> vorgesehen ist.

Überhaupt nicht. Der Zweck, den Du festlegst, muß mich überhaupt nicht
jucken. Und umgekehrt.

Der Zweck ergibt sich *immer* aus der Intention des An-/Verwenders.

>>> Ein Python-Skipt enthält Anweisungen in einer Programmiersprache.
>>
>> Richtig. Was es allerdings nicht zu einem Programm macht sondern nur den
>> Interpreter (= das Programm) parametrisiert.
>
> Wieder falsch. Das Python-Skipt *ist* das Programm.

Nein, der Interpreter ist das Programm.

> Aber wenn für Dich "muss ein Interpreter ausführen" automatisch
> bedeutet, dass etwas kein Programm mehr ist, dann gibt es keine
> Programme!

Aber immer gibt es die. Interpreter sind Programme. Das schreibe ich

doch schon die ganze Zeit.

>>> Dann definiere bitte, was FÜR DICH ein "Programm" ist und was "Daten".
>>
>> Bitte lies meine Postings. Insbesondere die, auf die Du antwortest.
>
> Habe ich. Ich habe keine Definition von Dir dafür gefunden. Kannst Du
> mir die Message-ID nennen, wo Du das getan hast?

<tdq844$1rihv$1...@dont-email.me> Das ist das, auf das Du geantwortet hast.

[Lars Gebauer]

Am 21.08.2022 um 20:26 schrieb Arno Welzel:
> Lars Gebauer, 2022-08-21 19:46:
>> Am 21.08.2022 um 16:54 schrieb Arno Welzel:
>>> Meine Argumentation war, dass Programme nicht ausschliesslich in binärer
>>> Form vorliegen müssen, sondern auch aus Befehlen in Textform bestehen
>>> können, und zur Ausführung noch einenn Interpreter oder Compiler
>>> benötigen. Das ändert aber nichts daran, dass es Programme sind und
>>> keine Kochrezepte oder Bilder, wie z.B. SVG, was auch in Textform vorliegt.
>>
>> Dann erkläre mal den Unterschied zwischen bspw. einem Python-Script und
>> einer Bilddatei. Die Bilddatei taugt nämlich ohne Interpreter auch nichts.
>
> Die Bilddatei kann den Computer nicht zu beliebigen Aktionen
> veranlassen, sondern kann nur benutzt werden, um Bilder zu speichern

Na das ist ja nun völliger Blödsinn. Was da passiert, hängt einzig vom
Interpreter der Bilddatei ab.

[Peter J. Holzer]

Das ist die, die ich in diesem Thread angeführt habe. Mir reicht sie
also offensichtlich. Lars nicht, aber seine Definiton wollte er uns
bisher nicht mitteilen. Wir wissen nur, dass Python-Programme nicht
darunterfallen.

hp

[Arno Welzel]

Lars Gebauer, 2022-08-21 21:27:

> Am 21.08.2022 um 20:24 schrieb Arno Welzel:
>> Lars Gebauer, 2022-08-21 19:27:
>>> Am 21.08.2022 um 17:00 schrieb Arno Welzel:
>>>> Es kann sein, dass in einem Excel-File Makros enthalten sind, die in VBA
>>>> o.Ä. geschrieben sind - *das* sind dann zweifellos Programme.
>>>
>>> Genau das bezweifele ich schon die ganze Zeit. Ganz besonders bezweifele
>>> ich das "zweifellos". Und bisher ist es weder Dir noch Peter gelungen,
>>> mich davon zu überzeugen.
>>
>> Na dann schau hier:
>>
>> <https://docs.microsoft.com/de-de/office/vba/library-reference/concepts/getting-started-with-vba-in-office>
>>
>> Ja, ich ahne schon - für Dich sind das sicher nur wieder Daten, die halt
>> speziell interpretiert werden.
>
> Womit Du vollkommen Recht hast. Ich sehe, wir nähern uns der Sache an.

Nö. Denn ich teile deine Ansicht nicht.

[...]>> Habe ich. Ich habe keine Definition von Dir dafür gefunden.

Kannst Du
>> mir die Message-ID nennen, wo Du das getan hast?
>
> <tdq844$1rihv$1...@dont-email.me> Das ist das, auf das Du geantwortet hast.

Nein.

<http://al.howardknight.net/?STYPE=msgid&MSGI=%3Ctdq844%241rihv%241%40dont-email.me%3E>

Da steht exakt NICHTS dazu, wie DU "Programm" konkret definierst.

Da steht nur:

"Programme interpretieren und verarbeiten Daten. Aber nicht umgekehrt."

Ein Python-Script interpretiert und verarbeitet Daten - also ist es ein
Programm. Die Tatsache, dass Python-Script eine Laufzeitumgebung dafür
benötigt, ist irrelevant, weil auch ein Binary mit x86-Code ebenfalls
eine Laufzeitumgebung braucht.

Du aber behauptest, dass ein Python-Script kein Programm sei, weil es
von einem Python-Interpreter ausgeführt wird.

Ob nun bei Dir aber "Interpreter nötig = kein Programm" gilt, ist mir
noch nicht klar. Wenn Du so argumentierst, gibt es eigentlich keine
Programme, da auch ein x86-Binary durch den x86-Interpreter der CPU
interpretiert werden muss, der seinerseits in Microcode geschrieben
wurde. Damit würde dann deiner Lesart folgendend gelten, dass nur der
Microcode von CPUs Programme sind, weil nur dieser Code direkt vom
CPU-Kern ausgeführt wird und nicht interpretiert werden muss.

[Arno Welzel]

Lars Gebauer, 2022-08-21 21:34:

> Am 21.08.2022 um 20:26 schrieb Arno Welzel:
>> Lars Gebauer, 2022-08-21 19:46:
>>> Am 21.08.2022 um 16:54 schrieb Arno Welzel:
>>>> Meine Argumentation war, dass Programme nicht ausschliesslich in binärer
>>>> Form vorliegen müssen, sondern auch aus Befehlen in Textform bestehen
>>>> können, und zur Ausführung noch einenn Interpreter oder Compiler
>>>> benötigen. Das ändert aber nichts daran, dass es Programme sind und
>>>> keine Kochrezepte oder Bilder, wie z.B. SVG, was auch in Textform vorliegt.
>>>
>>> Dann erkläre mal den Unterschied zwischen bspw. einem Python-Script und
>>> einer Bilddatei. Die Bilddatei taugt nämlich ohne Interpreter auch nichts.
>>
>> Die Bilddatei kann den Computer nicht zu beliebigen Aktionen
>> veranlassen, sondern kann nur benutzt werden, um Bilder zu speichern
>
> Na das ist ja nun völliger Blödsinn. Was da passiert, hängt einzig vom
> Interpreter der Bilddatei ab.

Welche Programme interpretieren Bilddateien so, dass sie sich dann
genaus verhalten wie Scripte in einer Programmiersprache inkl.
Variablen, Sprüngen, Bedingungen, Schleifen etc.? Wo ist der Standard
dafür beschrieben? Die Erweiterung dafür in Formaten wie JPEG oder PNG
muss ich wohl übersehen haben.

Und nein, ich meine bewusst nicht SVG oder PostScript, sondern
Bitmap-Formate.

[Lars Gebauer]

Am 22.08.2022 um 17:42 schrieb Arno Welzel:
> Lars Gebauer, 2022-08-21 21:34:
>> Am 21.08.2022 um 20:26 schrieb Arno Welzel:
>>> Lars Gebauer, 2022-08-21 19:46:

>>>> Dann erkläre mal den Unterschied zwischen bspw. einem Python-Script und
>>>> einer Bilddatei. Die Bilddatei taugt nämlich ohne Interpreter auch nichts.
>>>
>>> Die Bilddatei kann den Computer nicht zu beliebigen Aktionen
>>> veranlassen, sondern kann nur benutzt werden, um Bilder zu speichern
>>
>> Na das ist ja nun völliger Blödsinn. Was da passiert, hängt einzig vom
>> Interpreter der Bilddatei ab.
>
> Welche Programme interpretieren Bilddateien so, dass sie sich dann
> genaus verhalten wie Scripte in einer Programmiersprache inkl.
> Variablen, Sprüngen, Bedingungen, Schleifen etc.?

Im Zweifel immer die, die $morgen geschrieben werden.

Daß es solche Programme momentan nicht gibt (afaik) heißt doch nicht,
daß es sie nicht geben könnte.

[Lars Gebauer]

Am 22.08.2022 um 17:39 schrieb Arno Welzel:
> Da steht exakt NICHTS dazu, wie DU "Programm" konkret definierst.

Falsch.

> Da steht nur:
>
> "Programme interpretieren und verarbeiten Daten. Aber nicht umgekehrt."

Richtig.

> Ein Python-Script interpretiert und verarbeitet Daten

Tut es selbstverst#ndlich nicht. Versuche mal, das Python-Skript ohne
Python-Interpreter aufzurufen. Du wirst feststellen, daß genau gar
nichts passiert. Bestenfalls kommt eine Fehlermeldung.

Das Python-Skript interpretiert und verarbeitet also *nichts*.

> Du aber behauptest, dass ein Python-Script kein Programm sei, weil es
> von einem Python-Interpreter ausgeführt wird.

Richtig. Der Python-Interpreter verarbeitet die Daten.

Das Skript bestimmt dabei nur, was konkret der Interpreter mit den Daten
machen soll. Iow: Es parametrisiert den Interpreter.

> Ob nun bei Dir aber "Interpreter nötig = kein Programm" gilt, ist mir
> noch nicht klar. Wenn Du so argumentierst, gibt es eigentlich keine
> Programme, da auch ein x86-Binary durch den x86-Interpreter der CPU
> interpretiert werden muss, der seinerseits in Microcode geschrieben
> wurde.

Ich habe nie bestritten, daß Programme auch Programme interpretieren und
verarbeiten können.

[Peter J. Holzer]

On 2022-08-21 15:00, Arno Welzel <use...@arnowelzel.de> wrote:
> Lars Gebauer, 2022-08-20 11:06:
>
>> Am 20.08.2022 um 09:25 schrieb Peter J. Holzer:
>>> On 2022-08-20 06:23, Lars Gebauer <lgeb...@live.de> wrote:
>>>> Am 20.08.2022 um 02:58 schrieb Arno Welzel:
>>>>> Nein, Du hast mir nicht Recht gegeben. Ich habe nicht behauptet, dass
>>>>> Bilddaten Programme wären.
>>>>
>>>> Das ist aber die Konsequenz, wenn man Deiner Argumentation folgt.
>>>
>>> Nein. Nur wenn man deiner Dichotomie folgt:
>>>
>>> Entweder:
>>> 1) Programme und Daten sind fundamental unterschiedlich. Etwas ist
>>> entweder Daten oder Programm
>>> oder:
>>> 2) Daten und Programme sind das gleiche. Alle Daten sind
>>> Programme und umgekehrt,
>>>
>>> Aber warum sollte man das tun?
>>
>> Genau das. Ich frage mich schon die ganze Zeit, warum Ihr das tut.
>
> Das tue ich nicht!
>
> Programme und Daten *SIND* fundamental unterschiedlich.

Da widerspreche ich.

| Gebilde aus Zeichen oder kontinuierliche Funktionen, die aufgrund
| bekannter oder unterstellter Abmachungen Informationen darstellen,
| vorrangig zum Zweck der Verarbeitung und als deren Ergebnis.
-- DIN 44300 Nr. 19

| a reinterpretable representation of information in a formalized
| manner, suitable for communication, interpretation, or processing
-- ISO/IEC 2382-1

(beide zitiert in https://de.wikipedia.org/wiki/Daten#Informatik)

Diese Definitionen treffen auf Programme zu. Folglich sind Programme
Daten (aber nicht notwendigerweise umgekehrt).

Der Wikipedia-Artikel erwähnt dann weiter unten auch "Programmcode,
Ausführbare Dateien usw." als Beispiele von "technischen Daten".

> Deswegen ist ein Python-Script ein *Programm* und nicht nur "Daten".

Das scheint mir ein Non-Sequitur zu sein.

Ein Python-Script ist ein Programm, weil es eben der Definition eines
Programms genügt.

>> Dann aber drängt sich (mir zumindest) die Frage auf, worin sich
>> eigentlich das Excel-File oder das Python-Skipt von einer Text-, Bild-
>> oder sonstigen Datei unterscheiden. Schließlich enthalten alle diese
>
> Sie unterscheiden sich dadurch, wofür sie *vorgesehen* sind.

ACK.

> Ein Python-Skipt enthält Anweisungen in einer Programmiersprache.
>
> Ein Excel-File - wenn man Makros mal außen vorlässt - dagegen nur Zahlen
> und Formeln.

^^^^^^^
Formeln sind eine Programmiersprache. Mit Rekursion wäre es sogar eine
turing-vollständige. (Ich wollte schon Fibonacci oder sowas implemen-
tieren, kann aber leider nicht, weil unsere Excel-Version zu alt ist.
Offenbar sind rekursive Funktionen erst in den letzten 1-2 Jahren für
die breite Masse freigeschaltet worden (Build
vierzehntausendundirgendwas). Gelesen habe ich davon das erste Mal vor
etlichen Jahren, daher meine optimistische Annahme, dass das
mittlerweile ein Standardfeature ist (aber naja, der Begriff Vapourware
wurde ja von Microsoft erfunden ...).)

hp

[Lars Gebauer]

Am 22.08.2022 um 21:27 schrieb Peter J. Holzer:
> (beide zitiert in https://de.wikipedia.org/wiki/Daten#Informatik)
>
> Diese Definitionen treffen auf Programme zu. Folglich sind Programme
> Daten (aber nicht notwendigerweise umgekehrt).

Sag' ich doch die ganze Zeit.

> Ein Python-Script ist ein Programm, weil es eben der Definition eines
> Programms genügt.

Ein Programm ist etwas "Ausführbares". Ich rufe ein Programm auf - und
$irgendetwas passiert: Am Bildschirm wird irgendwas aufgelistet, es
zeigt sich ein prompt und es wird auf eine weitere Eingabe gewartet,
eine grafische Anwendung wird gestartet, $irgendwas. Vielleicht läuft
auch nur eine Hintergrund-Anwendung ab. Aber es passiert was.

Rufe ich ein Python-Skript auf, passiert nichts. Überhaupt nichts.
Maximal erscheint eine vom Betriebsystem generierte Fehlermeldung.

Es sei denn, ein Python-Interpreter ist installiert. Dann übergibt das
Betriebssystem das Skript an jenen Interpreter und *dann* passiert
etwas. Der Interpreter ist das Programm, das Skript enthält nur Daten
(die an den Interpreter übergeben werden und ihn parametrisieren).

Nicht anders bei einer Bild-Datei:

Rufe ich ein .jpg auf, passiert nichts. Überhaupt nichts. Maximal
erscheint eine vom Betriebsystem generierte Fehlermeldung.

Es sei denn, ein .jpg-Interpreter ist installiert. Dann übergibt das
Betriebssystem das .jpg an jenen Interpreter und *dann* passiert etwas.
Der Interpreter ist das Programm, das .jpg enthält nur Daten (die an den
Interpreter übergeben werden und ihn parametrisieren).

Ebenso bei einem Excel-File:

Rufe ich ein Excel-File auf, passiert nichts. Überhaupt nichts. Maximal
erscheint eine vom Betriebsystem generierte Fehlermeldung.

Es sei denn, ein Excel-Interpreter ist installiert. Dann übergibt das
Betriebssystem das Excel-File an jenen Interpreter und *dann* passiert
etwas. Der Interpreter ist das Programm, das Excel-File enthält nur
Daten (die an den Interpreter übergeben werden und ihn parametrisieren).

Daß die an den Interpreter übergebenen Daten verschieden komplex sein
können, ist vollkommen richtig. Tut aber überhaupt nichts zur Sache, da
das kein qualitativer Unterschied ist.

[Arno Welzel]

Lars Gebauer, 2022-08-22 19:27:

> Am 22.08.2022 um 17:39 schrieb Arno Welzel:
>> Da steht exakt NICHTS dazu, wie DU "Programm" konkret definierst.
>
> Falsch.
>
>> Da steht nur:
>>
>> "Programme interpretieren und verarbeiten Daten. Aber nicht umgekehrt."
>
> Richtig.
>
>> Ein Python-Script interpretiert und verarbeitet Daten
>
> Tut es selbstverst#ndlich nicht. Versuche mal, das Python-Skript ohne
> Python-Interpreter aufzurufen. Du wirst feststellen, daß genau gar
> nichts passiert. Bestenfalls kommt eine Fehlermeldung.
>
> Das Python-Skript interpretiert und verarbeitet also *nichts*.

Versuche mal ein x86-Binary auf einer ARM-CPU auszuführen. Ein
x86-Binary interpretiert und verarbeitet also *nichts* ohne die richtige
Laufzeitumgebung.

>> Du aber behauptest, dass ein Python-Script kein Programm sei, weil es
>> von einem Python-Interpreter ausgeführt wird.
>
> Richtig. Der Python-Interpreter verarbeitet die Daten.
>
> Das Skript bestimmt dabei nur, was konkret der Interpreter mit den Daten
> machen soll. Iow: Es parametrisiert den Interpreter.

Diesere Argumentation folgende gibt gar keine Programme. Denn *alles*
muss interpretiert werden.

>> Ob nun bei Dir aber "Interpreter nötig = kein Programm" gilt, ist mir
>> noch nicht klar. Wenn Du so argumentierst, gibt es eigentlich keine
>> Programme, da auch ein x86-Binary durch den x86-Interpreter der CPU
>> interpretiert werden muss, der seinerseits in Microcode geschrieben
>> wurde.
>
> Ich habe nie bestritten, daß Programme auch Programme interpretieren und
> verarbeiten können.

Deiner Logik nach gibt es aber keine Programme. Es sei denn, Du
definierst GANZ EXAKT wann etwas als "Programm" anzusehen ist.

Nein, auch ein Python-Interpreter ist deiner bisherigen Argumentation
nach KEIN PROGRAMM! Denn auch der Python-Interpreter läuft nicht ohne
Laufzeitumgebung, die den Interpreter selbst wieder interpretiert.

[Arno Welzel]

Lars Gebauer, 2022-08-23 14:42:

> Am 22.08.2022 um 21:27 schrieb Peter J. Holzer:
>> (beide zitiert in https://de.wikipedia.org/wiki/Daten#Informatik)
>>
>> Diese Definitionen treffen auf Programme zu. Folglich sind Programme
>> Daten (aber nicht notwendigerweise umgekehrt).
>
> Sag' ich doch die ganze Zeit.
>
>> Ein Python-Script ist ein Programm, weil es eben der Definition eines
>> Programms genügt.
>
> Ein Programm ist etwas "Ausführbares". Ich rufe ein Programm auf - und

Das trifft auf ein Python-Script zu.

> $irgendetwas passiert: Am Bildschirm wird irgendwas aufgelistet, es
> zeigt sich ein prompt und es wird auf eine weitere Eingabe gewartet,
> eine grafische Anwendung wird gestartet, $irgendwas. Vielleicht läuft
> auch nur eine Hintergrund-Anwendung ab. Aber es passiert was.
>
> Rufe ich ein Python-Skript auf, passiert nichts. Überhaupt nichts.
> Maximal erscheint eine vom Betriebsystem generierte Fehlermeldung.

Genaus wie wenn ich auf einem x86-PC ein ARM-Binary aufrufen würde oder
unter Windows ein Linux-Programm starten wollte

> Es sei denn, ein Python-Interpreter ist installiert. Dann übergibt das
> Betriebssystem das Skript an jenen Interpreter und *dann* passiert
> etwas. Der Interpreter ist das Programm, das Skript enthält nur Daten
> (die an den Interpreter übergeben werden und ihn parametrisieren).

Ja und? Das passiert mit JEDEM(!) Programm so! Du merkst das nur nicht.

[Arno Welzel]

Lars Gebauer, 2022-08-22 19:15:

> Am 22.08.2022 um 17:42 schrieb Arno Welzel:
>> Lars Gebauer, 2022-08-21 21:34:
>>> Am 21.08.2022 um 20:26 schrieb Arno Welzel:
>>>> Lars Gebauer, 2022-08-21 19:46:
>>>>> Dann erkläre mal den Unterschied zwischen bspw. einem Python-Script und
>>>>> einer Bilddatei. Die Bilddatei taugt nämlich ohne Interpreter auch nichts.
>>>>
>>>> Die Bilddatei kann den Computer nicht zu beliebigen Aktionen
>>>> veranlassen, sondern kann nur benutzt werden, um Bilder zu speichern
>>>
>>> Na das ist ja nun völliger Blödsinn. Was da passiert, hängt einzig vom
>>> Interpreter der Bilddatei ab.
>>
>> Welche Programme interpretieren Bilddateien so, dass sie sich dann
>> genaus verhalten wie Scripte in einer Programmiersprache inkl.
>> Variablen, Sprüngen, Bedingungen, Schleifen etc.?
>
> Im Zweifel immer die, die $morgen geschrieben werden.

Lenke nicht ab. Beweise deine Behauptung. Nein, dass es irgendwann
irgendwas geben könnte, ist kein Beweis.

[Lars Gebauer]

Am 23.08.2022 um 16:10 schrieb Arno Welzel:
> Lars Gebauer, 2022-08-22 19:15:
>> Am 22.08.2022 um 17:42 schrieb Arno Welzel:
>>> Lars Gebauer, 2022-08-21 21:34:

>>>> Na das ist ja nun völliger Blödsinn. Was da passiert, hängt einzig vom
>>>> Interpreter der Bilddatei ab.
>>>
>>> Welche Programme interpretieren Bilddateien so, dass sie sich dann
>>> genaus verhalten wie Scripte in einer Programmiersprache inkl.
>>> Variablen, Sprüngen, Bedingungen, Schleifen etc.?
>>
>> Im Zweifel immer die, die $morgen geschrieben werden.
>
> Lenke nicht ab. Beweise deine Behauptung.

Was gibt es da zu beweisen? Willst Du ernsthaft behaupten, daß es
unmöglich ist, daß es ein solches Programm gibt? Oder doch wenigstens
geben könnte?

[Lars Gebauer]

Am 23.08.2022 um 16:09 schrieb Arno Welzel:
> Lars Gebauer, 2022-08-23 14:42:
>> Am 22.08.2022 um 21:27 schrieb Peter J. Holzer:
>>> Ein Python-Script ist ein Programm, weil es eben der Definition eines
>>> Programms genügt.
>>
>> Ein Programm ist etwas "Ausführbares". Ich rufe ein Programm auf - und
>
> Das trifft auf ein Python-Script zu.

Was? Daß ich es aufrufe? In der Tat.

>> Es sei denn, ein Python-Interpreter ist installiert. Dann übergibt das
>> Betriebssystem das Skript an jenen Interpreter und *dann* passiert
>> etwas. Der Interpreter ist das Programm, das Skript enthält nur Daten
>> (die an den Interpreter übergeben werden und ihn parametrisieren).
>
> Ja und? Das passiert mit JEDEM(!) Programm so! Du merkst das nur nicht.

Richtig! Mit jedem *Programm*!

Nicht aber mit einem Daten-File. Da passiert ohne Programm
(=Interpreter) gar nichts.

[Lars Gebauer]

Am 23.08.2022 um 16:06 schrieb Arno Welzel:
> Lars Gebauer, 2022-08-22 19:27:
>> Am 22.08.2022 um 17:39 schrieb Arno Welzel:
>>> Ein Python-Script interpretiert und verarbeitet Daten
>>
>> Tut es selbstverst#ndlich nicht. Versuche mal, das Python-Skript ohne
>> Python-Interpreter aufzurufen. Du wirst feststellen, daß genau gar
>> nichts passiert. Bestenfalls kommt eine Fehlermeldung.
>>
>> Das Python-Skript interpretiert und verarbeitet also *nichts*.
>
> Versuche mal ein x86-Binary auf einer ARM-CPU auszuführen.

Wozu? Bleib' doch einfach mal bei der Sache und versuche nicht laufend
abzulenken.

> Ein
> x86-Binary interpretiert und verarbeitet also *nichts* ohne die richtige
> Laufzeitumgebung.

Und wennschon: Programme können natürlich auch andere Programme
verarbeiten. Wie oft muß ich das noch schreiben?

>>> Du aber behauptest, dass ein Python-Script kein Programm sei, weil es
>>> von einem Python-Interpreter ausgeführt wird.
>>
>> Richtig. Der Python-Interpreter verarbeitet die Daten.
>>
>> Das Skript bestimmt dabei nur, was konkret der Interpreter mit den Daten
>> machen soll. Iow: Es parametrisiert den Interpreter.
>
> Diesere Argumentation folgende gibt gar keine Programme.

Doch: Interpreter sind Programme.

> Denn *alles* muss interpretiert werden.

Ja - aber nicht "Alles" kann alles interpretieren. Python-Skripte bspw.
können das nicht. Die brauchen dafür einen Interpreter. Was sie mit txt-
oder jpg-Files gemeinsam haben.

>>> Ob nun bei Dir aber "Interpreter nötig = kein Programm" gilt, ist mir
>>> noch nicht klar. Wenn Du so argumentierst, gibt es eigentlich keine
>>> Programme, da auch ein x86-Binary durch den x86-Interpreter der CPU
>>> interpretiert werden muss, der seinerseits in Microcode geschrieben
>>> wurde.
>>
>> Ich habe nie bestritten, daß Programme auch Programme interpretieren und
>> verarbeiten können.
>
> Deiner Logik nach gibt es aber keine Programme.

Aber natürlich gibt es die. Interpreter sind bspw. welche.

> Nein, auch ein Python-Interpreter ist deiner bisherigen Argumentation
> nach KEIN PROGRAMM! Denn auch der Python-Interpreter läuft nicht ohne
> Laufzeitumgebung, die den Interpreter selbst wieder interpretiert.

Ja. Weil Programme auch Programme interpretieren können. Was Daten nicht

[Arno Welzel]

Lars Gebauer, 2022-08-23 16:30:

> Am 23.08.2022 um 16:10 schrieb Arno Welzel:
>> Lars Gebauer, 2022-08-22 19:15:
>>> Am 22.08.2022 um 17:42 schrieb Arno Welzel:
>>>> Lars Gebauer, 2022-08-21 21:34:
>>>>> Na das ist ja nun völliger Blödsinn. Was da passiert, hängt einzig vom
>>>>> Interpreter der Bilddatei ab.
>>>>
>>>> Welche Programme interpretieren Bilddateien so, dass sie sich dann
>>>> genaus verhalten wie Scripte in einer Programmiersprache inkl.
>>>> Variablen, Sprüngen, Bedingungen, Schleifen etc.?
>>>
>>> Im Zweifel immer die, die $morgen geschrieben werden.
>>
>> Lenke nicht ab. Beweise deine Behauptung.
>
> Was gibt es da zu beweisen? Willst Du ernsthaft behaupten, daß es
> unmöglich ist, daß es ein solches Programm gibt? Oder doch wenigstens
> geben könnte?

Deine Aussage war, dass Bilder auch als Programme interpretiert werden
können. Dann zeige ein Beispiel dafür.

Und selbst wenn jemand ein Programm schreibt, dass Inhalte aus Bildern
als Programme interpretiert und ausführt, dann sind diese Bilder eben
auch Programme, weil sie explizit dafür *vorgesehen* sind! Denn auch die
Bilder müssen logischerweise passende Inhalte dafür haben, so wie nicht
jeder Text automatisch auch ein Programm ist, nur weil man Texte als
Programme interpretieren kann.

[Arno Welzel]

Lars Gebauer, 2022-08-23 16:43:

> Am 23.08.2022 um 16:06 schrieb Arno Welzel:
>> Lars Gebauer, 2022-08-22 19:27:
>>> Am 22.08.2022 um 17:39 schrieb Arno Welzel:
>>>> Ein Python-Script interpretiert und verarbeitet Daten
>>>
>>> Tut es selbstverst#ndlich nicht. Versuche mal, das Python-Skript ohne
>>> Python-Interpreter aufzurufen. Du wirst feststellen, daß genau gar
>>> nichts passiert. Bestenfalls kommt eine Fehlermeldung.
>>>
>>> Das Python-Skript interpretiert und verarbeitet also *nichts*.
>>
>> Versuche mal ein x86-Binary auf einer ARM-CPU auszuführen.
>
> Wozu? Bleib' doch einfach mal bei der Sache und versuche nicht laufend
> abzulenken.

Das *IST* die Sachen! Genau das! DU(!) faselst die ganze Zeit davon,
dass irgendtwas kein Programm mehr ist, wenn es nicht direkt auf einem
Computer "aufgerufen" werden kann.

Genau das gilt exakt GANZ GENAU SO(!), wenn das Binary nicht passend zur
CPU ist! Und ja - mit einem Emulator ist das ebenso lösbar - ist das
dann kein Programm mehr, wenn der x86-Code auf eier ARM-CPU durch einen
Emulator interpretiert werden muss?

[...]

>> Diesere Argumentation folgende gibt gar keine Programme.
>
> Doch: Interpreter sind Programme.

Falsch! DEINE(!) Argumentation sagt, wenn etwas interpretiert werden
muss, ist es kein Programm mehr!

Es muss aber ALLES interpretiert werden, ausnahmslos!

>> Denn *alles* muss interpretiert werden.
>
> Ja - aber nicht "Alles" kann alles interpretieren. Python-Skripte bspw.
> können das nicht. Die brauchen dafür einen Interpreter. Was sie mit txt-
> oder jpg-Files gemeinsam haben.

ALLES(!) braucht einen Interpreter!

[...]

>> Deiner Logik nach gibt es aber keine Programme.
>
> Aber natürlich gibt es die. Interpreter sind bspw. welche.

Nein, da sie deiner Logik folgend ebenfalls interpretiert werden müssen.

[Arno Welzel]

Lars Gebauer, 2022-08-23 16:34:

> Am 23.08.2022 um 16:09 schrieb Arno Welzel:

[...]

>> Ja und? Das passiert mit JEDEM(!) Programm so! Du merkst das nur nicht.
>
> Richtig! Mit jedem *Programm*!
>
> Nicht aber mit einem Daten-File. Da passiert ohne Programm
> (=Interpreter) gar nichts.

Das gilt aber IMMER. Daher gibt es in deiner Welt keine Programme,
sondern nur nur "Daten-Files", von denen für manche auch Interpreter
existieren. Diese Interpreter sind aber selbst ebenfalls nur
"Daten-Files", die zufälligerweise von einem anderen Interpreter
ausgeführt werden können, der beim Betriebssystem schon dabei war.

[Peter J. Holzer]

On 2022-08-23 14:30, Lars Gebauer <lgeb...@live.de> wrote:
> Am 23.08.2022 um 16:10 schrieb Arno Welzel:
>> Lars Gebauer, 2022-08-22 19:15:
>>> Am 22.08.2022 um 17:42 schrieb Arno Welzel:
>>>> Lars Gebauer, 2022-08-21 21:34:
>>>>> Na das ist ja nun völliger Blödsinn. Was da passiert, hängt einzig vom
>>>>> Interpreter der Bilddatei ab.
>>>>
>>>> Welche Programme interpretieren Bilddateien so, dass sie sich dann
>>>> genaus verhalten wie Scripte in einer Programmiersprache inkl.
>>>> Variablen, Sprüngen, Bedingungen, Schleifen etc.?
>>>
>>> Im Zweifel immer die, die $morgen geschrieben werden.
>>
>> Lenke nicht ab. Beweise deine Behauptung.
>
> Was gibt es da zu beweisen? Willst Du ernsthaft behaupten, daß es
> unmöglich ist, daß es ein solches Programm gibt? Oder doch wenigstens
> geben könnte?

Du kannst natürlich jedes File in .com umbenennen und unter MS-DOS
ausführen[1]. Irgendwas wird das schon tun. Macht das jedes File in
Deinen Augen zum Programm? Es sollte jedenfalls Deinen Kriterien
entsprechen, soweit ich sie erkennen kann: Es ist ausführbar und es
braucht keinen Interpreter außer der CPU.

hp

[1] Zumindest, wenn es kürzer als 65280 Bytes ist. Bin mir nicht sicher,
was MS-DOS mit COM-Files gemacht hat, die nicht in ein Segment passen.

[Laurenz Trossel]

On 2022-08-23, Arno Welzel <use...@arnowelzel.de> wrote:

> Deine Aussage war, dass Bilder auch als Programme interpretiert werden
> können. Dann zeige ein Beispiel dafür.

Das Beispiel war:
https://www.securityweek.com/google-says-nso-pegasus-zero-click-most-technically-sophisticated-exploit-ever-seen

Eine virtuelle CPU und Programme in Bilddaten, die vom
Bilddaten-Interpreter ausgeführt werden.

[Laurenz Trossel]

On 2022-08-23, Arno Welzel <use...@arnowelzel.de> wrote:

> Deine Aussage war, dass Bilder auch als Programme interpretiert werden
> können. Dann zeige ein Beispiel dafür.

Eine Frage habe ich noch: Ist Postscript eine Programmiersprache oder ein
Datenformat?

[Lars Gebauer]

Am 23.08.2022 um 22:19 schrieb Arno Welzel:
> Lars Gebauer, 2022-08-23 16:30:
>> Am 23.08.2022 um 16:10 schrieb Arno Welzel:
>>> Lars Gebauer, 2022-08-22 19:15:
>>>> Am 22.08.2022 um 17:42 schrieb Arno Welzel:
>>>>> Welche Programme interpretieren Bilddateien so, dass sie sich dann
>>>>> genaus verhalten wie Scripte in einer Programmiersprache inkl.
>>>>> Variablen, Sprüngen, Bedingungen, Schleifen etc.?
>>>>
>>>> Im Zweifel immer die, die $morgen geschrieben werden.
>>>
>>> Lenke nicht ab. Beweise deine Behauptung.
>>
>> Was gibt es da zu beweisen? Willst Du ernsthaft behaupten, daß es
>> unmöglich ist, daß es ein solches Programm gibt? Oder doch wenigstens
>> geben könnte?
>
> Deine Aussage war, dass Bilder auch als Programme interpretiert werden
> können.

Nein, das war und ist *nicht* meine Aussage. Noch nie.

> Dann zeige ein Beispiel dafür.

Du denkst Dir Blödsinn aus und ich soll ein Beispiel dafür zeigen?

[Lars Gebauer]

Am 23.08.2022 um 22:23 schrieb Arno Welzel:
> Lars Gebauer, 2022-08-23 16:43:

>>> Versuche mal ein x86-Binary auf einer ARM-CPU auszuführen.
>>
>> Wozu? Bleib' doch einfach mal bei der Sache und versuche nicht laufend
>> abzulenken.
>
> Das *IST* die Sachen! Genau das! DU(!) faselst die ganze Zeit davon,
> dass irgendtwas kein Programm mehr ist, wenn es nicht direkt auf einem
> Computer "aufgerufen" werden kann.
>
> Genau das gilt exakt GANZ GENAU SO(!), wenn das Binary nicht passend zur
> CPU ist!

Dann ist es eben für für diesen Computer kein Programm. Wo soll das
jetzt das Problem sein?

>>> Diesere Argumentation folgende gibt gar keine Programme.
>>
>> Doch: Interpreter sind Programme.
>
> Falsch! DEINE(!) Argumentation sagt, wenn etwas interpretiert werden
> muss, ist es kein Programm mehr!

Nein. Das war und ist nicht meine Aussage. Eher im Gegenteil habe ich
schon mehrfach geschrieben, daß Programme selbstverständlich auch
Programme ausführen können.

>>> Denn *alles* muss interpretiert werden.
>>
>> Ja - aber nicht "Alles" kann alles interpretieren. Python-Skripte bspw.
>> können das nicht. Die brauchen dafür einen Interpreter. Was sie mit txt-
>> oder jpg-Files gemeinsam haben.
>
> ALLES(!) braucht einen Interpreter!

Aber nicht alle *ist* ein Interpreter.

[Lars Gebauer]

Am 23.08.2022 um 22:25 schrieb Arno Welzel:
> Lars Gebauer, 2022-08-23 16:34:
>> Am 23.08.2022 um 16:09 schrieb Arno Welzel:
> [...]
>>> Ja und? Das passiert mit JEDEM(!) Programm so! Du merkst das nur nicht.
>>
>> Richtig! Mit jedem *Programm*!
>>
>> Nicht aber mit einem Daten-File. Da passiert ohne Programm
>> (=Interpreter) gar nichts.
>
> Das gilt aber IMMER.

Dennoch sind nicht alle Daten auch Interpreter. Manche sind einfach nur
Daten(-Files).

[Stefan Reuther]

Am 24.08.2022 um 15:14 schrieb Lars Gebauer:
> Am 23.08.2022 um 22:25 schrieb Arno Welzel:
>> Lars Gebauer, 2022-08-23 16:34:
>>> Am 23.08.2022 um 16:09 schrieb Arno Welzel:
>> [...]
>>>> Ja und? Das passiert mit JEDEM(!) Programm so! Du merkst das nur nicht.
>>>
>>> Richtig! Mit jedem *Programm*!
>>>
>>> Nicht aber mit einem Daten-File. Da passiert ohne Programm
>>> (=Interpreter) gar nichts.
>>
>> Das gilt aber IMMER.
>
> Dennoch sind nicht alle Daten auch Interpreter. Manche sind einfach nur
> Daten(-Files).

Irgendwann wird jemand die Datendatei in einer grafischen Oberfläche
anzeigen wollen. Und dann dient sie als Eingabe für den Hint-Interpreter
im Fontrenderer.

(siehe z.B. <https://litherum.blogspot.com/2019/03/addition-font.html>)


Stefan

[Arno Welzel]

Lars Gebauer, 2022-08-24 15:05:

> Am 23.08.2022 um 22:23 schrieb Arno Welzel:
>> Lars Gebauer, 2022-08-23 16:43:
>>>> Versuche mal ein x86-Binary auf einer ARM-CPU auszuführen.
>>>
>>> Wozu? Bleib' doch einfach mal bei der Sache und versuche nicht laufend
>>> abzulenken.
>>
>> Das *IST* die Sachen! Genau das! DU(!) faselst die ganze Zeit davon,
>> dass irgendtwas kein Programm mehr ist, wenn es nicht direkt auf einem
>> Computer "aufgerufen" werden kann.
>>
>> Genau das gilt exakt GANZ GENAU SO(!), wenn das Binary nicht passend zur
>> CPU ist!
>
> Dann ist es eben für für diesen Computer kein Programm. Wo soll das
> jetzt das Problem sein?

Das Problem ist deine Aussage, dass irgendetwas für Dich kein Programm
ist, nur weil irgendwelche Rahmenbedingungen gerade nicht passen.

Wenn Dir jemand einen Text vorlegt, der ein Kochrezept enthält, Du die
Sprache des Textes aber nicht verstehst, sagst Du dann acuh "Das ist
kein Kochrezept, weil ich den Text nicht verstehe."?

[...]

>> Falsch! DEINE(!) Argumentation sagt, wenn etwas interpretiert werden
>> muss, ist es kein Programm mehr!
>
> Nein. Das war und ist nicht meine Aussage. Eher im Gegenteil habe ich
> schon mehrfach geschrieben, daß Programme selbstverständlich auch
> Programme ausführen können.

Nein, deine Aussage war, dass ein Python-Script kein Programm ist, weil
es ohne Interpreter nicht ausführbar ist.

Daher gilt logischerweise, das *alles* was ohne Interpreter nicht
ausführbar ist, kein Programm ist. Wieso sollte das denn nur für Python
gelten?

[...]

>> ALLES(!) braucht einen Interpreter!
>
> Aber nicht alle *ist* ein Interpreter.

Das war auch gar nicht das Thema! Lenke nicht wieder ab!

Es geht darum, dass es deiner Logik nach keine Programme geben kann,
weil nichts ohne Interpreter ausführbar ist.

[Arno Welzel]

Lars Gebauer, 2022-08-24 15:14:

> Am 23.08.2022 um 22:25 schrieb Arno Welzel:
>> Lars Gebauer, 2022-08-23 16:34:
>>> Am 23.08.2022 um 16:09 schrieb Arno Welzel:
>> [...]
>>>> Ja und? Das passiert mit JEDEM(!) Programm so! Du merkst das nur nicht.
>>>
>>> Richtig! Mit jedem *Programm*!
>>>
>>> Nicht aber mit einem Daten-File. Da passiert ohne Programm
>>> (=Interpreter) gar nichts.
>>
>> Das gilt aber IMMER.
>
> Dennoch sind nicht alle Daten auch Interpreter. Manche sind einfach nur
> Daten(-Files).

Es hat auch niemand behauptet, dass alle Daten Interpreter oder
Programme wären.

[Arno Welzel]

Laurenz Trossel, 2022-08-24 10:45:

Falsch - es wurde eine *Sicherheitslücke* ausgenutzt. Der übliche
Einstiegspunkt: irgendeine Bildanzeiger hat einen Fehler, der dazu
führt, dass Code ausgeführt wird, weil eine Pufferüberlauf nicht
abgefangen wird.

[Arno Welzel]

Laurenz Trossel, 2022-08-24 13:02:

Postscript ist kein "Bild", sondern eine Scriptsprache.

[Arno Welzel]

Lars Gebauer, 2022-08-24 14:58:

> Am 23.08.2022 um 22:19 schrieb Arno Welzel:
>> Lars Gebauer, 2022-08-23 16:30:
>>> Am 23.08.2022 um 16:10 schrieb Arno Welzel:
>>>> Lars Gebauer, 2022-08-22 19:15:
>>>>> Am 22.08.2022 um 17:42 schrieb Arno Welzel:
>>>>>> Welche Programme interpretieren Bilddateien so, dass sie sich dann
>>>>>> genaus verhalten wie Scripte in einer Programmiersprache inkl.
>>>>>> Variablen, Sprüngen, Bedingungen, Schleifen etc.?
>>>>>
>>>>> Im Zweifel immer die, die $morgen geschrieben werden.
>>>>
>>>> Lenke nicht ab. Beweise deine Behauptung.
>>>
>>> Was gibt es da zu beweisen? Willst Du ernsthaft behaupten, daß es
>>> unmöglich ist, daß es ein solches Programm gibt? Oder doch wenigstens
>>> geben könnte?
>>
>> Deine Aussage war, dass Bilder auch als Programme interpretiert werden
>> können.
>
> Nein, das war und ist *nicht* meine Aussage. Noch nie.

Aberr sicher! Das Zitat steht ja da oben sogar noch:

Meine Frage:

"Welche Programme interpretieren Bilddateien so, dass sie sich dann
genaus verhalten wie Scripte in einer Programmiersprache inkl.
Variablen, Sprüngen, Bedingungen, Schleifen etc.?"

Deine Antwort:

"Im Zweifel immer die, die $morgen geschrieben werden."

>> Dann zeige ein Beispiel dafür.
>
> Du denkst Dir Blödsinn aus und ich soll ein Beispiel dafür zeigen?

Den Blödsinn hast Du Dir ausgedacht. Siehe oben.