Fragen zum Add-On Signing bzw. den Firefox Builds

    Ich möchte meinen Firefox um eine Funktion erweitern. Konkret möchte ich eine Möglichkeit implementieren, um Statusinformationen diverser Netzwerkkomponenten per SNMP abzufragen (nur get) und dann in einem Tab aufbereitet darzustelllen.

    Ich möchte das nicht per Script sondern in Form einer Erweiterung umsetzen. Das würde eine private Erweiterung sein. Ich habe also nicht vor, sie zu veröffentlichen und per AMO zu verteilen.

    An dieser Stelle erweist sich die durchaus sinnvolle Pflicht zur Signierung nun als kleines Hindernis. Soweit ich gelesen habe, lässt sich das in den offiziellen Versionen nicht mehr deaktivieren. Mir sind von https://wiki.mozilla.org/Add-ons/Extens…nbranded_Builds folgenden Möglichkeiten bekannt:


    • Einen Account bei AMO anlegen und die Erweiterung zertifizieren zu lassen, ohne sie zu veröffentlichen. Das möchte ich nicht.
    • Einen unbranded oder einen Dev-Build zu verwenden.
      Das könnte durchaus eine Option sein. Meine Frage dazu wäre, ob diese Builds dem automatischen Update unterliegen und falls nicht, wie zeitnah zu den offiziellen Versionen diese üblicherweise verfügbar sind.
    • Möglicherweise die ESR-Versionen. Die oben genannte Seite ist hier jedoch nicht ganz eindeutig. Dort steht

      Zitat


      The first ESR version to include signing support will be the Firefox ESR 52 release.


      Etwas weiter unten findet sich dann

      Zitat


      What about private add-ons used in enterprise environments?

      The ESR release supports signing starting with version 45-based releases. Signing enforcement is enabled by default in these releases, and enforcement can be disabled using the xpinstall.signatures.required preference.


      Abgesehen von den unterschiedlichen Versionsnummern, ist meine Annahme richtig, dass sämtliche ESR-Version ab der 52 die Möglichkeit bieten, unsignierte Erweiterungen zu installieren?

    Falls es noch eine weitere Möglichkeit gibt, bitte her damit. Danke!

    Zitat von Casali

    Einen Account bei AMO anlegen und die Erweiterung zertifizieren zu lassen, ohne sie zu veröffentlichen. Das möchte ich nicht.

    Du meinst vermutlich signieren und nicht zertifizieren lassen. Mit welcher Begründung möchtest du das nicht? Das ist ein vollkommen automatisierter Prozess, der das Problem löst. Welchen Nachteil siehst du?

    Zitat von Casali

    Einen unbranded oder einen Dev-Build zu verwenden.
    Das könnte durchaus eine Option sein. Meine Frage dazu wäre, ob diese Builds dem automatischen Update unterliegen und falls nicht, wie zeitnah zu den offiziellen Versionen diese üblicherweise verfügbar sind.

    Es gibt keine automatischen Updates für Unbranded Builds. Die Links zu den Unbranded Builds werden in der Regel bei Major-Updates sehr zeitnah bereitgestellt, bei Updates mit Änderung der Versionsnummer an dritter Stelle nicht immer.

    Für die Developer Edition und Nightly-Version gibt es selbstverständlich schon Updates (Developer Edition: ein bis zweimal pro Woche, Nightly-Versionen: ein bis zweimal pro Tag).

    Zitat von Casali

    Abgesehen von den unterschiedlichen Versionsnummern, ist meine Annahme richtig, dass sämtliche ESR-Version ab der 52 die Möglichkeit bieten, unsignierte Erweiterungen zu installieren?

    Ja.

    Zitat von Sören Hentzschel


    Du meinst vermutlich signieren und nicht zertifizieren lassen.


    Ja klar, so wie in der Überschrift auch erwähnt. Da war der Freud nur schneller als ich.

    Zitat von Sören Hentzschel


    Mit welcher Begründung möchtest du das nicht?


    Das hat mit der Art der Erweiterung zu tun, die mir vorschwebt. Solche Netzwerkkomponenten, um die es mir geht, hat man nicht im Keller stehen. Der eine oder andere hat zuhause, so wie ich, vielleicht einen einen kleinen manageable Switch mit 8 bis 24 Ports aber sicher kein größeres Netzwerk oder gar Fabrics. Die typischen Consumer-Produkte, wie eine Fritzbox oder ein Netgear Switch für 50 Euro, beherrschen ja nicht einmal SNMP.

    Mein Arbeitgeber ist so freundlich und erlaubt mir, eines unserer Test-Labs zu benutzen. Da habe ich alles, was das Herz begehrt. Gemäß der Firmenpolicy ist es mir nicht gestattet, irgendetwas nach außen zu senden, auch nicht an einen Automaten. Ich müsste dann also bei jeder noch so kleinen Änderungen zunächst im Lab testen, die Erweiterung dann von zuhause aus signieren lassen und könnte sie dann am nächsten Tag auch in der Firma benutzen. Das ist mir zu aufwendig und zeitraubend.

    Ansonsten vielen Dank für die Antworten. Das hilft mir schon mal weiter. Ich werde mich sicher mit einer der Lösungen arrangieren können. Zumindest für die Entwicklung werde ich wohl parallel die ESR installieren.

    Manchmal ist man wirklich betriebsblind. Das ist mir schon fast peinlich. Ich war so darauf fokussiert, die Aufgabe über eine Erweiterung lösen. Ich wollte gern mal selbst ausprobieren, wie man eine Webextension erstellt.
    Erst als ich mir am Nachmittag weitere Gedanken zur Umsetzung, insbesondere zu den Details des SNMP-Protokolls gemacht habe, wurde mir klar, dass eine Erweiterung in diesem Fall absolut nicht die optimale Lösung ist.

    Bei der Suche nach den RFCs bin ich auf dieses Projekt gestoßen: https://github.com/stephenwvickers/node-net-snmp
    Der Autor stellt damit für node.js alles Wesentliche bereit, was man benötigt, um mit einem SNMPv2c-Agent per JavaScript zu kommunizieren.
    Das erspart nicht nur viele Stunden des Einlesens in die RFC und das Schreiben der entsprechenden Funktionen. Die Aufgabe serverseitig über node.js zu lösen ist auch einfach die "schlauere" Idee. Man ist dann ganz unabhängig vom verwendeten Browser, der Version, der Signierung, ... .

    Ich werde meinen "Monitor" deshalb über eine dynamische Webseite bauen. Das habe ich zwar auch noch nicht gemacht, aber den JS-Teil und die Anzeige bekomme ich hin. Das "Schönmachen" der Seite ist dann für mich weniger interessant. Da lasse ich mir von einem Bekannten helfen.

    Für Mitlesende interessanter als meine Pläne:

    Bei meiner Recherche habe ich auch von der Möglichkeit gelesen, node.js als Executable in eine Erweiterung einzubinden und über nsIProcess zu nutzen. Der Firefox wird damit quasi zum Node.js-Server. Das klingt spannend und ermöglicht einiges, was über einen reinen Browser hinausgeht. Siehe http://rawkes.com/articles/running-node.html

    Bei Mozilla hat man anscheinend ähnliche Gedanken. Es gibt ein entsprechendes Projekt, das aber im Moment zu ruhen scheint:
    https://medium.com/mozilla-tech/m…js-33c13e29beb1
    https://github.com/mozilla/spidernode

    Zitat von Casali

    Bei meiner Recherche habe ich auch von der Möglichkeit gelesen, node.js als Executable in eine Erweiterung einzubinden und über nsIProcess zu nutzen. Der Firefox wird damit quasi zum Node.js-Server. Das klingt spannend und ermöglicht einiges, was über einen reinen Browser hinausgeht. Siehe http://rawkes.com/articles/running-node.html

    Der Artikel ist aus dem Jahr 2011, nsIProcess ist keine WebExtension-API. Wenn du mit einer lokalen Anwendung auf dem System kommunizieren willst, ist Native Messaging das entsprechende WebExtension-Konzept:

    https://developer.mozilla.org/en-US/Add-ons/…ative_messaging

    Zitat von Casali

    Bei Mozilla hat man anscheinend ähnliche Gedanken. Es gibt ein entsprechendes Projekt, das aber im Moment zu ruhen scheint:
    https://medium.com/mozilla-tech/m…js-33c13e29beb1
    https://github.com/mozilla/spidernode

    Ich würde nicht davon ausgehen, dass daraus in absehbarer Zeit etwas Brauchbares resultiert. Ursprünglich wurde das Spidernode-Projekt ja in Zusammenhang mit Positron gestartet, aber die Entwicklung von Positron hat Mozilla ganz offiziell eingestellt.

    Hier gibt es ein relativ aktuelles Statement zum Stand von Spidernode (drei Wochen alt):
    https://github.com/mozilla/spider…mment-351783384

    Ich kannte das Positron bisher als das Antiteilchen des Elektrons, also als Lepton. Und natürlich das positronische Gehirn von Lt. Commander Data. ;)

    Ja, Spidernode machte mir schon den Eindruck, als würde es stillstehen oder von anderen Entwicklungen überholt werden. In der IT ist alles sehr schnellebig.

    Zitat von Casali

    Ich kannte das Positron bisher als das Antiteilchen des Elektrons

    Das ist die Idee hinter der Namensgebung gewesen. ;) Electron [1] erlaubt die Entwicklung von plattformübergreifenden Desktop-Applikationen mit Webtechnologien. Das Ganze basiert auf Chromium und ist ziemlich verbreitet. Positron sollte ein Pendant mit Mozilla-Technologie werden.

    [1] https://electronjs.org/

    Ich habe mir das Video auf der Seite angeschaut. Aus der Helikoptersicht stellt es sich mir so ähnlich dar, wie die Grundidee hinter Java. Man schreibt die App in plattformunabhängigem Code, der bei Java durch die JRE und bei Electron durch Node und den Browser dann plattformspezifisch interpretiert/kompiliert wird und ausgeführt werden kann.

    Ein Problem bei Java (ich meine jetzt Applikationen) ist, dass die unterschiedlichen JREs dann doch nie ganz gleiche Resultate liefern, vor allem dann, wenn sie nicht von Sun/Oracle sind.
    Unter Linux gibt es neben dem Original auch eine offene SDKs/JREs, Apple hat sich Jahre lang schwer getan. Im Resultat kommt es dann immer wieder vor, dass Kleinigkeiten nicht passen, z.B. das Schriften abgeschnitten werden, weil sie aufgrund der leicht unterschiedlichen Größe nicht mehr in ein Label passen usw. .
    Ein größeres Problem sind oftmals die Versionsabhängigkeiten. Das PLM verlangt Java Version x, der Netzworkmonitor kommt mit Version y.
    Ich würde mir wünschen und hoffe, dass es hier besser wird und alle am selben Ende des Strangs ziehen. Insofern ist die Entscheidung, Positron nicht mehr weiterzuverfolgen, vielleicht eine gute.

    Ich bin heute früh, obwohl ich noch ein paar Tage Urlaub habe, in die Firma gefahren und habe dort einen Beispiel-Code aus dem node-net-snmp ausprobiert. Es funktioniert. :)

    Nach dem Urlaub geht es dann weiter. Danke soweit.

    Zitat von Casali

    Ich würde mir wünschen und hoffe, dass es hier besser wird und alle am selben Ende des Strangs ziehen. Insofern ist die Entscheidung, Positron nicht mehr weiterzuverfolgen, vielleicht eine gute.

    Ich hätte mir gewünscht, dass Positron weiterverfolgt wird, denn der Embedding-Markt ist komplett in Google-Hand. So ziemlich alles, was mit Webtechnologie umgesetzt ist, basiert auf Chromium. Da gibt es auch keinen Strang, an dem Mozilla mitziehen kann. Mozilla würde damit Ressourcen investieren, Chromium und Google noch stärker zu machen. Mozilla ist nach wie vor interessiert, wieder auf dem Embedding-Markt einzusteigen. Das würde übrigens Firefox-Forks auch sehr viel einfacher machen. Nicht grundlos basieren so viele Browser auf Chromium. Auf Firefox basierende Browser (außer Tor; und die geben Änderungen sogar Upstream an Mozilla zurück!) sind ansonsten in meinen Augen alle nichts wert, da sie alle keine Innovationen liefern, sondern sich ausschließlich darauf beschränken, Sachen zu deaktivieren oder alten Code weiterzubehalten. Man ist noch auf der Suche nach dem richtigen Weg in der Embedding-Sache und Positron hat sich offensichtlich nicht als der richtige Weg herausgestellt…

    Zitat von Sören Hentzschel

    Ich hätte mir gewünscht, dass Positron weiterverfolgt wird, denn der Embedding-Markt ist komplett in Google-Hand. So ziemlich alles, was mit Webtechnologie umgesetzt ist, basiert auf Chromium.


    Wie kam es eigentlich dazu? Hat Mozilla den Trend verschlafen oder war die technical debt bei Gecko einfach mal wieder zu hoch um es hinzukriegen?

    Zuletzt las man in den Browser Architecture Newslettern wieder vermehrt Gedanken Richtung Embedding. Konkrete Pläne für eine Umsetzung scheint man aber noch nicht zu haben.

    Zitat von Lurtz

    Wie kam es eigentlich dazu? Hat Mozilla den Trend verschlafen oder war die technical debt bei Gecko einfach mal wieder zu hoch um es hinzukriegen?

    Mozilla hatte es schon hinbekommen, früher gab es ja auch einige Gecko-basierte Browser mehr als heute. Ich erinnere mich beispielsweise noch an Flock, die dann irgendwann auf Chromium umgestellt haben. Man konnte Gecko nämlich in andere Anwendungen einbetten, was heute nicht mehr so ohne Weiteres möglich ist.

    Mozilla hat mit Gecko / Firefox 4 die Unterstützung für Embedding entfernt. Und das war zum damaligen Zeitpunkt meines Erachtens auch die richtige Entscheidung, denn es hat die Entwicklung massiv behindert. Unter anderem die Umsetzung der Multiprozess-Architektur (ja, schon vor so vielen Jahren war das ein Thema) hätte dies noch weiter erschwert. Für Mozilla war es wichtig, den Fokus verstärkt auf Firefox zu legen.

    Und so sehr ich dies für die richtige Entscheidung zum damaligen Zeitpunkt halte, so sehr denke ich auch, dass die Zeit reif ist, dies erneut in Angriff zu nehmen. Man könnte nun argumentieren, ob Mozilla den perfekten Zeitpunkt nicht schon wieder verpasst hat, denn Mozilla ist nun in einer sehr ungünstigen Lage, was dieses Thema betrifft. Dem gegenüber steht aber das Argument, dass der Fokus auf Firefox bis zuletzt extrem wichtig war (der ja zwischenzeitlich durch Projekte wie Firefox OS auch verloren ging). Also das ist eine schwierige Situation. Klar könnte man spekulieren, was man hätte anders machen können. Zum Beispiel Firefox OS sein lassen, das hätte automatisch mehr Fokus für Firefox bedeutet, vielleicht wäre Firefox dann heute schon weiter, dann hätte man sich unter Umständen auch diesem Thema eher widmen können. Aber ich sehe es ehrlich gesagt als eine Pflicht von Mozilla, dass sie dieses Projekt gewagt haben. Leider war am Ende der Markt zu stark, aber ich stehe zu meiner Ansicht, dass Mozilla es versuchen musste, und es hat die Webplattform ja durchaus auch weiter gebracht. Auch half es, den Speicherverbrauch von Gecko zu optimieren, weil man auf Geräten mit wirklich wenig RAM laufen musste.

    Was für mich daraus deutlich wird, ist, dass ich sehr froh, nicht die Entscheidungen treffen zu müssen, die bei Mozilla ganz oben getroffen werden müssen, denn das sind teilweise wirklich harte Entscheidungen mit großen Auswirkungen, deren Konsequenz im Vorfeld leider nur bedingt absehbar ist. Hinterher ist es immer leichter zu sagen, dass man etwas hätte anders machen können.