Veni, Vidi, VISA

Ist eigentlich ganz einfach

if [[ "$TMUX" == "" ]] &&

        [[ "$SSH_CONNECTION" != "" ]]; then

    WHOAMI=$(whoami)

    if tmux has-session -t $WHOAMI 2>/dev/null; then

    tmux -2 attach-session -t $WHOAMI

    else

        tmux -2 new-session -s $WHOAMI

    fi

fi

in die ~/.zshrc (oder zur Shell passende Datei schreiben) und fertig. Und da Tmux scriptbar ist, kann man auch automatisch die Statuszeile ändern, damit man bei verschachtelten Sessions nicht durcheinander kommt.

Ergänzung der Regelungen zur Quellen-TKÜ und zur Online-Durchsuchung um ein Betretungsrecht
[..]
Sie sind der Auffassung, dass die derzeit zulässigen Möglichkeiten zur Aufbringung der Software auf dem informationstechnischen System des Betroffenen mit erheblichen rechtlichen und tatsächlichen Problemen behaftet sind.
[...]

Quelle: http://www.jm.nrw.de/JM/jumiko/beschluesse/2018/Fruehjahrskonferenz_2018/II-8-RP---Ergaenzung-der-Regelungen-zur-Quellen-TKUe-und-zur-Online-Durchsuchung-um-ein-Betretungsrecht.pdf

Kurz: Es geht um den Bundestrojaner. Die Polizei will in Wohnungen eindringen dürfen, um dort Spähsoftware auf dem Rechner installieren zu dürfen.

Ich schreibe meine Dokumentationen schon seit gut einem Jahrzehnt (2005 um genau zu sein.. scheisse.. ich werde alt) mit AsciiDoc, aber da scheint die Entwicklung stehengeblieben zu sein (8.6.9 ist von2013) und zudem kam ich da immer wieder an die Grenzen. Nichts desto trotz hat es hervorragend funktioniert und seinen Zweck erfüllt, aber seit geraumer Zeit verwende ich jetzt Asciidoctor. Das ist - grob gesagt - ein aufgepepptes AsciiDoc. Installiert ist es relativ einfach; dazu einfach unter https://asciidoctor.org/ unter Installation nachlesen und sich daran halten.
Eins der Features von Asciidoctor ist das erstellen von Flowcharts. Dazu erstellt man einfach ein Dokument mit folgendem Inhalt:

= Nur ein kleiner Test



[ditaa]

----

+-------------+

| AsciiDoctor |-------+

|   diagram   |       |

+-------------+       | PNG out

    ^                 |

    | ditaa in        |

    |                 v

+--------+   +--------+----+    /---------------\

|        |---+ Asciidoctor +--->|               |

|  Text  |   +-------------+    |   Beautiful   |

|Document|   |   !magic!   |    |    Output     |

|     {d}|   |             |    |               |

+---+----+   +-------------+    \---------------/

    :                                   ^

    |          Lots of work             |

    +-----------------------------------+

----

Das speichert man ab und ruft dann asciidoctor -r asciidoctor-diagram dateiname auf; das erstellt dann eine HTML-Datei inkl. PNG. Wer das ganze als PDF haben will, kann einfach ein asciidoctor-pdf -r asciidoctor-diagram dateiname verwenden. Wenn man dazu noch Vim etwas anpasst, wird das ganze noch komfortabler:

autocmd BufNewFile,BufRead *.adoc

        \ setlocal autoindent expandtab tabstop=8 softtabstop=2 shiftwidth=2

        \ | setlocal tabstop=8 softtabstop=2 shiftwidth=2 filetype=asciidoc

        \ | set textwidth=70 wrap formatoptions=tcqn 

        \ | set formatlistpat=^\\s*\\d\\+\\.\\s\\+\\\\|^\\s*<\\d\\+>\\s\\+\\\\|^\\s*[a-zA-Z.]\\.\\s\\+\\\\|^\\s*[ivxIVX]\\+\\.\\s\\+

        \ | set comments=s1:/*,ex:*/,://,b:#,:%,:XCOMM,fb:-,fb:*,fb:+,fb:.,fb:>

        \ | nnoremap Q gq}

        \ | set ft=asciidoc

        \ | source ~/.vim/macros/abbreviations.vim

        \ | nmap <F4> :make<CR>

        \ | nmap <F3> :w<CR>

        \ | inoremap <F4> <ESC>:make<CR><CR>a

        \ | set makeprg=asciidoctor\ -r\ asciidoctor-diagram\ %

Ich wurde per Mail gefragt wie ich Sonderzeichen auf einer Tastatur mit US-Layout und ohne Sonderzeichen eingebe und das ist relativ einfach. Zuerst erstellt man folgende Datei:

default partial 

xkb_symbols "basic" {

    key <AE01> {  [  1,   exclam      , dead_grave             ] };

    key <AE02> {  [  2,   at          , dead_circumflex        ] };

    key <AE03> {  [  3,   numbersign  , dead_acute             ] };

    key <AE04> {  [  4,   dollar      , dead_diaeresis         ] };

    key <AE05> {  [  5,   percent     , dead_cedilla           ] };

    key <AE06> {  [  6,   asciicircum , dead_caron             ] };

    key <AE07> {  [  7,   ampersand   , section                ] };

    key <AD03> {  [  e,   E           , EuroSign               ] };

    key <AD07> {  [  u,   U           , udiaeresis, Udiaeresis ] };

    key <AD09> {  [  o,   O           , odiaeresis, Odiaeresis ] };

    key <AC01> {  [  a,   A           , adiaeresis, Adiaeresis ] };

    key <AC02> {  [  s,   S           , ssharp                 ] };

    key <AB03> {  [  c,   C           , ccedilla               ] };

    key <AB01> {  [  z,   Z           , guillemotleft          ] };

    key <AB02> {  [  x,   X           , guillemotright         ] };

};

und speichert sie als us_de_diff in symbols Verzeichnis von setxkbmap(1) ab. Unter OpenBSD ist das /usr/X11R6/share/X11/xkb/symbols und unter Linux /usr/share/X11/xkb/symbols. Anschließend erstellt man im gleichen Verzeichnis eine Datei Namens us_de mit folgendem Inhalt:

partial default alphanumeric_keys

xkb_symbols "basic" {

    include "us"

    include "us_de_diff"

    name[Group1]="en_US";

    key <RALT>  { type[Group1]="TWO_LEVEL",

                  [ ISO_Level3_Shift, Multi_key ]   };

    modifier_map Mod5   { <RALT> };

};

xkb_symbols "nodeadkeys" {

    include "pc/en_US(basic)"

    include "pc/latin(nodeadkeys)"

    include "us_de_diff"

};

Wenn das geschehen ist, aktiviert man das Layout noch mit setxkbmap -layout us_de und kann dann mit Alt+a ein "ä" erzeugen, mit Alt+o ein "ö" usw.

Die Anleitung ist nicht von mir, sondern die habe ich vor Jahren mal irgendwo gelesen und dann abgespeichert. Sollte jemand den Urheber bzw. einen Link dazu haben, kann er ihn mir gerne mitteilen.

Weil mich schon einige Mails erreicht haben, wo ich danach gefragt wurde:

# lighttd.conf

     url.rewrite = (

            "^/lib/.*$"              => "$0",

            "^/_media/(.*)?\?(.*)$"  => "/lib/exe/fetch.php?media=$1&$2",

            "^/_media/(.*)$"         => "/lib/exe/fetch.php?media=$1",

            "^/_detail/(.*)?\?(.*)$" => "/lib/exe/detail.php?media=$1&2",

            "^/_detail/(.*)?$"       => "/lib/exe/detail.php?media=$1",

            "^/_export/([^/]+)/(.*)\?(.*)$" => "/doku.php?do=export_$1&id=$2&$3",

            "^/_export/([^/]+)/(.*)" => "/doku.php?do=export_$1&id=$2",

            "^/doku.php.*"           => "$0",

            "^/feed.php.*"           => "$0",

            "^/(.*)\?(.*)"           => "/doku.php?id=$1&$2",

            "^/(.*)"                 => "/doku.php?id=$1"

	    )

	    }

# nginx.conf

location @dokuwiki {

    rewrite ^/_media/(.*) /lib/exe/fetch.php?media=$1 last;

    rewrite ^/_detail/(.*) /lib/exe/detail.php?media=$1 last;

    rewrite ^/_export/([^/]+)/(.*) /doku.php?do=export_$1&id=$2 last;

    rewrite ^/(?!lib/)(.*) /doku.php?id=$1&$args last;

}

Guckst Du: https://www.vim.org/vim-8.1-released.php. Ich hab es nur kurz überflogen, aber termdebug sieht ganz brauchbar aus; wie es genau funktioniert kann man unter :h terminal-debug nachlesen. Den kompletten ChangeLog gibt es unter https://raw.githubusercontent.com/vim/vim/master/runtime/doc/version8.txt oder mit :h version8.1. Und Ja. Ich habe vor vor neun Jahren schon geschrieben das der ChangeLog von (u. a.) Vim saugt, aber auf mich hört ja keiner.

Der Ubuntu Snap Store hat Snaps angeboten, die Malware enthielten, um per Crypto-Mining Hardware-Ressourcen der Anwender zur Erstellung von ByteCoin abzuzweigen.

Im Ubuntu Snap Store kursierten seit Ende April verschiedene Snaps, die eine Malware enthielten, um die Crypto-Währung ByteCoin zu erstellen. Mindestens zwei der Pakete eines Users, der mehrere Snaps unter dem Namen Nicolas Tomb hochgeladen hatte, enthielten die Crypto-Mining-Malware, die als Systemd-Daemon getarnt war. Canonical hat die Snaps dieses Users mittlerweile entfernt und eine Untersuchung eingeleitet.
Es ist nicht bekannt, wie oft die Snaps heruntergeladen wurden, da der Snap Store keinen öffentlichen Zähler aufweist. Zudem waren die Snaps auch über die Applikation Gnome-Software zu beziehen, die neben Ubuntu auch von anderen Distributionen verwendet wird. Bei den beiden identifizierten Snaps handelt es sich um die Spiele »2048buntu« und »Hextris«. Tomb hatte teilweise proprietäre Lizenzen verwendet, um sich so vor Entdeckung zu schützen. So war das Snap zu 2048buntu, einem Clone des Spiels »2048«, mit einer solchen Lizenz versehen. Das Originalspiel unterliegt einer MIT-Lizenz, die es erlaubt, die Software frei oder proprietär zu verteilen. Vor drei Tagen fragte der Entdecker der Malware auf der GitHub-Instanz von Snapcraft an, wo er die Malware melden solle.

Jedermann kann in den Snap Store Pakete hochladen, sofern sie technisch funktionieren. Das stellt ein automatischer Test sicher, der derzeit die einzige Zugangsbarriere des Ubuntu Snap Store darstellt. Selbst eine weitere Überprüfung der Apps wäre wegen der proprietären Lizenz nicht in der Lage gewesen, die Malware zu erkennen.

Im Flatpak-Store FlatHub wird jedes Paket einer manuellen Durchsicht unterzogen, ob die App Requirements erfüllt werden. Auch FlatHub erlaubt proprietäre Lizenzen, um Anwendungen wie etwa Steam oder Spotify als Flatpak zu ermöglichen. Auch hier kann laut aussage eines Entwicklers in solchen Fällen keine absolute Sicherheit gewährleistet werden. Jedoch ist Flatpak eher auf Upstream-Pakete ausgelegt, deren Quellen man vertraut, als auf Pakete Dritter. Alle FlatHub-Pakete werden zudem auf vertrauenswürdigen Build-Servern gebaut.

Quelle: https://www.pro-linux.de/news/1/25887/ubuntu-snap-store-enthielt-malware.html

Von früh bis spät nur Qualität. Und - für bei Linux und Co. mittlerweile schon fast selbstverständlich - kein einziger Hinweis auf snapcraft, because "Not only are snaps kept separate, their data is kept separate too. Snaps communicate with each other only in ways that you approve.".

Kann jetzt endlich mal jemand einen anständigen Fork von Linux rausbringen und so Abfallhalden wie Ubuntu, open Suse und wie die ganzen anderen "Du bist zu faul um Dokumentationen zu lesen und sowieso zu dumm um sie zu verstehen? Kein Problem! Wir haben da genau das richtige für Dich!" - Distributionen heißen entsorgen?

Nein. Nicht heute oder morgen, sondern demnächst mal werde ich auf DokuWiki umsteigen. Das erste mal hab ich es Anfang 2007 auf meiner Homepage installiert und dann wieder durch statische Seiten ersetzt weil... öhm. Ja. Weil halt. Damals war es Release 2006-11-06. Ich habe es dann auch auf meiner Firmenseite (damals als Freiberuflicher IT-Consulant) genutzt und wurde von mehreren Kunden darauf angesprochen und sollte/musste/durfte es dann in diversen Firmen/Rechenzentren als CMS installieren. Vor ein paar Tagen habe ich es just for fun auf meinem lokalem Server installiert und angefangen es mit Inhalt zu füllen. Jetzt sind alle Texte - mit Ausnahme dieses Blogs - auf dem lokalem Wiki gespeichert und werden irgendwann mal die statische Seite ersetzen. Was jetzt noch fehlt ist Feintuning: Tabellen formatieren, Sidebars bzw. Navigationsleisten erstellen, Design anpassen und das ganze halbwegs brauchbar strukturieren.
Probleme tragen bisher kaum welche auf wenn man mal von PEBCAK absieht. Das Blog werde ich aber nicht auf DokuWiki übertragen; zum einen weil es ein extremer Arbeitsaufwand wäre und zum anderen bin ich mit S9Y aka Serendipity sehr zufrieden.

Zwei Sicherheitslücken und einige Regressionen wurden jetzt im Debian-Kernel gepatched. Beide waren der Kategorie »high« zugeordnet.

Das Debian Security Advisory 4196-1 bezieht sich auf zwei Sicherheitslücken mit den CVE-Nummern CVE-2018-1087 und CVE-2018-8897, die jetzt im Debian-Kernel gepatched wurden. CVE-2018-1087 war von Kernel-Entwickler Andy Lutomirski entdeckt worden. Die Lücke in der Kernel-based Virtual Machine (KVM)ermöglichte es einfachen KVM-Anwendern, ihre Privilegien auszuweiten oder das Gastsystem zum Absturz zu bringen.

Die zweite Lücke, CVE-2018-8897, entdeckte Nick Peterson von der Firma Everdox Tech LLC. Sie ermöglichte unprivilegierten Anwendern, Kernel-Abstürze durch eine Lücke herbeizuführen, die darin lag, wie der Kernel mit nach Mov-to-SS- oder Pop-to-SS-Instruktionen erlaubten Debug-Exceptions umgeht. Beide Lücken, wurden in ihrer Gefährlichkeit als »high« eingestuft.

Zudem wurden drei Regressionen beseitigt, die ein Kernel-Update letzte Woche in Debian GNU/Linux 8 »Jessie« eingeschleppt hatte. Dieses Update hatte weitere Patches gegen Spectre v1 gebracht und insgesamt 27 Sicherheitslücken geschlossen, einschließlich einer bereits seit acht Jahren vorhandenen Lücke in MMap.

Anwender von Debian GNU/Linux 9 »Stretch« und Debian GNU/Linux 8 »Jessie« sollten die Updates zeitnah einspielen, indem sie auf Kernel 4.9.88-1+deb9u1 respektive 3.16.56-1+deb8u1 aktualisieren. Updates, die auf einem Debian Security Advisory (DSA) beruhen, werden in Debian möglichst zeitnah gepatched und ausgeliefert. Diese Updates werden dann später zusammen mit bereinigten Fehlern kumulativ in einem Update der jeweils stabilen Veröffentlichung herausgegeben. Das letzte Update dieser Art war die Aktualisierung auf Debian 9.4. Ein Termin für Debian 9.5, das dann auch die gestern veröffentlichten Kernel-Updates umfasst, ist noch nicht bekannt.

Quelle: https://www.pro-linux.de/news/1/25878/sicherheitsl%C3%83%C2%BCcken-im-debian-kernel-geschlossen.html

Acht Jahre.. was nennt man da als Grund? Because fuck you, thats why! oder was? Tja.. was soll man dazu noch sagen? Vielleicht Leise Scheisse.., aber sonst fällt einem da nix mehr ein.

Nachdem mir der httpd(8) von OpenBSD auf die Eier gegangen ist, habe ich ihn gegen Lighttpd ausgetauscht, was auch problemlos funktioniert hat. Anschließend habe ich just for fun DokuWiki installiert und beim Aufruf von install.php It seems your data directory is not properly secured. zu sehen bekommen. chmod/chown waren korrekt gesetzt, also konnte es daran nicht liegen. Lag es auch nicht. Nach kurzer Recherche habe ich dann folgendes gefunden: https://www.dokuwiki.org/security#deny_directory_access_in_lighttpd und siehe da.. nach dem Eintrag von

$HTTP["url"] =~ "^/dokuwiki/(data|conf|bin|inc)/+.*" {

    url.access-deny = ("")

}

in der lighttpd.conf und einem anschließendem Neustart war das mit de Warnhinweis auch Geschichte.