RE: [discuss] Openoffice Security Issue => _not_ a security issue?
Bruce Martin
It is possible in that case that Oo needs to automatically encrypt Calc
sheets where sheet protection is activated, but not necessarily require a
password to open the file unless the file is saved with one.
This would seem to me to mean the need for a "front end" layer to the
encryption module that would handle the operation of the encryption
appropriately for all cases.
Hence, if a user were to protect one or more sheets, the whole workbook
would automatically be encrypted, but, when saved would not necessarily
force the use of a password at the file level.
When it was reopened, (assuming it was not saved with a file level password)
it would then decrypt on the fly only the unprotected areas. If the user
then needed to unlock one or more sheets, those sheets would be decrypted on
the fly when they were unprotected. If they were subsequently re-protected,
they would re-encrypt on the fly.
I would think that both this "front end" and the encryption itself should be
fully compiled as one section, and, if possible itself encrypted to
discourage hacking of itself. This should render Oo to be viable in places
where significant money is involved, and where there is that kind of money,
there should be money in the woodwork to better support Oo and java
development.
I think, unpleasant as the thought may be, that in present times where the
economy is not doing well, and there may be a higher general propensity of
various individuals to gain their money in wrongful ways, such as hacking
and misappropriation in many places, «Vaut mieux prévenir que guérir!» ("A
stitch in time saves 9.")
Cheers, all
Bruce Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: discuss-u...@openoffice.org
For additional commands, e-mail: discus...@openoffice.org
Daniel Rentz
Malte Timmermann schrieb:
> Cell protection is a pure UI feature. The content is not encrypted in
> the document (except for password protected documents).
>
> So this issue might end up in a missing feature in Calc (cell protection
> doesn't work w/o sheet protection), or in a bug that the xls import
> filter doesn't recognize this feature.
Cell protection depending on sheet protection is intended. This
behaviour is equal in Calc and Excel.
Regards
Daniel
Malte Timmermann
short answer - encryption only makes sense when the key is provided from
the user, or some other source, like a private key certificate.
It is not possible for OOo to encrypt anything on it's own w/o using a
static hard coded password, or using a random password and store it in
the document. So in one situation you can find it in the source, in the
other situation you can find it in the document.
Malte.
Bruce Martin wrote, On 10/30/09 14:29:
> Good Morning Malte:
>
> It is possible in that case that Oo needs to automatically encrypt Calc
> sheets where sheet protection is activated, but not necessarily require a
> password to open the file unless the file is saved with one.
>
> This would seem to me to mean the need for a "front end" layer to the
> encryption module that would handle the operation of the encryption
> appropriately for all cases.
>
> Hence, if a user were to protect one or more sheets, the whole workbook
> would automatically be encrypted, but, when saved would not necessarily
> force the use of a password at the file level.
>
> When it was reopened, (assuming it was not saved with a file level password)
> it would then decrypt on the fly only the unprotected areas. If the user
> then needed to unlock one or more sheets, those sheets would be decrypted on
> the fly when they were unprotected. If they were subsequently re-protected,
> they would re-encrypt on the fly.
>
> I would think that both this "front end" and the encryption itself should be
> fully compiled as one section, and, if possible itself encrypted to
> discourage hacking of itself. This should render Oo to be viable in places
> where significant money is involved, and where there is that kind of money,
> there should be money in the woodwork to better support Oo and java
> development.
>
> I think, unpleasant as the thought may be, that in present times where the
> economy is not doing well, and there may be a higher general propensity of
> various individuals to gain their money in wrongful ways, such as hacking
> and misappropriation in many places, �Vaut mieux pr�venir que gu�rir!� ("A
> stitch in time saves 9.")
>
> Cheers, all
>
> Bruce Martin
>
>