Da bewahrheitet es sich wieder: Open Source ist sicher.

[1st1]

Jeder kann den Quellcode einsehen, jeder kann den Quellcode patchen und damit nicht nur erweitern, sondern auch Fehler beseitigen,

Wie lange waren diese Lücken jetzt offen?

[schap23]

Das ist ja das lustige mit dem üblichen Umgang mit Fehlern: Die werden 90 Tage vor der Veröffentlichung den Verantwortlichen für die Software mitgeteilt. Bei Open Source bedeutet das, daß man jemanden finden muß, der Commit-Recht hat und auch Willen und Kenntis die Lücke zu schließen.

Wenn irgendwer die Lücke erkennt und einen Patch einreicht, ist das schon eine Veröffentlichung der Lücke. Übelwollende Leute brauchen nur die eingereichten Patches zu Scannen und können dort die Sicherheitslücken auf dem Tablett serviert finden. Dann haben sie Zeit, bis die Maintainer des Projekts den Patch überprüft und damit ein neues Release hergestellt haben.

[Hulk]

… und wo, mein Freund, warst Du, als diese Lücken offen waren?

Ich hab Trollkommentare gelesen.

Liebe
Hulk

[wonoscho]

LOL
Na wenn jeder den Quellcode patchen kann, dann braucht es ja gar keine offiziellen Patches geben, denn Jeder kann ja die Software die er nutzt selbst nach Belieben patschen.

Auch fragt man sich, wenn der Quellcode von jedem gelesen werden kann, wieso der Fehler überhaupt noch drin war und nicht schon längst gefunden und beseitigt wurde?
Wo es doch tausende oder gar Millionen User gibt, die den Code lesen können?

Aber wie war das noch gleich mit dem Lesen?
„Wer lesen kann ist klar im Vorteil.
ABER:
Nur wer das Gelesene auch versteht,
kann es zu seinem Vorteil nutzen.“

Und bei größeren Softwarepaketen kann es Jahre dauern, bis man das Gelesene tatsächlich bis in alle Einzelheite, Abhängigkeiten und Zusammenhängen versteht.

Aber mal ne Frage:
Angenommen eine Firma setzt ein Open Souce Software-Paket ein, und darin wird eine schwerwiegende Lücke entdeckt. aber niemand fixt diese Lücke.

Wen zieht man denn da bei Open Source zur Verantwortung ???



7 mal bearbeitet, zuletzt am 19.05.18 16:20 durch wonoscho.

[Anonymer Nutzer]

im falle von email-lösungen, ist der fehler überhaupt diese schiere überfunktionalität zu pflegen, weder protokoll, server noch verbreitete clientlösungen halten den heutigen anforderungen von grund auf stand.

[wonoscho]

Ja, da hat sich von Anfang an Wildwuchs entwickelt, „viele Köche haben an dem Brei gekocht“ und die Softwarentwickler haben große Mühe, alles irgendwie sinnvoll unter einen Hut zu bringen.

[Mr Miyagi]

1st1 schrieb:
--------------------------------------------------------------------------------
> Jeder kann den Quellcode einsehen, jeder kann den Quellcode patchen und
> damit nicht nur erweitern, sondern auch Fehler beseitigen,
>

Zitat aus dem Artikel:
>> Nutzer des Thunderbird-Mailprogramms, die Mailverschlüsselung benutzen, sollten dringend >> das Update auf Version 52.8.0 installieren. Neben weiteren Sicherheitslücken werden darin >> verschiedene Bugs behoben, die es Angreifern ermöglichen, verschlüsselte Nachrichten zu
>> exfiltrieren. Nach wie vor kein Update gibt es für Apple Mail, das ähnlich wie Thunderbird von
>> der gravierendsten Variante der Efail-Sicherheitslücke betroffen ist.

> Wie lange waren diese Lücken jetzt offen?

Auf jeden Fall weniger lange als bei Apple-Mail, insofern kannst Du dir die Trollerei schenken.

<°(((<

lass es Dir schmecken.

[Mr Miyagi]

ML82 schrieb:
--------------------------------------------------------------------------------
> im falle von email-lösungen, ist der fehler überhaupt diese schiere
> überfunktionalität zu pflegen, weder protokoll, server noch verbreitete
> clientlösungen halten den heutigen anforderungen von grund auf stand.

Das Protokoll hält super stand, es erlaubt kein HTML. Sprich wer sich ans Protokoll hält hat auch nicht zu befürchten. Das Problem tritt in dem Moment auf in dem sich Applikationen *nicht* an das Protokoll halten.

[Apfelbrot]

Mr Miyagi schrieb:
--------------------------------------------------------------------------------
> ML82 schrieb:
> ---------------------------------------------------------------------------
> -----
> > im falle von email-lösungen, ist der fehler überhaupt diese schiere
> > überfunktionalität zu pflegen, weder protokoll, server noch verbreitete
> > clientlösungen halten den heutigen anforderungen von grund auf stand.
>
> Das Protokoll hält super stand, es erlaubt kein HTML. Sprich wer sich ans
> Protokoll hält hat auch nicht zu befürchten. Das Problem tritt in dem
> Moment auf in dem sich Applikationen *nicht* an das Protokoll halten.

Es steht nirgends dass HTML nicht erlaubt ist, es ist reiner ascii content, und entspricht daher erst mal RFC 5322

[Tuxgamer12]

Apfelbrot schrieb:
--------------------------------------------------------------------------------
> Mr Miyagi schrieb:
> ---------------------------------------------------------------------------
> -----
> > ML82 schrieb:
> >
> ---------------------------------------------------------------------------
>
> > -----
> > > im falle von email-lösungen, ist der fehler überhaupt diese schiere
> > > überfunktionalität zu pflegen, weder protokoll, server noch
> verbreitete
> > > clientlösungen halten den heutigen anforderungen von grund auf stand.
> >
> > Das Protokoll hält super stand, es erlaubt kein HTML. Sprich wer sich
> ans
> > Protokoll hält hat auch nicht zu befürchten. Das Problem tritt in dem
> > Moment auf in dem sich Applikationen *nicht* an das Protokoll halten.
>
> Es steht nirgends dass HTML nicht erlaubt ist, es ist reiner ascii content,
> und entspricht daher erst mal RFC 5322

Ach wie lustig!

Natürlich spricht nichts dagegen, <img src="https://efail.de/x= in deine Mail zu tippen. Das spezifizierte Ergebniss ist dann eben: Nutzer sieht einen img-Tag.

Oder ließt du irgendwo im Standard, dass wenn du img-Tag ließt, du Kontakt zu dieser Domain herstellen sollst? Nein? Eben.

[throgh]

Und? Wie lange hat es jetzt gedauert bis erste Korrekturen vorgelegen haben? Ja, Open-Source ist ein Vorteil, während geschlossene Software entsprechend durchweg kaum transparent für Nutzer agiert und Korrekturen entsprechend nur vom Wohlwollen des Herstellers dahinter abhängig sind. ;-)

Aber netter Versuch!