Jan 25

Gaaaanz kurze knackige Anleitung, wie man einen PGP/GPG Key beglaubigt  bzw. signiert (unvollständig, und OHNE Anleitung, wie man den Key auf korrektheit prüft – idealerweise signiert Ihr nur Keys, bei denen Ihr 100%ig sicher seid, dass diese auch vom passenden Keyowner kommen 🙂 )

Shell:

[gpg –list-keys] Pub-Key-ID des zu signierenden keys merken

[gpg –sign-key <pubkeyid>] Das eigentliche Signieren

[gpg –send-keys <pubkeyid>] Signieren dem Keyserver bekanntmachen

OSX / GPGTools:

  • GPG Schlüsselbund (GPG Keychain) starten.
  • Rechte Maustaste auf den zu signierenden Key
  • Beglaubigen anclicken, Details entsprechend wählen und OK drücken
  • Wieder rechte Maustaste, diesesmal “Öffentlichen Schlüssel an Schlüsselserver senden”

Der letzte Punkt – also das Veröffentlichen der Beglaubigung, wird gern vergessen. Ohne diesen Schritt ist das ganze jedoch recht witzlos.

[UPDATE]

Bei mehreren uids (Identitäten) pro Key:

  • Doppelclick auf den Key in der Keychain-GUI
  • Wechsel auf den “Benutzer-ID”-Tab
  • Zu bestätigende Identität OBEN auswählen
  • Unten auf das Plus clicken und beglaubigen
  • Anschliessend wieder raus, und “Öffentlichen Schlüssel an Schlüsselserver senden” (s.o.)
Tagged with:
Jan 12

Ausnahmsweise mal keine (Über-)Lebenshilfe, sondern ein Hilferuf!

Da hier zwei Kids rumlaufen, hab ich gern die Kontrolle wann und wie das Netz benutzt wird. Bisher (zu v4-Zeiten) hat der Squid gute Dienste geleistet. Mit ipv6 ist das nicht mehr so. Da beisse ich mir nämlich die Zähne aus.

Doch von vorn: Hier im Netz läuft ein radvd (Router Advertising Daemon), der ein sixxs-Prefix im LAN Announced. Der (zwangs-)proxy biegt alle ausgehenden ipv4-Port-80 Anfragen transparent auf den Squid-Port um, und handlet den Kram dann per ACL. v4 gibt es statisch über einen DHCP, und für Gäste ist eine Range vergeben.

Seit v6 schnappen sich die Endgeräte irgendeine v6-Adresse (bei ios7 kann man ja bekanntlich die privacy-extensions nicht mehr ausschalten) und vorbei ist es mit der Kontrolle (vom DNS mal ganz abgesehen). Eine Lösung muss her. Bisher ausprobiert habe ich folgendes:

  • auth_param im Squid angeknipst. Resultat erschütternd:
    • Android und Proxys … Hahaha (wenn, nur “gerooted”) !!! Android und Proxy-Auth – HEUL! Tut überhaupt nicht.
    • ios und Proxys – Nett / ios und Proxy-Auth – Neee, da taktet ein Autoblinker stabiler. Geht nicht 🙁
    • OSX: Siehe ios.
  • acl based on arp (acl arp)
    • Bei v4 schick – bei v6 gibts Neighbourdiscovery und kein arp mehr. Dummerweise scheint noch niemand ND in irgendeiner Squid-Version als acl implementiert zu haben 🙁
  • ACLs auf V6-IP-Basis
    • Aufgrund der Privacy-Extensions unbenutzbar

Noch nicht ausprobiert (weil so demotiviert von den o.g. zwei Punkten – und tlw. auch zu aufwendig):

  • Getrennte “Netze” mit getrennten IPv6-Prefixen um die ACLs auf Netzebene auszurollen:
    • Aufwändig !! Trennbar nur über VLANs, extra SSIDs an jedem WLAN-AP … und überhaupt
  • DHCPv6
    • will man sowas?
  • RADIUS
    • Kanonen / Spatzen und so. Neee
  • 802.1X
    • Interessanter Ansatz. Aber da fliegen auch wieder die IOS-Devices raus. Ferner gilt das selbe wie bei radius.

Vorschläge sind mehr als willkommen. Derzeit hab ich auf der LAN-Seite des Proxies v6 wieder ausgeschaltet und arbeite mit den o.g. ARP-Filtern. Tut zumindest einigermassen. An so einem iphone lässt sich die macaddy nicht so einfach ändern. 

Tagged with:
Jan 12

TT-RSS an sich ist ja eine feine Sache. Das Ding hat allerdings ein/zwei Haken, wenn man es für mehrere Leute hosted. Ich nutze das hier mit dem Fever-Plugin, damit man die Feeds auch einigermassen elegant auf mobilen Endgeräten nutzen kann.

Meist ist es ja so, dass $user sich eine Feedliste zusammenstellt, und sich dann Wochenlang nicht mehr ins Frontend einloggt (Hab ich beim Google-Reader damals™ auch so gemacht). Das nimmt einem ttrss aber übel. Denn nach 30 Tagen (Einstellbar in der ./include/rssfuncs.php // Zeile 2) sagt sich ttrss: Nee, der User hat sich seit 30 Tagen nicht mehr eingeloggt, dann update ich halt nicht mehr. Pikanterweise zählt der Fever-Login nicht (Plugins verwalten Ihre Daten “irgendwie” anders – PHP-Magic halt).

Also merken: Wenn tt-rss nicht mehr updatet, entweder:

  • Zeile 2 der ./include/rssfuncs.php anpassen und hochdrehen (Halte ich für nicht so super)
  • Den/Die User/in anhalten, sich von Zeit zu Zeit mal ins Frontend einzuloggen
  • Oder (superschmutzig), per Hand das Feld last_login in der tabelle ttrss_users auf “NOW()” updaten.

 

Tagged with:
preload preload preload