Date: prev next · Thread: first prev next last
2017 Archives by date, by thread · List index


Hi Michael,

On Fri, Aug 18, 2017 at 6:32 AM, Michael Stahl <mstahl@redhat.com> wrote:

On 17.08.2017 17:10, Ashod Nakashian wrote:
Hi Thorsten,

On Wed, Aug 16, 2017 at 5:22 AM, Thorsten Behrens <thb@libreoffice.org
<mailto:thb@libreoffice.org>> wrote:

    Miklos Vajna wrote:
    > The idea is that per-paragraph signature should be non-chained,
similar
    > to per-document signatures, so the Writer field(s) representing the
    > signature(s) should be filtered out before hashing, but otherwise
this
    > just takes the paragraph text as-is. (My understanding is that ODF
    > specifies what is the exact paragraph string for a <text:p>
element.)
    >
    Hi Miklos,

    ok - as long as that could be described (or pseudo code given),
    that'll do I guess. Just be aware that text:p can still be quite
    complex in xml, with whitespace mangling & all sorts of child
elements
    (see paragraph-content-or-hyperlink / paragraph-content in the
    schema).


The code currently in master was a temporary first step. The logic I
currently have locally ready to push soon is to only use Text portions.

Roughly as follows:

  OUStringBuffer strBuf;
  for (auto& portion : paragraphTextPortions) {
      if (portion.TextPortionType == "Text")
          strBuf.append(portion.Text);
  }
  sign(strBuf.makeStringAndClear());

I expect this should exclude any unwanted fields/characters/LO-specific
conversions etc.

Let me know if there are concerns with this approach.

there are some other portions that, depending on what you want to do,
could be interpreted as containing text:


Thanks, I think these should be considered for inclusion. Currently I'm
excluding anything that isn't TextPortionType=="Text", so it's limited
coverage.



there are various other functions to get "cleaned up" text from a
paragraph, such as SwTextNode::GetExpandText() and class
ModelToViewHelper but i'm not even sure why there are several different
ones and when to use which one.


These don't seem to give us what we need, and I couldn't find an
obvious/easy way to extend them. GetExpandText uses ModelToViewHelper, so I
tried using ModelToViewHelper with Replace but (though it should've worked)
since it depends on the hints to be up-to-date, it's failing (at least in
some scenarios hints are empty, which means it returns the display text as
default, which includes all fields).

For now I have a small helper (sadly, which adds yet another way of getting
"cleaned up" text) that uses the UNO API to enumerate the text portions of
the current TextNode and constructs the text to be signed per the above
pseudo-code. Ideally we'll convert that to internal API and extend
ModelToViewHelper with a new flag/enum to return signable text. Hopefully
I'll get to it once I reach a stable milestone.

Thanks,
-Ash

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.