In diesem Interview spricht Richard Seidl mit Miriam Sasse über den „Patienten Agilität“. Die beiden stellen sich die Frage, ob Agilität in Unternehmen wirklich am Ende ist oder ob sie nur dringend Hilfe braucht. Mit anschaulichen Metaphern aus der Notfallmedizin befragt Miriam Sasse typische Symptome: Warum fallen Unternehmen in Krisen zurück in alte Muster? Weshalb scheint Agilität oft nicht Teil der Unternehmenskultur zu sein? Gemeinsam beleuchten sie, wie gezielte Diagnose und dosierte Maßnahmen helfen können, Teams und Prozesse nachhaltig zu stärken.

„Bei vielen heißt es schon, oh geh‘ mir weg mit agil.“ – Miriam Sasse

Dr. Miriam Sasse ist promovierte Maschinenbauerin und zertifizierter Coach. Sie begleitet Organisationen bei agiler und digitaler Transformation, mit Fokus auf Deep-Tech-Teams und Game Design. Als TEDx-Speakerin und Autorin beschäftigt sie sich mit der Zukunft von Führung und Organisationsdesign. Sie lehrt an Hochschulen und leitet die Regionalgruppe der GPM OWL.

Softwarequalität im Gespräch

Dieses Format fokussiert sich auf Softwarequalität: Ob Testautomatisierung, Qualität in agilen Projekten, Testdaten oder Testteams – Richard Seidl und seine Gäste betrachten die Dinge, die die Qualität in der Softwareentwicklung steigern.

Die aktuelle Episode ist auch auf Richard Seidls Blog verfügbar.

(mai)

Lizenzfreier Sprechfunk kann im privaten wie im professionellen Umfeld eine große Hilfe sein, die Prozesse dank verbesserter Kommunikation enorm beschleunigt. Doch die Auswahl an Funkgeräten ist riesig. Das fängt beim Preis an: Günstige Geräte sind schon für deutlich unter 20 Euro pro Stück erhältlich, die Spitzenmodelle von Markenherstellern kosten leicht das Zehnfache und mehr.

Eine breite Spanne gibt es auch bei der Ausstattung: Auf der einen Seite findet man einfache Geräte mit wenigen Bedienelementen, auf der anderen Geräte mit vielen Knöpfen und einem Display.

Weiter variiert die technische Ausstattung: Zum seit vielen Jahrzehnten üblichen Analogfunk ist in den vergangenen Jahren der Digitalfunk hinzugetreten, hat die analoge Technik aber noch lange nicht verdrängt.

Das war die Leseprobe unseres heise-Plus-Artikels „Marktübersicht: Funkgeräte für jedermann“.
Mit einem heise-Plus-Abo können Sie den ganzen Artikel lesen.

Google wird Android-Apps erlauben, ein Dutzend well-known Ports (kleiner als 1024) zu nutzen. Das öffnet neue Einsatzmöglichkeiten für populäre Android-Geräte, insbesondere im lokalen Netzwerk. Konkret sollen mit dem nächsten Update des Google Play Systems Android-Apps bei Bedarf Zugriff auf diese neun TCP-Ports erhalten: 20 und 21 (typischerweise für FTP genutzt), 22 (SSH/SFTP), 23 (Telnet), 80 (HTTP), 443 (HTTPS), 445 (SMB), sowie die beiden regelmäßig für vernetzte Drucker eingesetzten Ports 515 (LPD) und 631 (IPP).

Hinzu kommen drei UDP-Ports: 319/320 (typischerweise für Zeitgeber-Synchronisierung mittels PTP) und 443 (für das QUIC-basierte WWW-Protokoll HTTP/3). Das geht aus einer am Wochenende veröffentlichten Mitteilung im öffentlichen Bugtracker Androids hervor. Kein Glück haben beispielsweise Nutzer von TFTP (UDP-Port 69) oder Doom-Fans (klassisch Port 666).

Bislang sperrt Google auf seinen Android-Versionen grundsätzlich Ports kleiner 1024. Nur wenn solche Android-Implementierungen gerootet sind, kann der Administrator die sogenannten well-known Ports zugänglich machen. Das schwächt unter Umständen bestimmte IT-Sicherheitsmaßnahmen.

Ein bisschen Glasnost

Daher regen Entwickler im Android Bugtracker seit vielen Jahren an, die Einschränkung fallen zu lassen. Doch Google hat das mehrfach als „absichtliches Verhalten” eingestuft und das Gesuch abgelehnt („Won’t Fix”). Im Oktober 2021 überraschte ein Googler mit der „Erklärung”, dass „raw sockets konstante Quelle für kernel exploits” seien, weshalb die Verbesserung nicht infrage komme. Dabei hatte niemand nach raw sockets (OSI-Layer 2 oder 3) gefragt, sondern lediglich nach Zugang für unprivilegierte Apps auf Layer 4.

Auch den zumindest dritten Anlauf vor gut vier Jahren hat Google mit „Won’t Fix” abgeschmettert. Doch vorige Woche entdeckte ein womöglich deutscher Entwickler, dass Anwendungen in der Developer Preview auf Android 17 Zugriff auf die UDP-Ports 319 und 320 ergattert haben.

Daraufhin rang Google sich zu einer teilweisen Öffnung durch, auch für altere Androids. Die grundsätzliche Herangehensweise, well-known Ports zu sperren, bleibt aufrecht. So viel Orthodoxie muss offenbar sein. Immerhin wird die Nutzung der zwölf obgenannten Ports ermöglicht.

Technisch gesehen setzt Google die neue Port-Whitelist mittels eBPF (extended Berkley Packet Filter) um. Das erfolgt in jenem APEX-Modul, das in Android Mainline für Datenverbindungen samt Tethering zuständig ist. Solche Module können durch Google Play Updates erneuert werden und bedürfen keines Updates des gesamten Betriebssystems. Der Konzern könnte Zukunft also relativ einfach weitere well-known Ports zur Verfügung stellen, wenn er denn möchte.

Voraussetzungen und Vergleich

Voraussetzung für den neuen Portzugriff sind sowohl mindestens Android 13 (API-Version 33 und höher) als auch mindestens Linux-Kernel 5.15. Damit sind Anwender erst mit Systemen, die neu mit Googles Android 14 ausgeliefert wurden, auf der sicheren Seiten. Mobiltelefone, die mit Googles Android 13 neu ausgeliefert wurden, durften Kernel 5.10 oder 5.15 nutzen, sind also nicht alle mit dabei. Geräte, die mit älteren Android-Versionen auf den Markt gekommen und später auf jüngere Versionen des Betriebssystems upgegradet worden sind, können sogar mit noch älteren Kernel-Versionen laufen.

Bei den Android-Varianten Android Auto, TV und Wear könnte die Verbesserung länger auf sich warten lassen. Das gilt auch für Android Go; das ist eine für weniger leistungsstarke Handys und Mobilfunknetze optimierte Android-Variante.

Die Einschränkung der niedrigen Ports ist auch bei anderen Linux-Systemen üblich. Allerdings ist es dort Administratoren in der Regel ein Leichtes, bei Bedarf Anwendungen den Zugriff zu gestatten. Für MacOS galt das nicht, doch können nicht-privilegierte Anwendungen seit Version 10.14 über die Wildcard-Adresse 0.0.0.0 auch an well-known Ports andocken. Den nicht auf Linux basierenden Betriebssystemen iOS und Windows ist die strikte Portnummern-basierte Blockade fremd.

(ds)