Beiträge von Welm

    eines meine Linuxschäfchen hat sich einen CanoScan LiDe 300 für sein heimbüro geholt. Der Verkäufer sagte er wäre Linux "tauglich". Leider bekomme ich ihn unter leap15.1 nicht zum laufen


    lsub sagt aber
    Bus 002 Device 005: ID 04a9:1913 Canon, Inc.

    Sollte lt. SANE: Supported Devices voll unterstützt sein. Mit dem Pixma-Treiber aus sane-backends. Yast->Hardware->Scanner bietet bei mir (15.1 mit Canon 9000F/Pixma) verwirrenderweise außer dem Pixma auch noch einen "Nicht konfiguriert/CanoScan" für dasselbe Gerät an: der ist es nicht -- der pixma ist der richtige.


    Ich benutze "xsane" und "gimp" (der im Endeffekt dann auch xsane benutzt).

    Eigentlich wollte ich einfach mein Home-Verzeichnis verschlüsseln, habe in einem ToDo-Video hierzu aber mitbekommen, wie leicht sich das root Passwort eines unverschlüsselten Systems zurücksetzten lässt.
    So dann die Idee der kompletten Verschlüsselung.
    Gibt es hierzu denn eine Möglichkeit, die Ihr als einfach und vernünftig beschreiben würdet?


    Der Austausch des root-PW liefert dem Angreifer ja keinen Zugang zum verschlüsselten Home. Bei der Geschichte geht es also nicht um verlorene Laptops oder Diebe. Da geht es um einen ganz direkten Angriff bei dem jemand Deinen Laptop heimlich manipuliert, um so später Deine PW-Eingaben auszuforschen. Wenn man das per Komplettverschlüsselung verhindert, dann baut der Angreifer statt dessen etwas Zusatzelektronik in Deine Tastatur ein...


    Die Frage ist immer, gegen welche Art von Risiken man sich wehren will.


    Ich suche z.B. nur nach Sicherheit gegen Liegenlassen und Klauen meines Laptops. Daher hab ich Home verschlüsselt und eingestellt, dass beim Zuklappen etc. die Kiste runtergefahren wird statt nur einzuschlafen.

    Das Trivial File Transfer Protocol (TFTP) ist ein sehr einfaches Dateiübertragungsprotokoll. ...

    Ja. Wenn man übers Netz bootet, muss man vor dem Start des Betriebssystems ein paar Dateien empfangen und die dann starten. Deshalb wurde vor langer Zeit TFTP erfunden. Es ist fast nie sinnvoll, TFTP für was anderes zu benutzen.

    Da kannst du die emails aber auch ohne html lesen........

    Ja, ich kann es so oder so lesen. Aber dass bei einer "multipart/alternative"-Mail der "text/plain"-Teil so garnichts vom Inhalt hat, finde ich ärgerlich. Was sollen Leute, die sich mit E-Mails nicht auskennen, denken, wenn sie sowas sehen?


    Code
    common201711
    email_validation_error_html.ftl
    email_validation_error_subject.ftl
    email_validation_error_text.ftl
    .
    .
    .
    selfreg_validation_code_html.ftl
    selfreg_validation_code_subject_firstdraft.ftl
    selfreg_validation_code_subject.ftl

    Bugreport?


    Ich hab erstmal probiert, ob alles mit dem anderen Repo geht: Geht.


    Dann habe ich mir für den Bugreport einen Account geholt ... und sah zwischendurch kurz ein "sending request to facebook...". Hä? Als dann noch eine E-Mail kam in der offensichtlich davon ausgegangen wurde, dass alle Empfänger immer nur die html-Fassung einer Mail lesen, war es zuviel. Falls ich einen Menüpunkt finde um mich da wieder abzumelden, werde ich ihn nutzen.



    Tut mir leid ... aber von mir gibt es unter diesen Umständen keinen Bugreport.

    Es sieht so aus, als wäre emacs 25.3 (Leap 15.1 und 15.2) nicht mehr voll brauchbar.
    Im Paket steckt ein abgelaufener Schlüssel:

    Code
    gpg /usr/share/emacs/25.3/etc/package-keyring.gpg
    gpg: WARNING:  Kein Kommando angegeben.  Versuche zu raten was gemeint ist ...
    pub   dsa2048 2014-09-24 [SC] [verfallen: 2019-09-23]
          CA442C00F91774F17F59D9B0474F05837FBDEF9B
    uid           GNU ELPA Signing Agent <elpasign@elpa.gnu.org>



    Benötigt würde aber der Schlüssel:


    Code
    gpg --list-keys 066DAFCB81E42C40
    pub   rsa3072 2019-04-23 [SC] [verfällt: 2024-04-21]
          C433554766D3DDC64221BFAA066DAFCB81E42C40
    uid        [ unbekannt ] GNU ELPA Signing Agent (2019) <elpasign@elpa.gnu.org>

    für das Nachladen von ELPA-Paketen. Beim Aufruf von "Options"->"Manage Emacs Packages" kommt daher die Fehlermeldung:





    Code
    Failed to verify signature archive-contents.sig:
    No public key for 066DAFCB81E42C40 created at 2020-01-29T11:05:03+0100 using RSA
    Command output:
    gpg: Signatur vom Mi 29 Jan 2020 11:05:03 CET
    gpg:                mittels RSA-Schlüssel C433554766D3DDC64221BFAA066DAFCB81E42C40
    gpg: Signatur kann nicht geprüft werden: Kein öffentlicher Schlüssel


    Ich werde wohl mal aufs "editors"-Repo umsteigen.

    Du hattest ja geschrieben, dass es auf den Eintrag nur ankommt, wenn die Eintragung in der Kodierung des Absenders falsch sei.

    Nicht so ganz. Wenn man da eine Kodierung einträgt, dann wird die genommen. Auch wenn in der Mail die richtige Kodierung steht.

    Deshalb habe ich das inzwischen wieder auf "Automatisch" zurückgestellt. Wenn in der Absender-Mail die Kodierung eingetragen ist, dann müsste KMail das also so auslesen können. Tut es allerdings nicht, was dafür spricht, dass bei der Programmierung Mal wieder der Wurm drin ist.

    Oder: Die Angabe in der Mail ist falsch und die ausprobierten Werte auch. Da müsste man mal in die Bytes der Umlaute der Originalmail reinsehen, um die Kodierung raten zu können. Ich kenne mich mit K-Mail aber nicht aus und muss daher ab hier passen :(

    Die Mails, die hier falsch dargestellt sind, sind mit iso-8859-1 kodiert.


    Versteh ich das richtig? Wenn KMail auf iso-8859-1 steht, kann man alles lesen und wenn es auf "Originalkodierung befolgen" steht, dann sieht es kaputt aus?



    Dann wäre die nächste Frage: Was schreibt das Absendeprogram für einen Quatsch in die Mail? Es gibt in der Mail einen Header "Content-Type:" in dem in diesem Fall eigentlich "charset=ISO-8859-1" stehen müsste. (KMail ist bei mir lange her. Ich hab keine Ahnung, wie man da an die Header der Mail kommt)



    Ach ja: auch wenn die Mail mit ISO-8859-1 gut lesbar ist, könnte sie auch in ISO-8859-15 oder Microsoft CP1252 verfasst sein. Wenn "äöüß" ok sind aber das Eurozeichen kaputt, dann ist es einer von denen.