Probleme mit GPL 2

jd

Hallo Gemeinde.

Ich habe ein Problem, was mich jetzt schon seit Tagen beschäftigt. Ich habe eine Client-Server Applikation mit Qt4 geschrieben. GPL2 besagt, das ich den Quellcode offen legen muss, bzw auf Anfrage raus geben muss. Das ist kein Problem und ist auch gewollt. Jetzt ist das aber für mich ein großes Sicherheitsproblem, Da der Client via dem Server Daten aus der Datenbank bekommt.

Client -> Server -> Datenbank.

Den Server habe ich dazwischen gepackt, da ich in den Clients keine SQL-Befehle verwenden kann, geschweige denn Verbindungsdaten, das wäre mein Todesurteil. Da ja der Quellcode offen liegt, kann man mir das ganze trotzdem schaden, da ja jeder lesen kann wie die Kommunikation abläuft.

So nun habe ich mir folgendes überlegt, das ich ein Kommunikations- "Protokoll" auf Basis von XML schreibe (lässt sich wunderbar parsen). Das Protokoll wird mit "Plain" C++ entwickelt und wird eine Library die Closed-Source ist.

Wie Läuft das rechtlich?
Kann ich in einem Programm was unter GPL-2 steht eine Closed-Source Lib verwenden? Ober müsste ich auch den Code für das Protokoll raus rücken? Die Verwendung der LIb wäre halt auch kostenlos und würde zum Download stehen (auf Anfrage), Aber den Code der Lib kann ich nicht raus geben, da das ein Sicherheitsproblem ist.

Wäre super wenn jemand ein paar Tipps parat hat.

PS: Ich habe einen Tipp bekommen das ganze über SOAP zu machen, aber da denke ich da werde ich spätestens bei WindowsMobile auf Probleme stoßen.

so long
jd

Das darfst du schon machen, sonst müsste Mircrosoft ja auch den Code der Winapi rausgeben weil QT diese benutzt und unter der GPL verfügbar ist.

Aber deine Security by Obscurity Taktik wird nicht aufgehen. Entweder dein Server ist sicher, dann ists egal ob jeder den Quellcode sehen kann oder er ist es nicht und dann spielt es auch keine Rolle, weil sie auch so gefunden wird.

Wenn der Client etwas mit dem Server tut, das niemand sehen soll hast du etwas falsch gemacht. Alles was deine Client-Anwendung mit dem Server tut sollte jeder auch händisch oder mit einem anderen Programm machen dürfen.

rüdiger

Warum stellt das ein Sicherheitsproblem für dich das? Wenn es so ist, dann machst du imho etwas grundlegendes falsch. Security-by-Obscurity ist einfach nur böse.

Von der Lizenz her ist es sowieso nicht in Ordnung.

btw. von SOAP würde ich die Finger lassen: http://wanderingbarque.com/nonintersecting/2006/11/15/the-s-stands-for-simple/
und auch XML ist vielleicht nicht ideal für ein Netzwerkprotokoll, wegen der viele Redundanzen.

jd

Jeder der das Programm benutzt, braucht ein Account bei mir. Mit der Client-Software meldet man sich dann via Server-Software an. Nun kann man seinen Account auch konfigurieren, dazu benötige ich ein paar Daten aus der DB (logisch).

Was definitiv ausfällt ist, das sowas im Client steht:

SELECT space FROM kunden WHERE lk='xxxxx-xxxxx-xxxxx-xxxxx-xxxxx';

Das halte ich für Tödlich. Wenn einer etwas überlegt oder rumprobiert, bekommt er meine ganzen Kunden-Daten, soviel zum Thema Datenschutz.

Security by Obscurity ist dumm, das weiß ich, aber mir fällt einfach nichts anders ein. Desswegen habe ich über eine alternatives Kommunikations "Protokoll" nachgedacht. Was natürlich super wäre, wenn ich nichts mit Closed-Source machen muss, denn ich möchte ja das JEDER eine eigene Client-Software für mein Server auf Basis des Protokolls schreiben kann. Nur wie kann ich das Lösen, das es trotzdem sicher ist?

Ich habe eine Lizenz-Datei, damit ich auch weiß, das nur die Leute zugriff haben, die einen Account haben. Das könnte man doch ausweiten, das der Lizenz-Key gleichzeitig eine Art Private-Key ist oder nicht? Wenn man dann die Anfragen an den Server richtig machen, nach dem Motto:

SELECT space FROM kunden WHERE privateKey='x';

Dann hätte ich ja das Problem gelöst oder nicht? Wer sein PrivateKey rausrückt und anderen gibt... pech... Das liegt außerhalb meiner Kontrolle.

Oder hat da jemand noch eine andere Idee? Warum ich an XML gedacht habe, ist auch recht einfach zu beantworten, da ich somit für den Client keine Client-DB-Lib brauche, was für MobileDevices sehr von Vorteil ist.

so long
jd

PS: Vielen Dank schonmal für Eure Hilfe.

Und was ist jetzt dein Problem? Ich dachte den Server übernimmt alle SQL-Statements die an den DB-Server geht und bietet eine öffentliche Schnittstelle zur Kommunikation an

rüdiger

jd schrieb:

Jeder der das Programm benutzt, braucht ein Account bei mir. Mit der Client-Software meldet man sich dann via Server-Software an. Nun kann man seinen Account auch konfigurieren, dazu benötige ich ein paar Daten aus der DB (logisch).

Was definitiv ausfällt ist, das sowas im Client steht:
SELECT space FROM kunden WHERE lk='xxxxx-xxxxx-xxxxx-xxxxx-xxxxx';
Das halte ich für Tödlich. Wenn einer etwas überlegt oder rumprobiert, bekommt er meine ganzen Kunden-Daten, soviel zum Thema Datenschutz.

Security by Obscurity ist dumm, das weiß ich, aber mir fällt einfach nichts anders ein. Desswegen habe ich über eine alternatives Kommunikations "Protokoll" nachgedacht. Was natürlich super wäre, wenn ich nichts mit Closed-Source machen muss, denn ich möchte ja das JEDER eine eigene Client-Software für mein Server auf Basis des Protokolls schreiben kann. Nur wie kann ich das Lösen, das es trotzdem sicher ist?

Du willst SQL-Statements an den Server schicken und dort ausführen? Das ist eine sehr sehr große Dummheit. Da muss dir ja nur jemand das SELECT mit einem DELETE austauschen etc. Mach so etwas nicht! Und hier schützt dich Closed-Source-Software in absolut keinster Weise! Closed-Source ist _keine_ Sicherheitsgarantie. Es muss ja nur jemand einen Sniffer anwerfen und sieht, was du da für eine Dummheit begehst!

Oder hat da jemand noch eine andere Idee? Warum ich an XML gedacht habe, ist auch recht einfach zu beantworten, da ich somit für den Client keine Client-DB-Lib brauche, was für MobileDevices sehr von Vorteil ist.

Eine Client-DB-Lib? Ich verstehe nicht ganz was XML damit zu tun hat.

dein problem ist nicht die gpl, sondern dein seltsames verständnis von sicherheit. bau doch eine vernünftige authentifizierung ein, damit sich jeder benutzer mit name und passwort anmelden muss. und sichere die eingaben vom client auf dem server vernünftig ab, wenn erforderlich mit abgestuften zugriffsrechten. verlasse dich niemals auf daten, die vom client kommen.

ein sicherheitskonzept gehört bei einer client-server anwendung eigentlich zur minimalen grundanforderung.

jd

Ok, sorry da habe ich mich falsch ausgedrückt
Das ist mir klar das ich vom Client keine SQL befehle abschicken darf, darum geht es mir ja. Ich will ja eine Schnittstelle bauen. Ich habe da an XML gedacht. Das ich den Clientdaten nicht vertrache ist auch soweit klar. Das es jetzt nun kein GPL problem ist, ist mir auch bewusst, da es ja schon geklärt wurde das Security by Obsecurity der falsche weg ist.

Wenn ich eine Schnittstelle benutze, benötige ich keine Client-Db-Lib, da dann der Client mit SQL nichts zu tun hat. Das war lediglich eine Feststellung. Meine weitergehende Frage ist, wie würdet Ihr die Kommunikations aufbauen?

Client sendet eine Anfrage zum Server. Daraufhin führt der Server eine SQL-Abfrage aus und schickt das Result zum Client zurück.

XML wäre eine Option, wovon mir aber auf Grund von Redundanz abgeraten wurde, siehe weiter oben. Tja, welche Alternativen habe ich?

PS: Das ich ein Sicherheits Konzept brauche ist richtig. Jedoch geht das nicht ohne eine Realisierungsoption. Ohne Ansatzpunkt gibts kein Konzept.

so long

jd schrieb:

PS: Das ich ein Sicherheits Konzept brauche ist richtig. Jedoch geht das nicht ohne eine Realisierungsoption. Ohne Ansatzpunkt gibts kein Konzept.

ohne ansatzpunkt kein konzept, ohne konzept keine anwendung. jedoch:

jd schrieb:

Ich habe eine Client-Server Applikation mit Qt4 geschrieben.

und wie die schon geschriebene applikation passt mit obiger aussage zusammen?

XML wäre eine Option, wovon mir aber auf Grund von Redundanz abgeraten wurde, siehe weiter oben. Tja, welche Alternativen habe ich?

das kommt drauf an, wie groß das datenaufkommen wird. XML ist nicht generell ungeeignet, wahrscheinlich sogar das bequemste. nur nicht unbedingt das effizienteste. JSON wäre eine möglichkeit oder vielleicht auch einfach nur eine kommaseparierte liste. hängt halt stark davon ab, was du eigentlich übertragen willst.

security officer schrieb:

und wie die schon geschriebene applikation passt mit obiger aussage zusammen?

mein deutsch ich muss verbessern noch.

hmm ok. wo fange ich an?

zum ersten:
wer ist Pete Lacey? bringt es irgendetwas, sich um die meinung einer einzelnen person zu scheeren, nur weil sie einen blog schreibt? ich hoffe jetzt keine leute mit personenkult zu diesem Pete Lacey beleidigt zu haben. aber man sollte solche entscheidungen nicht auf der basis eines einzigen blogs einer person fällen.

zum zweiten:
wie alle hier schon geschrieben haben, brauchst du eine bessere architektur. xml und soap sind (trotz aller gegenstimmen) eine gute wahl:

begründung:
- xml und soap sind standards, die derzeit auf so gut wie jeder plattform mit so gut wie jedem framework zumindest im ansatz unterstützt werden. insbesondere java und .net (windows mobile, java mobiles)
- soap verwendet http als transportprotokol. auch dieses ist universell einsetzbar.
- es lassen sich sogar clients mit javascript schreiben.
- du kannst in soap authentifizieren, aber auch das ganze extern über http machen. das würde dir z.b. x509 zertifikate zur authentifizierung ermöglichen. ebenso http digest auth und sogar kerberos oder ntlm. letzteres ist für unternehmen interessant.

soap hat overhead der dann nicht gebraucht wird, wenn man eine beschränke anzahl an systeme verwendet. so wie ich den threadersteller verstanden habe, will er eine möglichst universelle und einfache schnittstelle. soap bietet das - eine korrekt geschrieben wsdl-datei vorausgesetzt.
ich habe selbst an eine soap implementierung mit mod_python geschrieben und dazu die standards für soap und wsdl gelesen. soap und wsdl sind keineswegs so übermäßig kompliziert. in manchen gebieten gebe ich aber zu, dass die standards schwammig sind. das lässt sich aber leicht kompensieren, indem man ein paar tests mit den verschiedenen soap-apis durchführt. das muss man sowieso mit jeder lösung.

soap ist mit sicherheit kein allheilmittel für jede art von soa, aber in diesem fall halte ich es für sinnvoll.

und da ich ja auch nur eine person bin, die hier ihren senf schreibt, solltest du dich auch durch andere quellen informieren. schau dir die apis für soap an. such dir soap beispiele. vergleich soap mit anderen methoden. hmm, das waren meine vorschläge. ich hoffe, sie waren gut genug begründet.

@rüdiger: ist natürlich alles nicht persönlich gemeint. ich hoffe, dass dich mein beitrag nicht beleidigt hat.

rüdiger

besserwisser schrieb:

zum ersten:
wer ist Pete Lacey? bringt es irgendetwas, sich um die meinung einer einzelnen person zu scheeren, nur weil sie einen blog schreibt? ich hoffe jetzt keine leute mit personenkult zu diesem Pete Lacey beleidigt zu haben. aber man sollte solche entscheidungen nicht auf der basis eines einzigen blogs einer person fällen.

Ich weiß nicht wer er ist. Ist ja auch ziemlich unerheblich für die ganze Sache. Man kann sich den Beitrag durchlesen und als Hinweis ansehen.

Andersrum: Wer ist besserwisser? Ist seine Meinung überhaupt etwas wert? Man sollte seine Entscheidung nicht auf einen Beitrag in einem Forum fällen... Merkst du was?

Aber sogar du musst ja zugeben, dass die SOAP-Standards nicht das gelbe vom Ei sind. Warum sollte man nicht etwas einfacheres nehmen, so wie REST (also HTTP direkt)? Jede Plattform mit Internetanschluss wird in irgend einer Form HTTP-Support dabei haben.

Aber im Grunde ist es auch vollkommen egal. Ich denke mal, dass jd viel grundlegendere Verständnissprobleme hat, als die Frage ob er SOAP verwenden sollte oder nicht.

@rüdiger
du hast ansheinend meinen beitrag nicht ganz gelesen. du wirst mir fehler vor, die ich in meinem beitrag schon beantwortet habe. naja... was soll s? ein versuch war es wert. ich hoffe, der threadersteller liest meinen beitrag komplett durch.

ich wünsche ihm viel glück bei der lösung seines problems.