Subversion & clientseitige PW-Verschlüsselung ohne X11

Hackse

Hackse

0
Hallo,

http(s)-Checkout via Subversion legt das Passwort "schön" im Klartext ins Home-Verzeichnis. :rolleyes: KDE-Wallet oder Gnome-Keyring sind für die Verschlüsselung des Passwortes auf einem konsolenbasierten Server völlig oversized:

Code: 
The following extra packages will be installed:
  cpp cpp-4.3 dbus dbus-x11 fontconfig gconf2 gconf2-common hicolor-icon-theme libatk1.0-0 libatk1.0-data libcairo2 libcups2 libdatrie0 libdbus-1-3 libdirectfb-1.0-0
  libfontenc1 libgconf2-4 libgmp3c2 libgtk2.0-0 libgtk2.0-bin libgtk2.0-common libhal-storage1 libhal1 libidl0 libmpfr1ldbl liborbit2 libpam-gnome-keyring libpango1.0-0
  libpango1.0-common libpixman-1-0 libsysfs2 libthai-data libthai0 libtiff4 libts-0.0-0 libx11-6 libx11-data libxau6 libxcb-render-util0 libxcb-render0 libxcb-xlib0
  libxcb1 libxcomposite1 libxcursor1 libxdamage1 libxdmcp6 libxext6 libxfixes3 libxfont1 libxft2 libxi6 libxinerama1 libxrandr2 libxrender1 x-ttcidfont-conf x11-common
  xfonts-encodings xfonts-utils
Suggested packages:
  cpp-doc gcc-4.3-locales cups-common librsvg2-common ttf-kochi-gothic ttf-kochi-mincho ttf-thryomanes ttf-baekmuk ttf-arphic-gbsn00lp ttf-arphic-bsmi00lp
  ttf-arphic-gkai00mp ttf-arphic-bkai00mp
The following NEW packages will be installed:
  cpp cpp-4.3 dbus dbus-x11 fontconfig gconf2 gconf2-common gnome-keyring hicolor-icon-theme libatk1.0-0 libatk1.0-data libcairo2 libcups2 libdatrie0 libdbus-1-3
  libdirectfb-1.0-0 libfontenc1 libgconf2-4 libgmp3c2 libgtk2.0-0 libgtk2.0-bin libgtk2.0-common libhal-storage1 libhal1 libidl0 libmpfr1ldbl liborbit2
  libpam-gnome-keyring libpango1.0-0 libpango1.0-common libpixman-1-0 libsysfs2 libthai-data libthai0 libtiff4 libts-0.0-0 libx11-6 libx11-data libxau6
  libxcb-render-util0 libxcb-render0 libxcb-xlib0 libxcb1 libxcomposite1 libxcursor1 libxdamage1 libxdmcp6 libxext6 libxfixes3 libxfont1 libxft2 libxi6 libxinerama1
  libxrandr2 libxrender1 x-ttcidfont-conf x11-common xfonts-encodings xfonts-utils
0 upgraded, 59 newly installed, 0 to remove and 0 not upgraded.
Need to get 21.8MB of archives.
After this operation, 62.6MB of additional disk space will be used.
Gibt es eine in SVN rein konsolenbasierte Alternative?

Greetz
Hackse
 
Was hindert dich daran das Caching des Passworts mit 'store-passwords = no' abzuschalten?

Im übrigen kannst du dich beim nicht existierenden Unix-Standard für Keychains bedanken, dass das Passwort im Klartext gespeichert wird. Denoch gilt, dass die auth/ (also der Password-Caching-Ordner) nur für den anlegenden User lesbar ist und somit nicht von anderen User des Rechners eingesehen werden kann. Unter Windows wird der Standard-Verschlüsselungsdienst genutzt und auf einem Mac wird das Passwort im Standard-Schlüsselbund verschlüsselt abgelegt. Das Problem ist also nicht SVN sondern dein System. Alle mir bekannten SVN-Clients für Unix und Linux nutzen die libsvn und somit haben sie alle das gleiche Verhalten.
 
Was hindert dich daran das Caching des Passworts mit 'store-passwords = no' abzuschalten?
Zum Vergrößern anklicken....
Die hohe Frequenz der notwendigen Zugriffe auf unterschiedliche Repository-Bereiche und der damit verbundene Umstand der permanenten Passworteingabe hindern mich daran. Vielleicht wird es dennoch darauf hinauslaufen.

Mac oder Windows kommen nicht in Frage. Es handelt sich um einen V-Server. Mir wäre Free-BSD recht gewesen, aber der Server-Provider bietet ausschließlich Linux-Derivate an, ergo setze ich auf Debian.
 
Dann wirst du mit dem Zustand wohl leben müssen, denn auch *BSD bietet keine zentrale/standardisierte Schlüssel/Passwort-Verwaltung. Aber wenn die Kiste ausreichend gesichert ist, dürfte ja aufgrund der eingeschränkten Rechte niemand an das Passwort kommen können. SELinux bietet sich evtl. als Erweiterung an. Damit könntest du eine SVN-Rolle für den User definieren, und nur wer diese Rolle hat, darf dann auf die Passwort-Datei zugreifen, unabhängig davon, ob er im gleichen User-Kontext ist.
 
Bin mittlerweile bereits am überlegen, ob ich den Zugriff auf das Repository via svn+ssh gestatte, auf der Serverseite die SVN-User Shell auf /bin/false setze und den Public Key verteile, um die dauerhafte Passwort-Eingabe zu ersparen. :rolleyes:
 
Damit wäre ja nicht wirklich geholfen, da der Private Key die gleichen Zugriffsrechte wie das auth-Verzeichnis hätte und somit genauso leicht entwendbar wäre wie das Passwort aus dem auth-Verzeichnis.
 
Ja, das stimmt natürlich. War auch eher ein Akt der Verzweiflung.

Schwer vorstellbar, dass ein solches Verhalten von Subversion von tausenden Entwicklern scheinbar stillschweigend hingenommen wird, es sei denn ich bin einer der Wenigen, die Subversion auf der Konsole verwenden und graphische SVN-Clients meiden, die wiederum Wallet und Keyring supporten.

Dann muss ich wohl selbst ein kleines Crypto-Addon für Subversion schreiben.
 
Ich denke, dass es viele Subversion-User gibt, die sich freuen würden, wenn jemand endlich mal wenigstens MD5-gehashte Passwörter direkt in Subversion für Unix-Systeme einbauen würde. Das wäre vermutlich sogar gar keine sooo riesige Aufgabe, da man ja über das configure-Skript beim kompilieren eh prüft welches System vorliegt und entsprechend eine '#if defined'-Direktive in die entsprechenden Teile des Source einbauen könnte. Ich vermute, dass den meisten Usern gar nicht bewusst ist, dass ihr Passwort unverschlüsselt auf der HDD liegt und die, die es wissen, begnügen sich mit den eingeschränkten Zugriffsrechten. Zeitgemäss wäre natürlich eine richtige Verschlüsselung mit entsprechendem Master-Passwort. Das Subversion-Projekt wird einen entsprechenden Patch evtl. sogar gern aufnehmen, wenn er sauber umgesetzt ist.
 
Um antworten zu können musst du eingeloggt sein.
Zurück
Oben