Moin,
Ich weiß, ich bin off topic, aber ich weiß, es gibt hier mind. 4 Leute, die mir evntl. helfen könnten.
1. DBTS #130680. Der Bug ist nicht reproduzierbar und man bräuchte mehr Infos vom Submitter, aber die Adresse ist tot. Eine Suche in google nach ihm förderte auch nicht mehr zu Tage. Wie geht man in dem Fall vor? 2. DBTS #198312. Ist die severity grave gerechtfertigt, weil bei grave steht in den developer documents:
grave makes the package in question unusable or mostly so, or causes data loss, or introduces a security hole allowing access to the accounts of users who use the package.
was nicht erfüllt ist, AFAICS. Den Tag security versteh ich auch nicht so richtig. Wenn ein server mit segfault abschmiert ist das gerechtfertigt, aber beim TeX-Compiler?
Danke für Hinweise, Hilmar
Am 04. Juli 2003 schrieb Hilmar Preusse:
- DBTS #130680. Der Bug ist nicht reproduzierbar und man bräuchte mehr Infos vom Submitter, aber die Adresse ist tot. Eine Suche in google nach ihm förderte auch nicht mehr zu Tage. Wie geht man in dem Fall vor?
Normalerweise
bts tags 130680 + unreproducible
In diesem Fall ist der Report so sinnlos, dass ich ihn mit einer Mail an 130680-done@bugs.debian.org und den obigen Begründungen schließen würde.
- DBTS #198312. Ist die severity grave gerechtfertigt, weil bei grave steht in den developer documents:
grave makes the package in question unusable or mostly so, or causes data loss, or introduces a security hole allowing access to the accounts of users who use the package.
was nicht erfüllt ist, AFAICS. Den Tag security versteh ich auch nicht so richtig. Wenn ein server mit segfault abschmiert ist das gerechtfertigt, aber beim TeX-Compiler?
Naja, dass ist ein Grenzfall. Mit der Argumentation des Bug-Reporters müsste man auch das Programm rm als sicherheitskritisch einstufen, weil ein blöder Benutzer versehentlich 'rm -rf ~' eingeben kann. Scheinbar ist das Problem in unstable gelöst, dann kann man den Bug schließen oder bis zur sarge-Release die severity auf 'fixed' setzen.
Torsten
Hallo Hilmar, Torsten und Liste,
Am 2003-07-05 11:10 +0200 schrieb Torsten Werner:
In diesem Fall ist der Report so sinnlos, dass ich ihn mit einer Mail an 130680-done@bugs.debian.org und den obigen Begründungen schließen würde.
Full ACK. AFAICS bist Du ja einer der Maintainer, also zu damit.
- DBTS #198312. Ist die severity grave gerechtfertigt, weil bei grave steht in den developer documents:
grave makes the package in question unusable or mostly so, or causes data loss, or introduces a security hole allowing access to the accounts of users who use the package.
was nicht erfüllt ist, AFAICS. Den Tag security versteh ich auch nicht so richtig. Wenn ein server mit segfault abschmiert ist das gerechtfertigt, aber beim TeX-Compiler?
IMHO ist weder grave noch security gerechtfertigt. Da solche ungültigen Dateinamen im Normalbetrieb nicht vorkommen, ist es kein Bug, der im Normalbetrieb(!) stört. Daher ist minor oder normal angemessen. Bei Serverprozessen wäre important und security okay, aber von einem tetex-server habe ich noch nie gehört.
Naja, dass ist ein Grenzfall. Mit der Argumentation des Bug-Reporters müsste man auch das Programm rm als sicherheitskritisch einstufen, weil ein blöder Benutzer versehentlich 'rm -rf ~' eingeben kann.
Das ist IMHO aber kein guter Vergleich. rm -rf ~ ist "you asked for it, you got it" und rm schmiert dabei nicht ab (wenn ja, dann bug report). latex tut es aber, und Abschmieren steht sicherlich nicht in der Spezifikation.
Scheinbar ist das Problem in unstable gelöst, dann kann man den Bug schließen oder bis zur sarge-Release die severity auf 'fixed' setzen.
Soweit ich das auf dem PTS sehen kann, hat tetex keine Probleme mit der Migration nach testing. Bei meinen eigenen Paketen schließe ich Bug reports, sobald die unstable-Version sie nicht mehr hat, weil mit bugs, die im Changelog geschlossen werden, ja auch so verfahren wird. Ansonsten blickt ja kein Schwein mehr durch ;-)
Schönen Abend!
Pitti
Am 06. Juli 2003 schrieb Martin Pitt:
Bei Serverprozessen wäre important und security okay, aber von einem tetex-server habe ich noch nie gehört.
Die Deutsche Bahn benutzt beispielsweise pdflatex auf ihrem Webserver. Daher ist die Argumentation des bug reporters nicht ganz von der Hand zu weisen.
Torsten
On 07.07.03 Torsten Werner (email@twerner42.de) wrote:
Am 06. Juli 2003 schrieb Martin Pitt:
Moin,
Bei Serverprozessen wäre important und security okay, aber von einem tetex-server habe ich noch nie gehört.
Die Deutsche Bahn benutzt beispielsweise pdflatex auf ihrem Webserver. Daher ist die Argumentation des bug reporters nicht ganz von der Hand zu weisen.
Korrekt, aber das ist kein Server, gegen den man eine DoS-Attacke fahren kann und der dann stirbt. Die Skripte, die dort den TeX-Input generieren, sorgen sicher von alleine dafür, daß die Input-Files passend kurze Namen haben.
H.
On 05.07.03 Torsten Werner (email@twerner42.de) wrote:
Am 04. Juli 2003 schrieb Hilmar Preusse:
Moin,
DBTS #198312. Ist die severity grave gerechtfertigt, weil bei grave steht in den developer documents:
was nicht erfüllt ist, AFAICS. Den Tag security versteh ich auch nicht so richtig. Wenn ein server mit segfault abschmiert ist das gerechtfertigt, aber beim TeX-Compiler?
Scheinbar ist das Problem in unstable gelöst, dann kann man den Bug schließen oder bis zur sarge-Release die severity auf 'fixed' setzen.
drachi:[t1] >./tex `perl -e 'print "ffffffffffffffff"x8086'` This is TeXk, Version 3.14159 (Web2C 7.4.5) %&-line parsing enabled. Segmentation fault
Nicht so wirklich. Ob das wirklich ein Bug im teTeX, oder woanders ist, weiß ich trotzdem nicht so genau. Ich werd die Severity auf normal setzen und den Bug auf den Upstream schieben. Hint an Martin: Ich bin kein offizieller Maintainer, sondern lediglich auf debian-tetex-maint eingeschrieben.
Thanks to all, H.
Am 07. Juli 2003 schrieb Hilmar Preusse:
Korrekt, aber das ist kein Server, gegen den man eine DoS-Attacke fahren kann und der dann stirbt. Die Skripte, die dort den TeX-Input generieren, sorgen sicher von alleine dafür, daß die Input-Files passend kurze Namen haben.
Bist du dir da sicher? Bei einer künftigen Änderung (bei der Bahn zur Zeit sehr beliebt) kann man diese Einschränkung mal übersehen bzw. vielleicht kennt sie der Programmierer gar nicht? Das auszunutzen dürfte trotzdem verdammt schwer werden.
Am 07. Juli 2003 schrieb Hilmar Preusse:
drachi:[t1] >./tex `perl -e 'print "ffffffffffffffff"x8086'` This is TeXk, Version 3.14159 (Web2C 7.4.5) %&-line parsing enabled. Segmentation fault
Nicht so wirklich.
Der Bug-Report hat aber den tag woody, das wäre dann falsch.
Torsten
On 07.07.03 Torsten Werner (email@twerner42.de) wrote:
Am 07. Juli 2003 schrieb Hilmar Preusse:
Moin,
Korrekt, aber das ist kein Server, gegen den man eine DoS-Attacke fahren kann und der dann stirbt. Die Skripte, die dort den TeX-Input generieren, sorgen sicher von alleine dafür, daß die Input-Files passend kurze Namen haben.
Bist du dir da sicher? Bei einer künftigen Änderung (bei der Bahn zur Zeit sehr beliebt) kann man diese Einschränkung mal übersehen bzw. vielleicht kennt sie der Programmierer gar nicht? Das auszunutzen dürfte trotzdem verdammt schwer werden.
Ich diskutier jetzt mit Dir, wie mit dem Submitter: Der Typ will LaTeX auf ein File aufrufen, was aufgrund der begrenzten Dateinamenlänge unter Linux gar nicht existieren kann und beschwert sich dann, daß TeX segfaultet. Ich weiß jetzt nicht, wie die Technik, die HAFAS da hingestellt hat, funktioniert. Nur zwei Cases: 1. LaTeX liest von stdin -> ich brauche kein TeX-File. 2. LaTeX liest aus File -> in dem Augenblick muß das File existieren können und da schon für woody gilt:
drachi:[hille] >tex `perl -e 'print "f"x500'` This is TeX, Version 3.14159 (Web2C 7.3.7) ! I can't find file `fff<snip>fff'. <*> ...fffffffffffffffffffffffffffffffffffffffffff
Please type another input file name: x (/usr/share/texmf/tex/latex/tools/x.tex drachi:[hille] >touch `perl -e 'print "f"x500'` touch: creating `fff<snip>fff': File name too long drachi:[hille] >
sehe ich das Problem nicht.
Am 07. Juli 2003 schrieb Hilmar Preusse:
drachi:[t1] >./tex `perl -e 'print "ffffffffffffffff"x8086'` This is TeXk, Version 3.14159 (Web2C 7.4.5) %&-line parsing enabled. Segmentation fault
Nicht so wirklich.
Der Bug-Report hat aber den tag woody, das wäre dann falsch.
Gut, ich habe nicht gut genug getestet. Ich habe keine unstable, sondern ein tetex-bin, was auf stable compiliert wurde und lauffähig ist. Der Unterschied zwischen mir und unstable ist also entweder die libkpathsea oder die glibc. Im ersteren Fall wäre alles korrekt, im zweiteren Fall ein glibc-Bug oder aber der Tag woody ist Unfug. Hat jemand ein unstable-System und kann das Mal kurz testen?
H.
Am 07. Juli 2003 schrieb Hilmar Preusse:
drachi:[hille] >touch `perl -e 'print "f"x500'` touch: creating `fff<snip>fff': File name too long
Das ist kein Argument, denn u. U. kann man den Server dazu bringen eine Verzeichnisstruktur der Art
perl -e 'print "f/"x500'
anzulegen, an der dann tex trotzdem stirbt.
Gut, ich habe nicht gut genug getestet.
Ich habe es gerade probiert und ein tex aus unstable stürzt nicht ab.
Torsten
On 07.07.03 Torsten Werner (email@twerner42.de) wrote:
Am 07. Juli 2003 schrieb Hilmar Preusse:
Moin,
drachi:[hille] >touch `perl -e 'print "f"x500'` touch: creating `fff<snip>fff': File name too long
Das ist kein Argument, denn u. U. kann man den Server dazu bringen eine Verzeichnisstruktur der Art
perl -e 'print "f/"x500'
anzulegen, an der dann tex trotzdem stirbt.
Hmmpppf. Ja, klar hast recht.
Gut, ich habe nicht gut genug getestet.
Ich habe es gerade probiert und ein tex aus unstable stürzt nicht ab.
Gut. Dann hat alles, bis auf die Severity, seine Richtigkeit. Ich fürchte, ich werde noch einen help-Tag ranpappen.
H.
lug-dd@mailman.schlittermann.de
-
Hilmar Preusse -
Martin Pitt -
Torsten Werner