Was wünscht ihr euch in die Standardlib?

Alles, was nicht direkt mit Python-Problemen zu tun hat. Dies ist auch der perfekte Platz für Jobangebote.
poker
User
Beiträge: 146
Registriert: Donnerstag 20. September 2007, 21:44

Ich wünsche mir folgendes in der stdlib:
  • * simplejson
    * coverage bzw. das aufgebohrte coverage figleaf
    * py.test -- Eigentlich kann gleich die ganze py lib rein ;)
    * SimpleParse
    * feedparser
    * Ein vernümftigen Support für AOP, und damit meine ich nicht die pseudo Implementierungen wie http://www.cs.tut.fi/~ask/aspects/aspects.html sondern sowas wie AspectJ oder PyPy's AOP Implementierung :)
    Kurz: Eine unabhängige Definierung der Aspekte und gleich einsatzfähig ohne den betroffenen Code mit dem Aspekt wrappen zu müssen!! => AspectJ-like
mfg
Benutzeravatar
jens
Python-Forum Veteran
Beiträge: 8502
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Ich wünschte mir, es gäbe mehr in Richtung Verschlüsselung direkt in Python. Das könnte dann z.B. direkten Zugriff auf SSH/sFTP/https ermöglichen, ohne externe Libs.

GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
Benutzeravatar
veers
User
Beiträge: 1219
Registriert: Mittwoch 28. Februar 2007, 20:01
Wohnort: Zürich (CH)
Kontaktdaten:

jens hat geschrieben:Ich wünschte mir, es gäbe mehr in Richtung Verschlüsselung direkt in Python. Das könnte dann z.B. direkten Zugriff auf SSH/sFTP/https ermöglichen, ohne externe Libs.
Bill Janssen hat das SSL Modul für Python 2.6 ziemlich aufgebohrt. So sind nun endlich Server Sockets sowie die Validierung von Zertifikaten möglich. Was allgemeine Kryptographische Werkzeuge angeht sieht es leider noch immer etwas düster aus. Mit PEP 272 gibt es zwar eine Empfehlung für die API für solche jedoch wurde noch nichts integriert. Den Grund dafür kenne ich nicht. Ich befürchte es sind/waren mal wieder die Amerikanischen Export Restriktionen daran Schuld. Hat da jemand nähere Informationen dazu? Mit PyCrypto gib es zumindest ein gut wirkendes Modul dafür. :)
[url=http://29a.ch/]My Website - 29a.ch[/url]
"If privacy is outlawed, only outlaws will have privacy." - Phil Zimmermann
lunar

veers hat geschrieben:Den Grund dafür kenne ich nicht. Ich befürchte es sind/waren mal wieder die Amerikanischen Export Restriktionen daran Schuld. Hat da jemand nähere Informationen dazu?
Die Exportrestriktionen können es eigentlich nicht sein, da diese iirc schon seit 2001 so gelockert wurden, dass die Standardalgorithmen problemlos in Binär- und Quellform exportiert werden können.

Ich würde mir auch nicht wirklich eine Implementierung der Algorithmen wünschen. Man sollte den Fokus lieber auf qualitativ hochwertige und sichere Implementierungen der Standardprotokolle (https, sftp, ssh, gpg) legen. Dadurch kommen die Algorithmen von selbst, und man hat das, was man wirklich braucht. Würden nur die Algorithmen in der Standardlib auftauchen, würden die Leute eventuell anfangen, https selbst zu implementieren. Sowas geht wahrscheinlich schief, besonders wenn man nicht viel Ahnung von der Materie hat.
Benutzeravatar
veers
User
Beiträge: 1219
Registriert: Mittwoch 28. Februar 2007, 20:01
Wohnort: Zürich (CH)
Kontaktdaten:

Du bist also dagegen die Grundlegenden Algorithmen zugänglich zu machen weil du den Benutzern nicht zumutest diese richtig Anzuwenden? :? Und wie soll jemand zum Beispiel SSH implementieren ohne auf die zu Grundeliegenden kryptographischen Funktionen zur Verfügung zu haben? Für mich ist es wichtiger das die stdlib die Grundsätzlichen Funktionen zur Verfügung stellt. Insbesondere wenn diese in C geschrieben sein müssen.

BTW: SSL richtig anzuwenden ist vermutlich schwieriger als einen String vernünftig mit einem Blockcipher zu verschlüsseln. :wink:
[url=http://29a.ch/]My Website - 29a.ch[/url]
"If privacy is outlawed, only outlaws will have privacy." - Phil Zimmermann
lunar

veers hat geschrieben:Du bist also dagegen die Grundlegenden Algorithmen zugänglich zu machen weil du den Benutzern nicht zumutest diese richtig Anzuwenden? :?
Nein. Ich bin dagegen, auf Teufel komm raus Algorithmen in die Standardbibliothek zu schmeißen, und dann dem Anwendungs-Programmierer den Rest zu überlassen. Das ist kontraproduktiv, vernünftige Programmierer würden sowieso Bindings zu bereits existierenden Implementierungen von Protokollen (z.B. openssl) nehmen, und diejenigen, die Protokolle mit den Algorithmen selbst implementieren, schreiben höchstwahrscheinlich Mist zusammen. Die Algorithmen wären also von vernünftigen Programmierern ungenützt, oder von unvernünftigen Programmierern in schlechter Software eingebaut...

Ich bin allerdings dafür, die Standardprotokolle in der Standardbibliothek zu implementieren. Dabei fallen die Algorithmen sowieso an (SSH kommt in der Regel nicht ohne AES aus), also kann man auch ein Paket mit Algorithmen zur Verfügung stellen. Dann könnten Programmierer auf die Implementierungen der Protokolle zurückgreifen, und die Algorithmen müssten nur genutzt werden, wenn es wirklich erforderlich ist, eigene Protokolle zu entwerfen.
Und wie soll jemand zum Beispiel SSH implementieren ohne auf die zu Grundeliegenden kryptographischen Funktionen zur Verfügung zu haben?
Gar nicht, weil SSH natürlich bereits in den Standardbibliothek implementiert ist, und man das ssh-Modul direkt benutzen kann. Das ist zum einen wesentlich sicherer, zum anderen wesentlich bequemer für den Programmierer.
Für mich ist es wichtiger das die stdlib die Grundsätzlichen Funktionen zur Verfügung stellt. Insbesondere wenn diese in C geschrieben sein müssen.
Damit sich jeder seinen eigenen Mist zusammenbasteln kann?
BTW: SSL richtig anzuwenden ist vermutlich schwieriger als einen String vernünftig mit einem Blockcipher zu verschlüsseln. :wink:
Das kannst du nicht vergleichen. SSL ist ein komplexes Protokoll. Ein String zu verschlüsseln höchstens ein kleiner Teil eines Protokolls. Das Problem ist, dass viele mangels Zugriff auf Standardprotokolle ihre eigenen Pseudoprotokolle entwickeln, die meistens auf sehr miesem Sicherheitsniveau liegen.

Als Beispiel kann man das sichere Speichern von Dateien nehmen:
Man kann alles selbst implementieren: Das Signieren, das Entschlüsseln, das Abfragen des Passworts, Erzeugung und Austausch des Schlüssels, etc. Das Ergebnis ist, gerade wenn der Programmierer wenig Ahnung hat, höchstwahrscheinlich unsicher und dazu noch anwendungsgebunden.

Oder man kann gnupg die Auswahl des Schlüssels, die Abfrage des Passworts, das Signieren der Datei, das Verschlüsseln der Datei, etc. überlassen. Im besten Fall reduziert sich der Prozess für den Anwendungsprogrammierer auf ein simples gpg.encrypt(data). Gpg könnte dann anhand der UID den passenden Schlüssel auswählen, und die Verschlüsselung vollziehen. Dieses Programm ist nun höchstwahrscheinlich ziemlich sicher, und noch dazu können die Dateien mit gpg selbst entschlüsselt werden und sind so nicht abhängig von der Anwendung.

Zudem sind solche Protokolle nicht interoperabel, was dazu führt, dass keine andere Anwendung derart verschlüsselte Daten lesen kann.
Antworten