IRC logs of #tryton for Saturday, 2011-08-13

chat.freenode.net #tryton log beginning Sat Aug 13 00:00:02 CEST 2011
-!- Ildin_(~chatzilla@184-76-111-12.war.clearwire-wmx.net) has joined #tryton00:33
-!- alimon(alimon@187.156.94.122) has joined #tryton01:13
-!- elbenfreund(~elbenfreu@g225208201.adsl.alicedsl.de) has joined #tryton01:30
-!- elbenfreund(~elbenfreu@g225208201.adsl.alicedsl.de) has joined #tryton01:45
-!- elbenfreund(~elbenfreu@g225208201.adsl.alicedsl.de) has joined #tryton02:10
-!- ikks(~ikks@190.27.84.116) has joined #tryton03:54
-!- lem0na(~lem0na@95.87.233.210) has joined #tryton04:40
-!- alimon(~alimon@187.156.94.122) has joined #tryton04:41
-!- yangoon(~mathiasb@p54B4FCCC.dip.t-dialin.net) has joined #tryton05:15
-!- okko1(~okko@dhcp-077-251-140-095.chello.nl) has joined #tryton06:53
-!- cedk(~ced@gentoo/developer/cedk) has joined #tryton08:51
-!- FWiesing(~franz@mail.tryton.at) has joined #tryton10:18
-!- okko1(~okko@dhcp-077-251-140-095.chello.nl) has joined #tryton11:59
-!- pjstevns(~pjstevns@helpoort.xs4all.nl) has joined #tryton12:15
-!- pjstevns(~pjstevns@helpoort.xs4all.nl) has left #tryton12:15
-!- yangoon(~mathiasb@p54B4FCCC.dip.t-dialin.net) has left #tryton13:04
-!- yangoon(~mathiasb@p54B4FCCC.dip.t-dialin.net) has joined #tryton13:05
-!- okko1(~okko@dhcp-077-251-140-095.chello.nl) has joined #tryton13:14
-!- okko1(~okko@dhcp-077-251-140-095.chello.nl) has joined #tryton14:19
-!- okko1(~okko@dhcp-077-251-140-095.chello.nl) has joined #tryton14:31
-!- ikks(~ikks@186.28.69.11) has joined #tryton14:59
-!- okko1(~okko@dhcp-077-251-140-095.chello.nl) has joined #tryton15:07
-!- ciupicri(~ciupicri@81.180.234.249) has joined #tryton16:49
-!- okko1(~okko@dhcp-077-251-140-095.chello.nl) has joined #tryton17:17
-!- alimon(~alimon@187.156.94.122) has joined #tryton17:30
-!- serpent223(~digger@teralink.net) has joined #tryton17:43
-!- alimon(~alimon@187.156.94.122) has joined #tryton18:15
-!- pjstevns(~pjstevns@helpoort.xs4all.nl) has joined #tryton19:11
-!- pjstevns(~pjstevns@helpoort.xs4all.nl) has left #tryton19:11
-!- elbenfreund(~elbenfreu@f055208249.adsl.alicedsl.de) has joined #tryton19:42
version2betacedk: Got time for more security discussion? This time about the SSL communication between client and server - looking for clarification on how it works.19:48
cedkversion2beta: ok19:48
version2betacedk: The client has a ca_cert file available and the built-in ssl library accepts it if it's there. I can't tell (due to my own python ignorance)  on the server if it's pysocket.py or xmlrpc.py that's responsible for setting up the connection. pysocket.py uses the ssl library built in beginning in 2.6, and xmlrpc.py uses the OpenSSL library. So I'm wondering if either of them are already able to validate the identity of the (client) peer?19:50
cedkversion2beta: on the server side all SSL connection is managed by OpenSSL module19:53
cedkversion2beta: and no the server doesn't validate the identity of the client because it is done with the login/password19:53
version2betacedk: what does pysocket.py do? Is that only used when the client and server are on the same machine? Please forgive my ignorance - long time since I programmed sockets.19:54
version2betacedk: It appears that the client is already capable of using an X509 certificate, which would (with username/password) provide two-factor authentication, right?19:55
cedkversion2beta: pysocket implement the netrpc protocol19:55
version2betacedk: pysocket - thank you.19:55
cedkversion2beta: no the client doesn't use X509 certificate19:55
cedkversion2beta: it has a CA file to check the certificate of the server19:56
cedkversion2beta: if you really want this kind of auth, I suggest you to use a VPN19:56
version2betacedk: Ah - I see, yes, it's ca_certs that are set, not certfile.19:57
version2betacedk: Yes, I would use a VPN for this level of auth. Still working on yesterday's conversation and exploring whether the presence of pki key pairs might be used for two-factor authentication.19:58
version2betacedk: Thank you for your help.20:00
cedkversion2beta: I guess you could patch the client to use a certificate and the server to validate it20:00
version2betacedk: Patching isn't nice - breaks updates too much. I'd either want to convince you to support it, or make it work as a plugin (no idea if that's even possible.) ;-)20:01
cedkversion2beta: indeed I don't understand the requirement, the current design is the common way which is used for net-banking etc.20:05
-!- bechamel(~user@host-85-201-144-79.brutele.be) has joined #tryton20:07
version2betacedk: For network communication I have no problem with it at all. I might choose a VPN only to limit the publicly accessible ports. For files, though, I feel confident that the appropriate level of security is that the decryption key does not live on the same server as the encrypted files, and that decryption of the files (not access to decrypted files) must be limited by the user's access rights. I know it goes further than many systems would, but it's20:10
version2betareally the basis of GPG.20:10
version2betacedk: But we had that conversation yesterday, and I got a lot out of it. I appreciate your feedback. Today's question really was just a tangent.20:11
version2betacedk: Now I need to go pick up the kids. ;-)20:11
cedkversion2beta: ok indeed I'm just affraid that the GUI will become complicate with such feature but if you can do it simple why not20:17
-!- elbenfreund(~elbenfreu@f055208249.adsl.alicedsl.de) has joined #tryton20:43
-!- elbenfreund(~elbenfreu@f055208249.adsl.alicedsl.de) has joined #tryton21:32
-!- okko1(~okko@dhcp-077-251-140-095.chello.nl) has joined #tryton22:46

Generated by irclog2html.py 2.11.0 by Marius Gedminas - find it at mg.pov.lt!