Request for comment: GnuPOS - A Point-Of-Sale program

[John Klar]

On Sun, 24 Jun 2001, Josh Sled wrote:

> | - ultimately, some way is going to have to be found to encrypt the data.
> 
> This might devolve into "just use a cryptographic file system" argument
> at some point.  OTOH, it's nice not to have that dependency, especially
> if the focus is on simplicity for the probably-non-technical end-user.
> OTOOH, if the idea is a turn-key system installation, the cryptographic
> file system can already be setup and hidden from the end-user.

(Sorry, I've skimmed the discussion so far, so my assumptions may not be
100% correct.)

I don't think an encrypted filesystem is the solution.  At the very least
it doesn't buy you anything.[2]

You will necessarily need to encrypt the client-backend communications
anyway (assumtion: you ARE planning on multi-station capability yes?)  

The OpenSSL toolkit exposes several layers: high enough to manage a
full-blown SSL session and low enough to provide field level
encryption using a variety of techniques and algorithms.  

But, IIRC, I think the GnuCash team is leaning towards the Mozilla
security library because of license issues [1].  I'm not familiar with the
Mozilla offering, but it too probably allows field level encryption.

John

[1] Even RMS (grudgingly) considers OpenSSL linkage into a GPL'd program
not a violation of the GPL.  He may have changed his mind since, but I
believe that was the resolution of the KDE v. OpenSSL GPL dustup.

[2] My gut's telling me an encrypted fs would give you a false sense of
security as well.  The decryption keys are specified during volume
mount.  Either that or you need to specify them during every I/O operation
and I'm not aware of any project to make that API available.