Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #38331

Re: Improve reduce functions of SQLite3 request

Show all headers | View raw

On Wed, 6 Feb 2013 23:33:38 +0000 (UTC), Steffen Mutter
<steffen@webanimations.de> declaimed the following in
gmane.comp.python.general:

> I want a browser user interface based on HTML5, jQuery and jQueryUI, CSS
> on the client side, JSON to submit the data and all stuff to display,
> alter and modify is almost completely done on the client. 

	I'll get back to that "alter and modify" later...

> So the server itself just waits for something to do (en-/decrypt the dat
> a for the referees for example)
> I've seen those commercial handball sites use something like TYPO3,
> they can't even get the easiest things to work I've been asking for,
> even their sites are not SSL secured.

	I'll confess that I've not looked at any such sites -- mainly
because I wouldn't understand enough about the sport to understand why
one would do something one way or another. I'm mainly responding from
the point of view of a general software developer with a bit too much
understanding of relational database theory.

> 
> I don't think normalization would really improve the speed on getting
> the data needed for the user interface, would it?
>
	It may not improve initial speed -- but ideally it should in the end
simplify the data you have to maintain. Any time you have a table design
that requires duplicating data from record to record, you run a risk of
inconsistent data on input.
 
> No it should not. Not even I as the 'master' of the system shall not be
> able to see the referee stuff - see, if the club got teams in higher
> leagues some guys would certainly like to pay referees to lead the game
> in a certain direction... 
> That's why I thought about using GnuPG...
> It's quite easy to use with a plugin, available as a tarball.
> http://packages.python.org/python-gnupg/ 
> I got very exited when I did some tests, but found out that I need a lot
> of entropy to work properly. So I summoned a haveged deamon on my
> systems (available as Debian Squeeze backport)
> 
> 
> That's indeed my idea:
> The GnuPG software on the server handles the keyrings
> and all the decryption for the users. 
> I will force them to use a password for their private
> key, when they initially set up their pub/sec rings so the server can
> decrypt it for them:
>

	Here we get to your "alter and modify". The originator (the person
using the "public" key of a key pair) will NOT be able to come back
later and modify the data -- only the owner of the "secret" key can
decrypt it.

	You've created a "write once" data system. The only operations the
originator will be able to perform are to delete the record, or replace
the contents blindly (and anyone with delete/replace privileges could do
that unless you implement some sort of database privilege scheme that
doesn't use the PKCS system to lock records to the originator user and
to the destination [reading] user).

	Given those restrictions, you might as well just email the encrypted
data to the reader and forget about storing it anywhere.	
 
> They will be asked for their private key when needed the session is SSL
> secured (I use CAcert as CA)  so no externals can spy their password.
>
	In other words -- you are going to use a single session symmetric
encryption system just to transmit a passphrase to unlock a PKCS key.
AND you want the server keyrings to have both public and secret keys for
each user... If I were paranoid, I sure wouldn't trust that. When PGP
was originally released, the recommendation was that the key-rings
should not even be on the computer hard-drive, but on a floppy that the
user would insert only long enough to perform an encryption/decryption
operation -- and PGP then went and wiped any memory that the key had
passed through. GnuPG, as I recall, is an open source replacement based
on PGP after PGP became a commercial product. Only public keys were ever
given to anyone else.
> Okay, I could do some server side scripting to create a save-passwords
> tool, but that would break user privacy and make my efforts useless.
> It thought about doing it this way: The keyring will reside in a
> directory. Every user gets his own directory inside of it for
> the keys, named as their userID. So is easy to pick the right key
> for the logged in user, isn't it?
> 
> > Not to
> > mention you'd need to have a way of transmitting the keys to the
> > appropriate people. 
> 
> Users can get download their individual pub/sec-keyring via https.
> 
> > If you kept the keys on the database, you'd then
> > need a secure way to ensure the proper key for the user was picked --
> > anything that secure could be used to control the direct access to the
> > data itself without encrypting it.
> 
> Er - but the data in the database would be readable, wouldn't it? 
> That's exactly not what I want...
> 
> Maybe my thinking is absolute nonsense:
> If you have an idea, how to get it done in an easier way, there are
> only 2 things to get done: 
> - data in the database needs to be kept save
> - even I can't see it (without breaking spying out the users) 
> - only the users who need it for gameplay can see it
> 
> I am listening
> :-)
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
        wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

Back to comp.lang.python | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Improve reduce functions of SQLite3 request Steffen Mutter <steffen@webanimations.de> - 2013-02-03 09:46 +0000
  Re: Improve reduce functions of SQLite3 request Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2013-02-03 13:11 -0500
    Re: Improve reduce functions of SQLite3 request Steffen Mutter <steffen@webanimations.de> - 2013-02-04 14:30 +0000
      Re: Improve reduce functions of SQLite3 request Dave Angel <davea@davea.name> - 2013-02-04 10:30 -0500
      Re: Improve reduce functions of SQLite3 request Peter Otten <__peter__@web.de> - 2013-02-04 17:29 +0100
      Re: Improve reduce functions of SQLite3 request Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2013-02-04 15:45 -0500
        Re: Improve reduce functions of SQLite3 request Steffen Mutter <steffen@webanimations.de> - 2013-02-04 22:05 +0000
          Re: Improve reduce functions of SQLite3 request Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2013-02-04 18:47 -0500
            Re: Improve reduce functions of SQLite3 request Steffen Mutter <steffen@webanimations.de> - 2013-02-06 09:18 +0000
              Re: Improve reduce functions of SQLite3 request Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2013-02-06 12:26 -0500
                Re: Improve reduce functions of SQLite3 request Steffen Mutter <steffen@webanimations.de> - 2013-02-06 23:33 +0000
                Re: Improve reduce functions of SQLite3 request Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2013-02-07 00:40 -0500
                Re: Improve reduce functions of SQLite3 request Steffen Mutter <steffen@webanimations.de> - 2013-02-07 11:33 +0000
                Re: Improve reduce functions of SQLite3 request Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2013-02-07 13:03 -0500
                Re: Improve reduce functions of SQLite3 request Steffen Mutter <steffen@webanimations.de> - 2013-02-07 22:54 +0000
                Re: Improve reduce functions of SQLite3 request Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2013-02-08 12:17 -0500
                Re: Improve reduce functions of SQLite3 request Steffen Mutter <steffen@webanimations.de> - 2013-02-08 19:59 +0000

csiph-web