„Unsere zahlenden Kunden brauchen X, wann beheben Sie das?“
(twitter.com/maximilianhils)- Ein Unternehmensnutzer mit Kunden aus regulierten Branchen (Banken, Bundesbehörden usw.) forderte in einem öffentlichen Issue einen Zeitplan für das nächste Release des Open-Source-Tools mitmproxy und setzte die Maintainer unter Druck, weil seine Kunden die Software wegen bekannter Schwachstellen mit High- und Critical-Schweregrad nicht nutzen könnten
- Die betreffende Schwachstelle liegt in einem Teil einer Bibliothek, den mitmproxy nicht verwendet, sodass tatsächliche Nutzer nicht betroffen sind
- Der Maintainer lehnte die Anfrage nicht ab, sondern antwortete, dass man bei Bedarf an zeitnahen Patch-Releases einen kostenpflichtigen Supportvertrag (support contract) abschließen könne, und verwies auf die E-Mail-Adresse in seinem Profil
- Der Unternehmensnutzer schickte daraufhin eine Beschwerde-E-Mail und schrieb, er habe diese Antwort als „Scherz oder geschickt getarnten Erpressungsversuch“ aufgefasst
- Die Frage nach einem Release-Zeitplan ist an sich berechtigt; der Kernpunkt ist jedoch, dass eine kooperative Haltung nötig ist, etwa „Wie können wir mit Beiträgen oder Finanzierung helfen?“. Der ursprüngliche Kommentator schickte später eine aufrichtige Entschuldigung
Hintergrund des Vorfalls
- Laut der angehängten Kontextbeschreibung existiert in einer mit mitmproxy ausgelieferten Bibliothek eine Schwachstelle, sie betrifft jedoch einen Teil, den mitmproxy nicht nutzt, und hat daher keine Auswirkungen auf tatsächliche Nutzer
- Nachdem der Fall extern Aufmerksamkeit erregte (went viral), wurde zusätzlicher Kontext erläutert
Erste Forderung des Unternehmensnutzers (GitHub-Issue)
- Vor 16 Stunden erwähnte ein Nutzer ein anderes Projektmitglied, @Prinzhorn, und fragte nach einem Zieldatum (target date) für das nächste Release
- Er erklärte, Kunden aus regulierten Branchen (regulated industries) wie Banken und Bundesbehörden dürften aufgrund von Vorschriften keine Software mit bekannten Schwachstellen der Schweregrade High oder Critical verwenden
- Man wolle intern eine Position zum Warten (waiting) festlegen, benötige dafür aber irgendeine Form von Zieltermin
Antwort des Maintainers mhils
- Das Mitglied mhils antwortete vor 15 Stunden und erklärte, wenn Interesse an zeitnahen Patch-Releases zur Erfüllung der Compliance-Anforderungen des Unternehmens bestehe, sei er bereit, einen Supportvertrag einzurichten
- Die Kontaktdaten seien in der E-Mail seines Profils zu finden (einschließlich „:-)“)
Beschwerde-E-Mail („Concerning response“)
- Danach wurde von einer Adresse mit der Domain us.ibm.com eine E-Mail mit dem Betreff „Concerning response“ an github@hi.ls gesendet (datiert auf den 14. Juli 2023)
- Sie begann mit „Mr. Hils“ und erklärte, man wolle die Bitte um einen Zieltermin besser erläutern, um eine direkte Antwort zu erhalten, statt die Sache zu eskalieren oder den GitHub-Issue-Tracker unnötig mit Worten zu überladen
- Man hoffe, dass diese Nachfass-E-Mail nicht als beleidigend aufgefasst werde; das sei ausdrücklich nicht die Absicht
- In der hervorgehobenen Passage hieß es, man nehme an, die Antwort des Maintainers sei ein Scherz und keine offizielle Projektantwort oder, schlimmer noch, ein geschickt getarnter Erpressungsversuch (thinly veiled extortion attempt) (danach bricht der Satz beim Verweis auf die Prüfung der offiziellen Projektdokumentation ab)
Zusammenfassung der Position des Maintainers
- Er stellte klar, dass die Antwort kein Scherz war
- Ein Ansatz nach dem Muster „Unsere zahlenden Kunden brauchen X, wann beheben Sie das?“ sei möglicherweise nicht die beste Art, sich einem Open-Source-Projekt vorzustellen
- Er räumte ein, dass die Frage nach einem Release-Zeitplan an sich nicht störend, sondern berechtigt (valid) sei
- Entscheidend sei jedoch, dass der Kontext lauten müsse: „Wir interessieren uns für diese Arbeit, wie können wir helfen, sie umzusetzen?“ (durch Beiträge oder Finanzierung) — und nicht: „Sie verursachen unseren Kunden Probleme“
Abschluss
- Der ursprüngliche Kommentator schickte eine aufrichtige Entschuldigung (genuine apology), für die der Maintainer wirklich dankbar war
- Er bat alle darum, gute Absichten zu unterstellen (assume good intentions) und freundlich miteinander umzugehen
1 Kommentare
Hacker-News-Kommentare
Wenn man dieses Issue liesthttps://github.com/mitmproxy/mitmproxy/issues/6051, wirkt die Anfrage von IBM deutlich vernünftiger, als es im Tweet erscheint
Das Problem ist, dass es in einer mitmproxy-Abhängigkeit eine CVE gibt und mitmproxy die Abhängigkeit zwar im März aktualisiert hat, aber bis heute noch kein stabiles Release veröffentlicht wurde, das dieses Update enthält. IBM fragt also: „Wann plant ihr, einen Release-Tag zu setzen, gibt es einen Zeitplan, den wir unseren Kunden weitergeben können?“
Insbesondere wird nicht gefragt: „Wann behebt ihr das?“ Es gibt nichts mehr zu beheben; eher wird gefragt: „Wann plant ihr, ein neues Release zu erstellen, das dieses Abhängigkeits-Update enthält?“
Ich halte diese Frage an sich nicht für unangebracht. Natürlich ist es auch nicht unangebracht, einen Supportvertrag zu verlangen, wenn man möchte, dass solche Änderungen innerhalb eines bestimmten Zeitraums ausgeliefert werden, aber die knappe Antwort „Für einen Supportvertrag bitte per E-Mail anfragen“ wirkt etwas überzogen
Maximilian ist nicht verpflichtet, Menschen ohne Bezahlung einen Release-Zeitplan zu liefern, und wenn IBM wirklich einen Zeitplan braucht, ist es überhaupt nicht seltsam vorzuschlagen, dass sie dafür bezahlen sollen. Wenn es IBM so wichtig ist, könnten sie heute sogar selbst ein internes mitmproxy-Release bauen
Dass ich „Für einen Supportvertrag bitte per E-Mail anfragen“ gesagt habe, lag daran, dass 1) ich in dem Thread bereits erklärt hatte, dass wir dafür kein Patch-Release machen werden, und 2) die Gegenseite betont hatte, welche Auswirkungen das auf ihre zahlenden Kunden habe
Deshalb hatte ich dort nicht viel mehr zu sagen. Ich stimme zu, dass ich es besser hätte formulieren können, aber ich empfinde meine Antwort nicht als völlig überzogen
Die CVE selbst ist außerdem fragwürdig, und wir verwenden diesen Teil der Abhängigkeit nicht
Warum sollte der Maintainer dafür kostenlos arbeiten, während der Anfragende daraus Nutzen zieht?
Unangebracht ist die selbstverständliche Haltung von FrugalGuy. Von Open-Source-Maintainern kostenlose Arbeit zu verlangen und dann von Erpressung zu sprechen, erfordert schon eine besondere Form von Heuchelei. Von Freiwilligen, die freie Open-Source-Projekte nebenbei betreiben, kann man keine Forderungen durchsetzen
Hier der OP. Um das klarzustellen: Die Frage nach dem Release selbst ist überhaupt kein Problem und völlig berechtigt
Der Kontext sollte aber eher sein: „Wir haben daran Interesse, wie können wir helfen, damit es passiert?“ – sei es durch Beiträge oder Geld. Es sollte nicht heißen: „Wegen euch haben wir ein Problem mit unseren Kunden.“
Ich wünsche mir nicht, dass der Anfragende wegen einer unbedachten Formulierung ins Elend gestürzt wird; ich wünsche mir, dass große Unternehmen ein gesundes Verhältnis zu freier Open-Source-Software entwickeln
Schon allein so einen Vertrag anzubieten, ist eigentlich ziemlich freundlich. FrugalGuy hätte auch einfach die Antwort „Schick einen Pull Request“ bekommen können, und ich weiß nicht, ob ihm das lieber gewesen wäre
Wenn das Problem aber darin besteht, dass es für einen bereits erstellten Fix kein Release gibt, ist mir nicht klar, wie man das durch Beiträge oder Geld lösen soll
Das klingt wie das typische Verhalten von dumme[n] Informationssicherheitsleuten, die nicht einmal wissen, was sie da eigentlich „beheben“. Wenn ein automatisiertes System meldet, dass es eine CVE gibt, denken sie einfach, man müsse sie unbedingt „patchen“
Sie prüfen weder, was in der CVE überhaupt behauptet wird, noch ob ihre konkrete Nutzungsweise tatsächlich verwundbar ist. Sie wissen es nicht, es interessiert sie nicht, und sie sind keine Programmierer. Sie wissen nur, dass ein Kontrollkästchen abgehakt werden muss
Bei h2database gab es etwas Ähnliches. Ein „Sicherheitsforscher“ fand heraus, dass etwas Schlechtes passiert, wenn man etwas tut, von dem gesagt wird, dass man es nicht tun soll, und verlangte trotzdem eine CVE — und bekam sie auch. Wenn man genauer hinschaut, ist das Unsinn, aber für solche Leute zählt nur, dass die CVE existiert
Aussage eines h2database-Entwicklers: https://github.com/h2database/h2database/issues/3686#issueco...
„Es fällt mir schwer zu verstehen, warum ich auch nur das geringste Mitgefühl für ein ‚Großunternehmen‘ haben sollte, das ein von Freiwilligen entwickeltes Open-Source-Projekt nutzt. Entweder stellt ihr mit Firmengeld jemanden dafür ein, oder ihr bezahlt für eine ähnliche kommerzielle Bibliothek.“
Selbst wenn sie in einer konkreten Situation Ausnahmen gewähren dürften, müssten sie diese Entscheidung womöglich mit zusätzlicher Dokumentation rechtfertigen. Diese zusätzliche Dokumentation kostet Zeit und wirkt sich negativ auf ihre Leistungskennzahlen aus
„Wenn man ein Passwort auf der Kommandozeile übergibt, können andere Prozesse auf dem System es mit
pssehen“Das ist doch selbstverständlich. Wenn das eine CVE mit „hoher Schwere“ ist, kann ich mich auch Sicherheitsforscher nennen. Ich kann spontan mindestens fünf oder sechs Anwendungen nennen, die genau das erlauben und nur mit einem Warnhinweis versehen sind, dass man es nicht so machen soll
Das Informationssicherheitsteam meldet Schwachstellen, die in Berichten auftauchen, und das Management bekommt Angst
Entwickler müssen dann ständig Updates machen. Sogar für nicht-operative Abhängigkeiten. Man kann Ausnahmen beantragen, aber das ist ein völlig eigenes Ärgernis
Und danach fragt das Management, warum die Entwicklungsarbeit langsamer geworden ist
Ich bezweifle sogar, dass irgendjemand die übrigen Antworten tatsächlich prüft
Bei einem meiner Projekte gab es plötzlich einen starken Anstieg von Kommentaren wie „Wann wird das behoben?“, „Ich bin auch betroffen, und das ist wichtig“. Dieses plötzliche Interesse war ziemlich merkwürdig
Dann bekam ich aber ungefähr zur gleichen Zeit eine Entschuldigungs-E-Mail, in der stand, dass ein Vorgesetzter in irgendeiner Firma seine Mitarbeiter angewiesen hatte, mich unter Druck zu setzen, indem sie so taten, als seien viel mehr Leute betroffen als tatsächlich der Fall war
Es wirkt, als habe jemand an seinem Arbeitsplatz gelernt, dass ein aggressiver oder bedrohlicher Ton sehr effektiv ist, aber nicht verstanden, dass die Verhandlungsposition hier eine völlig andere ist
Zwischen „Ich muss wissen, wann es fertig ist, damit ich planen kann“ und „Ich verdiene Geld mit deiner Arbeit, also musst du das machen, bitte beeil dich“ gibt es einen feinen Unterschied
Hätte der Anfragende ohne Hintergrundinformationen gefragt, hätte es viel mehr nach Ersterem und viel weniger nach Letzterem geklungen
Wenn dieser Grund auch für viele andere Nutzer wichtig zu sein scheint, kann das Maintainern helfen zu entscheiden, ob sie eine Funktionserweiterung oder Fehlerbehebung priorisieren sollten. Wenn es eine Umgehungslösung gibt, kann das ebenfalls helfen, sie zu finden
Es war unfair, das als Erpressung von Entwicklern zu bezeichnen, aber ich finde nicht, dass mit der ersten Nachricht selbst etwas nicht stimmte
Das Anspruchsdenken von Unternehmen, die Open Source nutzen und dann auch noch Support verlangen, ist enorm. Ich wünschte, Lizenzen mit Nutzungseinschränkungen wären weiter verbreitet, und die OSI würde nicht einfach nur sagen: „Das ist keine Open Source!!!“
Solche Lizenzen könnten solche Situationen verhindern.
Jedenfalls ist es gut, dass OSI und FSF hier eine harte Linie vertreten. Wenn deine Prioritäten nicht mit ihren übereinstimmen, warum sollten sie sich ändern, nur um dich zufriedenzustellen?
Nimm einfach eine Lizenz, die dir gefällt. Auch wenn sie sie nicht absegnen. Ich verstehe nicht, warum das ein Problem sein sollte. Warum sollten diese Organisationen deiner Lizenzwahl ihren Stempel aufdrücken, wenn du ihre Werte von vornherein gar nicht teilst?
Für Unternehmenssponsoren ist die Ablehnung von Nutzungseinschränkungen kein Fehler, sondern ein Feature.
Rund um die Definitionen von Open Source und freier Software gibt es außerdem enorm viel Dogmatismus. Wer diesen Definitionen nicht folgt, wird schnell angegriffen, und diese Definitionen werden oft wie heilige Schriften behandelt. Die Anhänger wollen nicht einmal die Möglichkeit akzeptieren, dass Anpassungen an die Realität von 2023 nötig sein könnten.
Selbst wenn man neue Begriffe einführt, um Konflikte zu vermeiden, bestehen Open-Source- und Free-Software-Befürworter auf ihrer eigenen Sprache und wollen die Deutungshoheit behalten. Diese Sprache ist so gestaltet, dass sie innerhalb ihres Rahmens negative Konnotationen trägt.
Die Freiheit der Nutzer, Software für jeden Zweck auszuführen, ist Freiheit 0, und Stallman erklärt sehr überzeugend, warum Nutzungseinschränkungen nicht hilfreich sind: https://www.gnu.org/philosophy/programs-must-not-limit-freed...
Wie ein Gewährleistungsausschluss wird freie Software bedingungslos gegeben. Schon die Freiheit geschenkt zu bekommen, sie nach Belieben zu verändern, ist viel — dann auch noch kostenlosen Support und kostenlose Wartung zu verlangen, ist unhöflich. Ich glaube nicht, dass solche unhöflichen Leute verschwinden würden, nur weil man die Lizenz ändert.
Und es könnte Wege geben, die nicht über die Lizenz laufen und trotzdem Open Source gegenüber Unternehmen bevorzugen. Zum Beispiel könnte man verlangen, dass jemand, der ein schwerwiegendes Problem meldet, den Reproduktionscode öffentlich machen muss.
Schon in den 80ern, als Support oft kostenlos war, hörte man viele Geschichten darüber, wie Unternehmen so etwas mit Raubkopien von Software gemacht haben. Das Einzige, was solche Spielchen reduziert hat, waren kostenpflichtige Supportverträge.
Die einzige realistische Reaktion ist, wegen Lizenzverstößen zu klagen, aber nicht viele Open-Source-Entwickler haben die Mittel, das gegen mittelgroße Unternehmen geschweige denn gegen Konzerne durchzuziehen.
Das Verhalten von „FrugalGuy“ ist unreif und kindisch, aber der mitmproxy-Maintainer hätte auf bessere Weise höflich und zugleich bestimmt antworten können, ohne Raum für Missverständnisse oder Drama zu lassen.
„Gemäß der mitmproxy-Lizenz wird diese Software ohne Gewährleistung und wie gesehen bereitgestellt, und die Maintainer des Projekts sind derzeit an andere Prioritäten und Deliverables gebunden.“
„Daher reichen Aussagen im Github-Issue-Tracker allein nicht aus, um eine Priorisierung des Issues zu rechtfertigen. Die einzige Möglichkeit, die Priorität des Issues zu erhöhen, ist der Abschluss eines Supportvertrags; dieser wird [here] angeboten. Die Konditionen bespreche ich gern weiter im Detail.“
Wenn es um das Jahresgehalt eines einzelnen Ingenieurs geht, ist das für manche Unternehmensgrößen praktisch kein Geld, und es scheint, als könne die Korrektur in wenigen Wochen erfolgen; das wäre fair.
Oder wenn man wirklich kein Geld zahlen will, kann man einfach einen eigenen Ingenieur des Unternehmens für ein paar Monate darauf ansetzen, die für zahlende Kunden nötigen Teile zu patchen und den Beitrag upstream einzureichen.
Korrektur: Mit der Vergütung für ein Ingenieursjahr ist nur meine begrenzte und ungenaue Schätzung gemeint. Ich bin nicht in der Position, den genauen Wert zu benennen, aber ich vermute, dass es für einen Ingenieur, der die Codebasis nicht kennt, wahrscheinlich einige Monate Arbeit wären.
Allerdings könnten dadurch andere Compliance-Probleme entstehen, und vermutlich haben sie es deshalb nicht getan. Das ist natürlich nicht das Problem des Open-Source-Projekts.
https://github.com/mitmproxy/mitmproxy/issues/6051#issuecomm...
Einfach zu fragen „Gibt es ein Zieldatum für das nächste Release?“ ist nicht problematisch. Es ist keine Forderung.
Die Formulierung „Ich versuche intern zu begründen, warum wir warten sollten, und dafür brauche ich irgendein Zieldatum“ liest sich so, als richte sich das „brauche“ nicht als Forderung an die mitmproxy-Entwickler, sondern als Forderung anderer Leute an ihn.
In diesem Kommentar stellt er eine Bitte und erklärt die geschäftlichen bzw. persönlichen Beweggründe dafür. Problematisch wurde es erst, als er mit Begriffen wie Erpressung wieder per E-Mail ankam.
Im Originalpost standen sowohl der Kontext als auch der Arbeitgeber. Der Verfasser wollte das offensichtlich absichtlich vermeiden, und dann das tatsächliche GitHub-Issue herumzureichen, ist ebenfalls mieses Verhalten.
FrugalGuy— mir fehlen die Worte.