Normale Ansicht

Verkürzte Git-Commit-Hashes und das Linux-Repository

31. Dezember 2024 um 18:15

In der letzten Episode des Risikozone-Podcasts habe ich ganz kurz das Thema der verkürzten Hashwerte und auftretenden Kollisionen angesprochen. Jetzt gibt es ein Proof of Concept zu der Thematik.

Worum es geht

Ein kurzer Refresher, worum es in der Thematik überhaupt geht: Als Git entwickelt wurde, musste ein Weg gefunden werden, wie man die Referenzen auf Commits, die Dateien und die Dateibäume realisiert. In vielen Systemen wie z. B. Issue-Trackern werden aufsteigende Indizes verwendet. In einem verteilten System wie Git ist das aus verschiedenen Gründen der Synchronisation nicht so einfach möglich, da sonst Kollisionen, also gleiche IDs für unterschiedliche Objekte entstehen könnten. Eine Alternative wäre UUIDs, da die IDs einen randomisierten Anteil haben und die Wahrscheinlichkeit für Kollisionen gesenkt wird.

Noch besser als UUIDs ist allerdings Content-adressable Storage, bei dem Inhalte einzig durch ihren Inhalt adressiert werden. Das ist so, als würde man den gesamten Inhalt der Datei nochmal in den Dateinamen schreiben. Der Clou dabei ist jedoch, dass der gesamten Dateiinhalt gar nicht in den Dateinamen geschrieben werden muss, um die Datei durch ihren Inhalt identifizierbar zu machen.

Mit kryptographischen Hashfunktionen wie SHA-1 oder SHA-256 existiert ein Mittel, um einen beliebig langen Dateiinhalt zu einem immer gleich langen Wert, dem Hash, umzuwandeln. Dabei sind kryptographische Hashfunktionen so konstruiert, dass die Wahrscheinlichkeit für Kollisionen durch verschiedene Mechanismen stark minimiert wird. Ein SHA-1-Hash für den Dateiinhalt "Hallo Welt" wäre z. B. 28cbbc72d6a52617a7abbfff6756d04bbad0106a. Ein netter Nebeneffekt ist, dass Dateien mit gleichem Inhalt im Content-adressable Storage auch nur einmal abgespeichert werden, wodurch sogar Deduplikation ermöglicht wird.

Git nutzt dieses Verfahren, um die eingechekten Dateien abzuspeichern. Diese Dateien werden dann in Trees zusammengebunden und in Commits mit den jeweiligen Vorgänger-Commits (parents) in einem sog. Merkle-Tree verheiratet.

Commits werden somit auch durch einen SHA-1-Hash identifiziert, der im hexadezimalen Format 40 Zeichen lang ist.

Das Problem

Das Problem bei dem Verfahren liegt jetzt darin, dass dieser Hash üblicherweise noch weiter abgekürzt wird, um ihn benutzerfreundlicher in Oberflächen oder E-Mails darzustellen. Damit wird natürlich die Wahrscheinlichkeit für Kollisionen erhöht.

Habe ich einen Hash 28cbbc72d6a52617a7abbfff6756d04bbad0106a und nutze nur 28cbbc zur Referenz, reicht das in den meisten kleinen Repositories aus, um einen Commit eindeutig zu referenzieren. In großen Repositories mit vielen Dateien und Commits kann es auf einmal passieren, dass ein weiterer Commit 28cbbcc00aa8ef4e80596c16ecfdb4bc92656cd3 auftaucht, sodass 28cbbc nicht mehr eindeutig einen Commit beschreibt.

Um das Risiko zu verringern, sollte die Mindestanzahl der Zeichen für einen abgekürzten Commit erhöht werden.

Das Kernel-Repository

Genau darum geht es in der aktuellen Diskussion. Aktuell nutzen die Linux-Entwickler zur Referenz von Commits in ihren E-Mails 12 Zeichen lange Hashes. Die Diskussion dreht sich um die Frage, ob die Zahl weiter erhöht werden sollte. Linus Torvalds ist bisher dagegen, weil er das Risiko für Kollisionen gering sieht und er die Position vertritt, dass ein Commit immer mit dem Commit Message Title angegeben werden sollte, was ungewollte Kollisionen ausreichend verhindere.

Gestern veröffentlichte Kees Cook einen Blogpost, indem er eine Commit-Kollision mit dem Werkzeug lucky-commit bewusst herbeiführte, um darauf aufmerksam zu machen, dass die Git- und Kernel-Entwicklungstools mit solchen Situationen klarkommen sollten. Es ist unwahrscheinlich, dass solche Kollisionen bei 12 Zeichen versehentlich entstehen, aber ein Angreifer könnte dies ausnutzen.

Dies sollte ein Apell an alle Entwickler sein, deren Tooling auf abgekürzte Commit-Hashes setzt. Schauen wir mal, wie sich das weiterentwickelt.

Ein Kommentar zu SHA-1

Abschließend ein Kommentar noch zu SHA-1. Wie viele von euch wissen, ist SHA-1 selbst nicht mehr vertretbar kollisionssicher. Das bedeutet, es kann passieren, dass auf einmal zwei Dateiinhalte sich doch den gleichen Hash teilen könnten, wenn ein Angreifer es drauf anlegt.

Da dies natürlich Git massiv stören könnte, gibt es schon Bestrebungen, das Verfahren auf SHA-2 zu aktualisieren, wodurch sich die Hashlänge auch vergrößert. Das ist aber gar nicht so einfach, da SHA-1 an vielen Stellen in die Struktur eines Git-Repos hartkodiert wurde.

Hier geht es aber nicht um das unsichere SHA-1. Durch die Abkürzung des Hashes von 40 auf 12 Zeichen wird die Kollisionssicherheit bewusst und massiv zugunsten der Benutzerfreundlichkeit geschwächt. Und das erfordert immer eine regelmäßige Evaluation, welches Niveau noch vertretbar ist.

SSH - Zugangsberechtigungen via Schlüssel einschränken

26. Dezember 2024 um 19:48

Bekanntermaßen sind SSH-Verbindungen weitestgehend das Standardverfahren, um Serververbindungen sicher aufzubauen.
Normalerweise kommt in Bezug auf Authentifizierung eine Kombination aus Nutzernamen und Passwort zum Einsatz. Es gibt aber auch Varianten mit Zertifikat oder Schlüssel.
Letzteres sollte nicht nur Standard, sondern heute auch Thema sein. Üblicherweise erhältst du via SSH Vollzugriff (oke vielleicht kein root), es besteht allerdings die Möglichkeit diesen per authorized keys zu regulieren, so kannst du in einem SSH Schlüssel etwa eine IP-Beschränkung hinterlegen, um einen Zugriff weiter einzuschränken.

SSH AuthorizedKeysFile Format

In einem Standardsetup findest du vorhandene Schlüssel unter ~/.ssh/authorized_keys und genau hier möchte ich heute einen genaueren Blick darauf werfen.
Dort liegen die öffentlichen SSH-Schlüssel, die einen bestimmten Aufbau haben, dazu gleich mehr. Auch wird zwischen Version 1 und Version 2 unterschieden, wobei zwei der Standard sein sollte.
Ältere Semester kennen eventuell noch  ~/.ssh/authorized_keys2,  was ursprünglich für den zweiten Protokolltyp vorgesehen war, allerdings seit 2001 deprecated ist und heute maximal noch von böswilligen Akteuren missbraucht wird.
Zurück zu den Schlüsseln, folgende Aufteilung besitzen diese laut Norm:

  • Öffentliche Schlüssel des Protokolls 1 bestehen aus den folgenden durch Leerzeichen getrennten Feldern: Optionen, Bits, Exponent, Modulus, Kommentar.
  • Öffentliche Schlüssel des Protokolls 2 bestehen aus: Optionen, Keytype, base64-kodierter Schlüssel, Kommentar
  • Das Optionsfeld ist optional. Sein Vorhandensein wird dadurch bestimmt, ob die Zeile mit einer Zahl beginnt oder nicht (das Optionsfeld beginnt nie mit einer Zahl).
  • Die Optionen (falls vorhanden) bestehen aus durch Kommata getrennten Optionsangaben.

Im Detail ermöglichen sie, verschiedene Werte mitzugeben und anderen eine IP-Einschränkung.

SSH - Zugangsberechtigungen einschränken

Hier ein erstes Beispiel:

from="192.168.1.?,*.example.com" ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIDQu9QfY+g0XRVbRTaMPLRN2PVmrRCpaDRaxTHPqggn3 user@example.com

Zur Erklärung: Du kannst in den Optionen Wildcards setzen. Das heißt, im Beispiel oben hätte 192.168.1.1-9 Zugriff, sowie Subdomains von example.com.

Eine weitere Möglichkeit wäre, die Option command zu verwenden, um direkte Befehle zu hinterlegen:
 

command="bash /opt/startworkflow" ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIDQu9QfY+g0XRVbRTaMPLRN2PVmrRCpaDRaxTHPqggn3 user@example.com

command="/opt/mehrere_befehle.sh" ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIDQu9QfY+g0XRVbRTaMPLRN2PVmrRCpaDRaxTHPqggn3 user@example.com

Der Nutzer hat hier nur das Recht, das vorgegebene Kommando auszuführen, nicht mehr und nicht weniger

Kontrollieren kannst du solche Kommandos mit der Variable $SSH_ORIGINAL_COMMAND. Diese enthält die ursprüngliche Befehlszeile
sobald ein erzwungener Befehl ausgeführt wird.
Wenn du mehrere Befehle erlauben willst, kommst du nicht drumherum, ein Script zu schreiben, was diese Beschränkungen mehr oder weniger aushebelt.

Ein weiteres Beispiel zeigt die Verwendungen der Kommandos für SSH Tunneling bzw. Port Forwarding:

restrict,port-forwarding,permitopen="localhost:8765" ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIDQu9QfY+g0XRVbRTaMPLRN2PVmrRCpaDRaxTHPqggn3 user@example.com

Hier wird explizit erlaubt, eine Verbindung auf Port 8765 herzustellen und alles andere bitte bleiben zu lassen. Auch echter Shell-Zugang (no-pty ist in restrict enthalten) wird unterbunden.


     restrict
Enable all restrictions, i.e. disable port, agent and X11 forwarding, as well as disabling PTY allocation and execution of ~/.ssh/rc.  If any future restriction capabilities are added to authorized_keys files they will be included in this set.

 

Du hast nun einen kleinen Einblick in die vielfältigen Konfigurationsmöglichkeiten von SSH-Schlüsseln erhalten. Gerade IP-Beschränkungen oder Limitierung auf Befehle kommen im Alltag vor und sind in diesem Sinne keine neue Methode.
SSH Tunneling ist eigentlich schon wieder ein anderes Kapitel.
Einen Überblick der SSH Befehle findest du bei den Ubuntu Manpages. Viel Spaß.

 

Neuer Linux-Rootkit „Pumakit“ entdeckt: Das musst Du wissen

Von: MK
24. Dezember 2024 um 08:01

Ein neues Malware-Rootkit namens Pumakit wurde kürzlich entdeckt und stellt eine Bedrohung für Linux-Systeme dar. Es nutzt fortschrittliche Verschleierungsmethoden, um sich unbemerkt auf betroffenen Systemen zu verstecken. Aktuell betrifft die Schadsoftware ausschließlich Linux Kernel Versionen älter als 5.7. Das Sicherheitsunternehmen Elastic identifizierte Pumakit im September, nachdem ein verdächtiges Binary von „cron“ auf VirusTotal hochgeladen wurde. […]

Der Beitrag Neuer Linux-Rootkit „Pumakit“ entdeckt: Das musst Du wissen erschien zuerst auf fosstopia.

Redlib – Alternatives Reddit Frontend

14. Juli 2024 um 08:25

Ein neuer adminForge Service kann ab sofort genutzt werden.

Redlib ist ein datenschutzorientiertes und quelloffenes Frontend für Reddit.

Redlib

Redlib ist ein datenschutzorientiertes und quelloffenes Frontend für Reddit.

https://reddit.adminforge.de

Features:

🚀 Schnell: geschrieben in Rust für blitzschnelle Geschwindigkeit und Speichersicherheit
☁️ Leicht: kein JavaScript, keine Werbung, kein Tracking, keine Aufblähung
🕵 Privat: alle Anfragen werden über den Server geleitet, einschließlich Medien
🔒 Sicher: starke Content Security Policy verhindert Browser-Anfragen an Reddit

Browser Addons:

Mit dieser Erweiterung könnt ihr sämtlichen Reddit Traffic in eurem Browser auf eine Redlib Instanz umleiten.

Firefox: LibRedirect
Chrome: LibRedirect

Software: Redlib

 

Euer adminForge Team

UnterstützenDas Betreiben der Dienste, Webseite und Server machen wir gerne, kostet aber leider auch Geld.
Unterstütze unsere Arbeit mit einer Spende und diskutiere in unserem Chat mit.

by adminForge.

Ubuntu Summit 2024 angekündigt

Von: MK
24. Juni 2024 um 17:14

Der Ubuntu Summit ist in der Ubuntu Community ein Höhepunkt im Jahr. Es bietet schließlich die Möglichkeit sich auszutauschen, neue Dinge lernen, bahnbrechende Demos zu sehen und vielleicht mit Gleichgesinnten zu feiern. Der Ubuntu Summit findet dieses Jahr vom 25. bis 27. Oktober in Den Haag, Niederlande, statt. Wie immer ist die Teilnahme am Ubuntu […]

Der Beitrag Ubuntu Summit 2024 angekündigt erschien zuerst auf fosstopia.

Fork: Grafischer Git-Client für macOS

08. Februar 2024 um 16:47

Ich habe mich nach einer kleinen Testphase gegen GitKraken und für Fork als grafischen Client für Git unter macOS entschieden.Gitkraken mag ein hervorragendes Werkzeug sein, aber das Abomodell hat mich abgeschreckt. Ich möchte noch erwähnen, dass GitKraken ein Studenten- und Universitätspaket anbietet. Ich werde vielleicht GitKraken Kollegen:innen an meinem Arbeitsplatz für einen Test vorschlagen. Dann ... Weiterlesen

Der Beitrag Fork: Grafischer Git-Client für macOS erschien zuerst auf Got tty.

Firefox - Cookie-Dialog-Blocker aktivieren

22. November 2023 um 12:21

Firefox – Cookie-Dialog-Blocker

Vor kurzem ist der neue Firefox 120 erschienen, er bringt eine nützliche Cookiedialog Blockfunktion mit.
Du kennst nervige Pop-ups zur Genüge, diese haben in den vergangenen Jahren das Internet zu einem Klicknet gemacht.

Praktischerweise bringt der neue Firefox eine Funktion mit, um diese automatisch abzulehnen. Heißt, sie werden nicht einfach ausgeblendet, sondern sie werden beantwortet.

Leider ist diese Funktion bisher nur deutschen Nutzer und dem privaten Modus vorbehalten. Das kannst du allerdings einfach über about:config ändern.

firefox-cookie-banner-dialog-aktivieren

Du musst lediglich nach den Variablen cookiebanners.service.mode suchen und die Werte auf 1 setzen.

Sollten Cookie-Banner weiterhin nicht verschwinden, kannst du auch den Wert 2 setzen. Dieser sorgt dafür, dass Cookie Dialoge, die nicht abgelehnt werden können, automatisch akzeptiert werden.

  • 0 Cookie-Banner Blocker deaktiviert
  • 1 Cookie-Banner Blocker lehnt ab, sofern möglich
  • 2 Cookie-Banner Blocker lehnt ab, sofern möglich und akzeptiert den Rest

Kontrollieren kannst du die Funktion in den Privacy Einstellungen about:preferences#privacy.

Natürlich kannst du die neue Surffreude ebenfalls auf Webseiten mit Cookie-Banner testen, so etwas wie chip.de oder dergleichen. Hier hat bei mir das Ablehnen nicht funktioniert, sondern nur Wert 2 mit Ablehnen, wenn möglich, und den Rest akzeptieren.

Fingerabdruck ade

Eine weitere praktische Funktion, um den Fingerabdruck beim Surfen zu reduzieren, bietet der neue Fingerprinting-Schutz in der Canvas API, welcher allerdings auch nur im privaten Modus aktiv ist.

Links ohne Tracking kopieren

Eine ebenfalls hervorragende neue Funktion ist das Kopieren eines Links über das Kontextmenü ohne Trackinginformationen.

firefox-link-ohne-tracking

Alle weiteren Neuerungen von Firefox 120 findest du bei Mozilla.

Open-Source-Saatgut-Stadt Dortmund

16. März 2023 um 20:30

Open-Source-Gärten blühen nun dauerhaft in Dortmund

Die Open-Source-Tomate

Bild: Die Open-Source-Tomate

Die von Do-FOSS angestoßene Initiative für Open-Source-Saatgut wurde letztes Jahr von der Stadt Dortmund mit der Open-Source-Saatgut-Stadt Dortmund als zentrales Klimaschutzprojekt aufgenommen. Pünktlich zur diesjährigen Pflanzperiode gibt das Umweltamt der Stadt Dortmund das Ergebnis des Pilotjahres bekannt und verstetigt ihr Open-Source-Saatgut-Engagement, welches von einer Vielzahl an engagierten Bürger*innen getragen wird. Alle aktuellen Informationen zu ihrer Open-Source-Saatgut-Arbeit stellt die Stadt Dortmund regelmäßig auf dortmund.de/saatgut zur Verfügung. Samenfestes Saatgut ist die Zukunft der Landwirtschaft, so wie Freie Software die Zukunft der Digitalisierung ist. Mit der Open-Source-Saatgut-Stadt Dortmund sowie der Koordinierungsstelle Digitale Souveränität und Open Source wird die Stadt Dortmund ihrem Ruf der Open-Source-Stadt Dortmund auf vielfältige Weise gerecht. Dank der Open-Source-Copyleft-Eigenschaft können bei Saatgut wie bei Software für alle Menschen die dauerhaften Verfügungsrechte gewährleistet werden. Das Prinzip Open ist damit inklusiv und nicht exklusiv.

Das Thema Open-Source-Saatgut ist nun nach fünfjähriger Begleitung von Do-FOSS dauerhaft in die eigenständige Verantwortung der Stadt Dortmund übergeben. Nach der erfolgreichen Implementierung der Open-Source-Saatgut-Erkenntnisse und dem erblühen von Open-Source-Gärten in Dortmund freut sich Do-FOSS auf die weitere Entwicklung der Dortmunder Open-Source-Saatgut-Community. Den Mailverteiler der Saatgutcommunity betreibt Do-FOSS gerne auf Basis Freier Software weiter. Auch darüber hinaus wird Do-FOSS dem Thema Open-Source-Saatgut weiterhin verbunden bleiben, denn Saatgut wie Software, ist eine Frage der Lizenz.

Pressemitteilung der Stadt Dortmund im Wortlaut


Collage eines Workshops zur Saatgutgewinnung der Open-Source-Tomate Sunviva
Saatgutgewinnung der Open-Source-Tomate Sunviva
© s. Logos

Open-Source-Saatgut-Stadt: Pflanzen und Ernten für eine gerechte, nachhaltige Zukunft / WWF Earth Hour am 25. März

Die Etablierung der „Open-Source-Saatgut-Stadt-Dortmund“ ist das erste Vorhaben aus dem Handlungsfeld Landwirtschaft und Ernährung des städtischen Klimaschutzprogramms Klima-Luft 2030.

„Open-Source“-Saatgut bedeutet, dass das Saatgut frei von privatrechtlichen Schutzrechten und somit als Gemeingut frei nutzbar ist. Die Open-Source-Lizenz sorgt dafür, dass dies auch in Zukunft so bleibt. Mit Open-Source-Saatgut kann Offenheit gesät, Freiheit geerntet und leckeres Gemüse gegessen werden.

Möglichst viele Dortmunder*innen sollen Open-Source-Saatgut nutzen und untereinander als Community teilen. Die Stadt Dortmund stellt als Impulsgeberin zum Initiieren des Community-Kreislaufs Open-Source-Tomatensaatgut der Sorte Sunviva bereit. Das Umweltamt übernimmt dabei die Saatgutverteilung zum Aufbau einer Open-Source-Saatgut-Community. Dortmunder*innen, die mitmachen, engagieren sich für das so wichtige Thema „Saatgut als unsere Ernährungsgrundlage“ und produzieren gemeinsam und gemeinwohlorientiert Open-Source-Saatgut.

Saatgut kann heute mehr wert sein als Gold

Das Ziel der bürgerschaftlich getragenen Initiative der Open-Source-Saatgut-Stadt Dortmund ist es jährlich ein Kilogramm Sunviva-Open-Source-Saatgut für einen lebenswerten Planeten zu produzieren. Für einen Wertvergleich der Leistung der Initiative: bis zu 400.000 € kostet ein Kilogramm Saatgut gelber Cherrytomaten. Zum Vergleich des Werts von Saatgut: ein Kilogramm Gold kostet ca. 57.000 € (Börse Frankfurt, Stand: 2. Januar 2023). So gesehen ist das Ziel der Open-Source-Saatgut-Stadt Dortmund ein Kilogramm Saatgut zu produzieren am Markt rund siebenmal mehr wert als Gold. Anders als Gold hat das Saatgut außerdem den Vorteil perspektivisch zur Ernährung beitragen zu können.

Lebensmittel von Menschen für Menschen

Das erste Erntejahr der offenen Dortmunder Saatgutgemeinschaft mit ca. 50 Akteur*innen erbrachte 385 g Open-Source-Saatgut der Tomate Sunviva. Dr. Uwe Rath, Leiter des Dortmunder Umweltamtes meint: „Ein tolles Ergebnis, auf das alle Beteiligten stolz sein können!“ Christian Nähle, der das Projekt im Umweltamt koordiniert, stellt fest: „Ein Kilogramm Saatgut bedeutet mehr als eine Pflanze je Dortmunder*in. Dieses einfache Beispiel zeigt den enormen Ertrag der gemeinwohlorientierten Arbeit der Dortmunder Bürger*innen. Außerdem wird deutlich, dass unsere Nahrungsmittelversorgung ganz anders gestaltet werden kann.“ Jörg Lüling, Vorstand des Vereins Ernährungsrat Dortmund und Region e.V. ergänzt: „Das Menschenrecht auf Nahrung kann nur gewährleistet werden, wenn wir in der Lage sind, dies auch selbstorganisiert zu leisten. Deshalb freuen wir uns gemeinsam mit der Stadt Dortmund an einem solch wegweisenden Projekt wie der Open-Source-Saatgut-Stadt Dortmund zu arbeiten.“ Weitere Personen sind willkommen, sich auch dieses Jahr an der gemeinschaftlichen Dortmunder Saatgutproduktion zu beteiligen. Künftig soll auch die Arten- und Sortenvielfalt der gemeinsamen Saatgutherstellung verbreitert werden.

Saatgut soll breit gestreut werden

Das geerntete Open-Source-Saatgut wird nun unter allen interessierten Bürger*innen verteilt. Entweder direkt vor Ort im Umfeld der erzeugenden Saatgut-Akteur*innen oder über das Umweltamt. Die Saatguttüten sind von der Shanti Leprahilfe Dortmund e.V. bereitgestellt worden. Diese Tüten sind aus nachwachsendem Seidelbastrindenpapier und wurden von schwer behinderten Menschen in der beschützenden Werkstatt von Shanti in Kathmandu (Nepal) extra für die Open-Source-Saatgut-Stadt Dortmund gefertigt. Außerdem wurde die Verpackungsarbeit zur Versendung des Saatguts ehrenamtlich in Dortmund von Freiwilligen der Shanti Leprahilfe organisiert. Im Gegenzug wurde Open-Source-Saatgut als Beitrag zur Ernährungssicherheit in Nepal bereitgestellt. „Diese Gemeinschaftsaktion ist nur ein Beispiel von vielen für das solidarische Engagement der Bürger*innen in unserer Stadt.“ freut sich Marianne Grosspietsch, Vorsitzende der Shanti Leprahilfe e.V. und Trägerin des Bundesverdienstkreuzes am Bande.

WWF Earth Hour im Lichte von Landwirtschaft und Ernährung

Am 25. März feiert die Stadt Dortmund die WWF Earth Hour im Lichte von Landwirtschaft und Ernährung in der Pauluskirche (Schützenstr. 35, 44147 Dortmund). Das Programm beginnt um 17:00 Uhr. Näheres unter www.dortmund.de/wwf-earth-hour
Auch die Open-Source-Saatgut-Stadt Dortmund wird mit einem Stand präsent sein. Darüber hinaus wird es darum gehen, mehr Menschen für eine Zusammenarbeit für eine nachhaltige Landwirtschaft und Ernährung zu gewinnen. Der Ernährungsrat Dortmund und Region e.V. bietet der Zivilgesellschaft hierfür eine Plattform und arbeitet bereits mit der Stadt Dortmund zusammen, um das Dortmunder Ernährungssystem nachhaltig zu gestalten. Die Stadt Dortmund entwickelt derweil einen partizipativen Prozess für die Entwicklung einer Ernährungsstrategie. Auch hier wird das Thema Saatgut eine Rolle spielen.

Weitere Informationen und Saatgutbestellung

Alle Hintergründe für das städtische Engagement zu Open-Source-Saatgut finden sich hier: dortmund.de/saatgut Das Dortmunder Open-Source-Saatgut kann bestellt werden unter:
https://service.dortmund.de/open-source-saatgut

Für Rückfragen von Bürger*innen steht zur Verfügung:
Umweltamt – Koordinierungsstelle Klimaschutz und Klimafolgenanpassung
Christian Nähle, cnaehle@stadtdo.de, 50 – 2 87 74

Redaktionshinweis:
Dieser Medieninformation hängen folgende Bilder/Grafiken (Quelle: Stadt Dortmund) an:
– Collage eines Workshops zur Saatgutgewinnung der Open-Source-Tomate Sunviva
– Visual: Sunviva-Saatgut ab sofort über das Umweltamt der Stadt Dortmund per Kontaktformular bestellbar
– QR-Code: https://service.dortmund.de/open-source-saatgut

Pressekontakt: Christian Schön


Sunviva-Saatgut ab sofort über das Umweltamt der Stadt Dortmund per Kontaktformular bestellbar
© OpenSourceSeeds – AGRECOL

Dokumente zum Herunterladen

Die Pressemitteilung der Stadt Dortmund vom 07.03.2023 kann hier und ein QR-Code, der zum Bestellformular für Open-Source-Saatgut verlinkt, kann hier heruntergeladen werden.

CC0
Soweit im gesetzlichen Rahmen möglich verzichtet der Autor auf alle Urheber- und damit verwandten Rechte an diesem Werk.
Es kann beliebig genutzt, kopiert, verändert und veröffentlicht werden.
Für weitere Informationen zur Lizenz, siehe hier.

The post Open-Source-Saatgut-Stadt Dortmund appeared first on Do-FOSS.

❌