spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Es begab sich in GitHub Issue #95, dass ich über die Instandhaltung von Duality Plugins nachgrübelte. Wie Benutzer des Frameworks wissen, ist Duality zu großen Teilen modular aufgebaut: Sämtliche Editorkomponenten und einige optionale Kernkomponenten sind hübsch verpackt in Plugins ausgelagert, damit man sie nach Bedarf hinzufügen und entfernen kann. Andere Entwickler können eigene Plugins entwickeln, und diese ebenfalls dem Mix hinzufügen. Das ist alles schön und gut - ich hatte aber nun das Problem, dass ich ständig vergaß, nach Updates des Kerns jene optionalen Plugins zu aktualisieren, sodass diese teilweise für einige Tage in nicht lauffähigem Zustand im Git Repository verweilten. Dieses Problem ist mittlerweile gelöst, aber darum geht es hier eigentlich gar nicht; sondern um die Idee welche sehr schnell von findigen Duality Nutzern in den Raum gestellt wurde: Package Management sei eine feine Sache und Duality könne davon sehr profitieren, modular sei es ja ohnehin.

Ein paar Monate später, nach erfolgreicher Implementierung kann ich nur sagen: Stimmt alles, war eine geniale Idee. Danke dafür.



Aber worum gehts eigentlich? Wer mit C# entwickelt, hat möglicherweise bereits von NuGet gehört. NuGet ist ein Paketverwaltungssystem für .Net Libraries, welche das Einbinden von externen Dependencies deutlich vereinfacht und dabei auch noch den Speicherplatzbedarf deutlich reduziert, was Versionskontrollsysteme wie Git sehr zu schätzen wissen. Die Idee dabei ist es, Libraries nicht mehr in Form einer manuell eingepflegten .dll Datei mit ins Repository zu packen, sondern - mithilfe von NuGet - lediglich auf eine Package Id und Versionsnummer zu verweisen, und NuGet kümmert sich im Buildprozess dann automatisch darum, besagte Library aus dem zentralen Online Repository fertig gebaut herunterzuladen und zur Verfügung zu stellen. Als Bonus mit dabei können Library Updates mit wenigen Mausklicks durchgeführt werden, ohne dass dabei auch nur der Browser geöffnet werden müsste, geschweige denn Dependencies gebaut. Insgesamt also eine sehr schöne Idee, und in der Umsetzung auch eine runde Sache, soweit ich das bisher beurteilen kann.

Was hat das nun mit Duality zu tun? Im Grunde ganz einfach: Duality arbeitet seit Kurzem ebenfalls paketbasiert: Sämtliche Plugins wurden hübsch getrennt in Pakete ausgelagert, welche vom Benutzer mithilfe einer netten Benutzeroberfläche hinzugefügt, entfernt und aktualisiert werden können. Das vereinfacht es nicht nur, immer auf dem aktuellen Stand zu bleiben und optionale Funktionalität zu- oder abzuschalten, es verbessert auch die Sichtbarkeit von "Third Party"-Plugins, also von Duality Nutzern selbst geschriebenen Plugins. Werden diese bei NuGet mit einem entsprechenden Tag hochgeladen, sind sie ein paar Minuten später für alle Duality Benutzer verfügbar und können per Paketverwaltungs User Interface gefunden und installiert werden.



Was ist nötig, um mit dem neuen System loszulegen? Im Grunde nicht viel. Ein Download des aktuellen Binary Packages reicht aus, alles wie gewohnt also. Der erste Unterschied stellt sich beim Entpacken der .zip Datei ein:



Deutlich weniger Inhalt, oder zumindest sieht es so aus, bevor man Duality zum ersten Mal startet. Der Editor lädt sich die jeweils aktuellen Versionen der Standardpakete selbst herunter, sobald man ihn hochfährt:



Je nach Internetanbindung dauert das zwischen 10 Sekunden und ein paar Minuten, danach sind die Pakete da und alles läuft wie bisher. Für Puristen gibt es natürlich auch die Möglichkeit, nach dieser initialen Installation vollkommen ohne Package Management oder Internetzugang auszukommen. Genaue Anweisungen dazu finden sich im jeweiligen Wiki-Artikel. Außerdem dort zu finden sind Anweisungen, wie man seine eigenen Duality-Pakete schnürt und für alle verfügbar macht.

Das wärs mal wieder - Feedback wie immer willkommen

Auf Dualityseite gibt es leider keine Signierung und soweit ich das sehe unterstützt NuGet bisher auch noch nichts in der Richtung. Das Framework existiert allerdings nun schon eine Weile und wird auch in Form von Visual Studio Plugins stark benutzt - insofern würde ich mir zumindest darum keine allzu großen Sorgen machen. Der Punkt Sicherheit ist natürlich trotzdem eine wichtige Frage! Denke aber, dass das im großen und ganzen soweit ohne große Faux-Pas hinhaut. Hier mal ein paar Stichpunkte zum Thema:

• Es gibt keine automatischen Updates in Duality, welche es für Schadsoftware besonders attraktiv machen würden.
  
• Standardmäßig wird das offizielle NuGet Repository verwendet. Schadhafte Packages können dort als solche geflagged werden.
  
• Es ist nur dem Autor eines Pakets möglich, Updates für dieses hochzuladen. Dazu benötigt dieser einen API Key der nur ihm bekannt ist.
  
• Sämtliche beim initialen Download geladenen Pakete sind explizit per ID angegeben und sind bereits mit meinem NuGet Account assoziiert.
  
• Es erfolgt keinerlei Verbindungsmanagement auf Seiten von Duality, das übernimmt gänzlich die NuGet library. Es wird eine gesicherte Verbindung verwendet.
  
• Das Herunterladen und Resolven von Paketen übernimmt ebenfalls NuGet - keine Chance, sich da versehentlich zu vergreifen, weil mein dilettantischer Code Unfug macht.
  
• Wer es ganz genau wissen will, kann vor dem Download eines Packages die ID bei nuget.org eingeben sich Paketdaten und Autor genauer ansehen.
  

Natürlich bleibt immer ein Restrisiko, da es prinzipiell in jeder beliebigen Library seitens des Autors möglich ist, schadhaften Code zu implementieren - aber das ist ja nun nichts neues. Meine Hoffnung wäre, dass hier die Flag-Funktion von NuGet in Kombination mit der dargestellten Downloadzahl ihren Dienst tut. Perfekt ist NuGet sicher nicht, aber soweit ich das sehe auch kein akutes Sicherheitsrisiko. Ein paar qualifiziertere Gedanken (als meine) zum Thema NuGet und Sicherheit finden sich hier.

Befasse mich derzeit größtenteil mit einem kompletten Rewrite des Cloning Systems in Duality. Klingt erstmal langweilig, ist aber essentiell dafür, dass Prefabs funktionieren und der Editor UndoRedo sowie "Objekt duplizieren" beherrscht. Bisher ist das alles noch experimentell in einen separaten cloning branch ausgelagert und nicht "offiziell" verfügbar, aber das dürfte sich in absehbarer Zeit ändern. Da das ganze nun doch ein größeres Thema geworden ist, habe ich einen eigenen Blogeintrag zum Thema verfasst, der erklärt, was es mit diesem Cloning System im Groben so auf sich hat, und auch erklärt, in welche Fallgruben man stolpern kann, wenn man so etwas selbst entwickelt.

Zitat von »Schorsch«

Ich wollte es grad noch mal testen, kann die Binaries aber nicht laden. Die zip über Dropbox wollte er erst gar nicht ziehen. Nach einigem hin und her ging das zwar, wird aber als Malware erkannt.
In meine Dropbox kopieren kann ich auch nicht.

Das ist ein bekanntes Problem - leider :/ Habe bereits Google kontaktiert, allerdings keine Antwort enthalten. Es handelt sich dabei um einen Fehlalarm seitens Google Chrome, der auch bei anderer Software gelegentlich auftritt, sofern diese unbekannt ist und in "verdächtigen" Dateiformaten wie .zip daher kommt. Ein Hosting via Dropbox wird, vermute ich, auch als nicht besonders vertrauenswürdig eingestuft, habe aber leider derzeit keine ähnlich pflegeleichte Alternative.

Sollte das Problem auftreten, einfach kurz die Malware Detection deaktivieren und wieder aktivieren. Bin ehrlichgesagt etwas verstimmt gegenüber Google, mit solchen Maßnahmen vorzurücken - insbesondere ohne wirklichen Support für betroffene Entwickler.

Danke fürs reporten auf jeden Fall!

Zitat von »Schorsch«

Alles klar. Das ist wirklich sehr sehr ärgerlich. Habe es über Firefox geladen. Der hat auch nichts beanstandet.

Habe nun, da das Thema nun schon allzu oft aufkam, sämtliche Binaries auf meinen eigenen Webspace geladen und die entsprechenden URL redirects abgeändert. Wenn jemand mit Google Chrome nochmal testen könnte, ob Duality als Malware erkannt wird, wäre das sehr gut

> Duality Binaries <

Klappt das soweit?