On Sat, 2012-08-25 at 15:25 +0200, Arnaud Versini wrote:
> I posted a first patch to remove the string anhnilation inside the PDF
> import. Better idea to remove this now instead of replacing
> rtl_zeroMemory by a memset and remove it. So could you review it, I'm
> not sure if I can modify pdf impo
I posted a first patch to remove the string anhnilation inside the PDF
import. Better idea to remove this now instead of replacing rtl_zeroMemory
by a memset and remove it. So could you review it, I'm not sure if I can
modify pdf import now or if we want to import modification from Apache.
https:/
On 24/08/12 12:53, Caolán McNamara wrote:
> On Thu, 2012-08-23 at 21:00 +0200, Arnaud Versini wrote:
>> Hi everyone,
>>
>> I noticed in the code some annihilation of O[U]String content by using
>> memset or rtl_zeroMemory directly on the content as a password
>> security. It breaks encapsulation an
On Thu, 2012-08-23 at 21:00 +0200, Arnaud Versini wrote:
> Hi everyone,
>
> I noticed in the code some annihilation of O[U]String content by using
> memset or rtl_zeroMemory directly on the content as a password
> security. It breaks encapsulation and the string immutability, not so
> good. I thin
> that is true for the document that is protected by the password.
> but in practice that same password may not only give access to that one
> document, but also let an attacker do other nefarious things like log on
> to twitter and impersonate the user's cat.
>
Hmm, but why use password-protected
On 23/08/12 22:15, Tor Lillqvist wrote:
> But if the password is used to load or save encrypted documents, then
> the contents of the document (which the so carefully erased password
> protects) is loaded into memory in plain-text, and is equally readable
> by an adversary that has access to the vi
But if the password is used to load or save encrypted documents, then the
contents of the document (which the so carefully erased password protects)
is loaded into memory in plain-text, and is equally readable by an
adversary that has access to the virtual memory of your process, and might
get page
On 23/08/12 21:12, Tor Lillqvist wrote:
> 1. Don't eradicate the string content,
>
> I vote for this. Overwriting password in memory after use is security
> theater.
well it doesn't protect against every threat but i wouldn't call it mere
theater; if you don't overwrite the password it may w
>
>
>1. Don't eradicate the string content,
>
> I vote for this. Overwriting password in memory after use is security
theater.
--tml
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoff
