h1. Meeting Log 03.05.2010 - 20:00 / mumble Present: Apophis, dergringo, Vanadis, cockroach, Simon Rupf, Corvus, Exception Lead meeting: Corvus Log writer: dergringo h1. Issues h2. Overview I = Information D = Discussion V = Vote |_. Title |_. I |_. D |_. V | | Status Reports: Mail (Syncom, SpamAssassin), Web (Drupal 2.0, Forum NG, Wiki NG), E-Voting (PiVote), MemberDB/LDAP | x | | | | Server Request by e-Voting | x | x | | Project Hosting (camp2010) | x | x | (x) | | Security for the connection Drupal to LDAP | | x | | h2. Detailed h3. Status Reports Every DI Sub Project gives a short overview about the things that were going on. h3. Server Request by e-Voting The e-Voting project has requested a virtual machine for a first alpha test at "http://forum.piratenpartei.ch/viewtopic.php?f=149&t=2074":http://forum.pirate%20npartei.ch/viewtopic.php?f=149&t=2074 h3. Project Hosting There was a request by Christian Loosli / Moira Bruelisauer to host the application form for the pirate camp this summer. ("http://wiki.piratenpartei. ch/wiki/Piratencamp2010":http://wiki.piratenpartei.ch/wiki/Piratencamp2010) * How do we want to handle those pirate related projects? * What's the hostname we want to use for this? Some suggestions: sub.piratenpartei.ch/camp2010 / projects.piratenpartei.ch/camp2010 / camp2010.piratenpartei.ch. (Request from the camp orga: camp.piratenpartei.ch) * Who will administrate such subsites and who will review the code? * Additionally the camp responsible requested an application for the subscription. The application would be a web from, which can be filled in and submitted by users without technical knowledge. The camp administrators should be able to get a list of subscriptions and to edit this list. In the worst case this could be done directly via SQL, a user friendly form would be nice though. Can this be done by AG DI? h3. Security for the connection Drupal to LDAP Drupal needs the authority to edit data in the LDAP-database. The integration module comes with two approaches. * The first one uses a configured user which is stored globally (plain password). This user needs to have wide access to LDAP. A hijacking of this user compromises most of the database (read access to almost everywhere and many fields writeable). * The second one uses the users password which is stored in plain for the duration of the session. A hijack of one of this accounts gives authority depending on the ACL's in the worst case the account is an admin. * There is also the possibility that drupal needs no password. This means that every access from the drupals IP have the access described in the first situation. Which of this solutions should we use? Are there other methods not mentioned yet?