Look for places where we are accidentally assigning a returned-by-value
VclPtr<T> to a T*, which generally ends up in a use-after-free.
Change-Id: I4f361eaca88820cdb7aa3b8340212db61580fdd9
Reviewed-on: https://gerrit.libreoffice.org/30749
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
A ZIP storage was unconditionally assumed when calling
showDocumentContentSignatures() for "originally" read-only documents,
i.e. in case the file itself is read-only at a filesystem level.
Change-Id: Iba69000fc396afaf5ab34699e811b5d2c216e2bb
Reviewed-on: https://gerrit.libreoffice.org/30758
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
This was the last problem to be able to counter-sign Acrobat-created PDF
1.6 signatures unlimited number of times.
Change-Id: I24ab80c8516b6fe9c08d57c08907bec70384dc28
Reviewed-on: https://gerrit.libreoffice.org/30757
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
The problem: an object stream provies obj#1 and obj#2, then an
incremental updates provides an updated obj#1'. Then we look up obj#2,
parse the stored objects on-demand, so at the end when later we look up
the first object, we find obj#1, not obj#1'.
An easy workaround would be to never update already existing objects
from object streams, but that would break when an incremental update
provides an object stream.
Fix the problem by parsing stored objects right after tokenizing the
object stream, and not later, on-demand, when we no longer have the
context what objects should be ignored.
This is needed (but not enough) to correctly append a signature at the
end of a PDF file that has both object streams and incremental updates.
Change-Id: I3c1fae5ac26804c8e8cc1984511f43cfa881c97b
Pass an XAdES flag to a couple more functions and adapt to that.
Factor out writeDigestMethod() and writeSignedProperties() from
OOXMLSecExporter::Impl to DocumentSignatureHelper and use them in an
additional place.
Write xd:UnsignedProperties with EncapsulatedX509Certificate. Probably
much more work needed.
Change-Id: I2a0cd1db6dd487b9c7ba256ad29473de3d271cd8
For a default column, now ScAttrArray does not store the default
format. So the case of default pattern from 0 to MAXROW is represented
as nCount = 0 and pData = nullptr in ScAttrArray.
A new ScAttrArray object (aNextColAttrArray) is introduced as a member
of ScTable. This is used to store the formatting of *unallocated*
columns (whose indices are from aCol.size() to MAXCOL).
In next patches for this bug, I plan to refactor table*.cxx functions
related to formatting such that :
1) In formatting setter functions, if colspan of the input range
spans the colrange(aCol.size() to MAXCOL) then instead of
allocating columns, apply that formatting to aNextColAttrArray.
2) In formatting getter (const) functions, if requested colspan has some
intersection with the colrange(aCol.size() to MAXCOL) then use the
formatting info stored in aNextColAttrArray to calculate the formatting
of the input range.
3) In general setter (non-const) functions if we really need to allocate
new columns (example, when data is entered), use the formatting info
stored in aNextColAttrArray to create pAttrArray of the new column.
Change-Id: Ieb56f853209b396d92fdb2c27e39361703576423
Reviewed-on: https://gerrit.libreoffice.org/27828
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Eike Rathke <erack@redhat.com>
Blacklisted intel driver for graphics card Intel(R) HD Graphics 4000 for Windows 8.
With this card LibreOffice won't start.
Change-Id: I3f4e04da7b4d61bddb1e755771b6a9538b596c51
Signed-off-by: Marina Latini <marina@studiostorti.com>
Reviewed-on: https://gerrit.libreoffice.org/30754
Reviewed-by: jan iversen <jani@documentfoundation.org>
Tested-by: jan iversen <jani@documentfoundation.org>
because the start move by wm conflicts with the manual efforts
to position the toolbar.
the move by wm was done to get wayland to move the toolbars, but
(gnome#768128) supporting docking toolbars under wayland is futile
as far as I can see
Change-Id: I502d4617efaf1eb686469e100224e56104ad650d
Reviewed-on: https://gerrit.libreoffice.org/30751
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
Why should clicking on a frame/image in a header act any differently from
a one insde the text body?
(The only time frames (or any kind of fly) required a double click occured
when switching from inside a header to a body-fly or from inside the body
to a h/f-fly. This patch removes that oddball corner-case.)
Now all frames are handled with a single click and there will not be
an impact on double-clicking anymore.
regression caused by 7e2f98d0a0c4a0f36a94353a256e7cc5caa3113b and its
prior commit which say:
> Header/Footer: fixed click on frames over the header/footer area.
> The main problem here was due to the click to show the separator when
> there is no header or footer under the frame. That code was just exiting
> MouseButtonDown too early, which isn't good.
> Now, double-click actually selects a frame anchored in header/footer.
confirmed that single-clicking on frames over the header/footer section
still shows the header blue-line.
Change-Id: I4770cfe7898202929742743931e22de8bf233b03
Reviewed-on: https://gerrit.libreoffice.org/30693
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
This is especially needed, as we don't bother compressing updated
objects into sections on signing, we simply use a separate section for
each updated object.
Work towards supporting xref streams and incremental updates at the same
time.
Change-Id: Ie9759edbba816991615fafc6602cdd440141b989
and account for the libreofficekit changes
This reverts commit 50e9065cbbb2c62fa925cf5b561a85c715a0eb1e.
that did in turn revert 4ae8c3c20bd4a10ba141a32f01e23ac63636f9c3.
Change-Id: Ie02d8743b3608120ed63bfe2a014fa4139577b01
cause of the reported regression, it seems extradinary that this
would cause that, but it seems to be the case and I have no interest
in debugging the undebuggable scheduler.
This reverts commit 180a0eac238ce456771ff20b8d3274b43408f54c.
This can happen when the group calculation is disabled and falls
back to non-group calculations. And we only care about the first
entry in case of non-group calculation of grouped cells.
Change-Id: I545980acf8e35b4d0504aa2a77f86bdc85799e29
Reviewed-on: https://gerrit.libreoffice.org/30738
Reviewed-by: Kohei Yoshida <libreoffice@kohei.us>
Tested-by: Kohei Yoshida <libreoffice@kohei.us>
the linux build / libreofficekit also uses those and needs to be told
about this change as well.
This reverts commit 4ae8c3c20bd4a10ba141a32f01e23ac63636f9c3.
android studio/sdk manager doesn't provide a default way to install
multiple versions of the NDK, so typically only the latest one will be
available. Don't make configure error out in this case, but print a
warning instead.
Change-Id: I6af9a3f088daf7d12ebd9910286d7f44d264014a
Project: help 02139162f541bb56ddbaf0a2d6142256a0454372
digital signatures: briefly document OOXML/PDF signing effort
It may be unexpected for users to see that OOXML files are always only
partially signed.
Change-Id: Ie7c6c553580a4eb38ed72c8a50b75f4b7902613f
...seen a failure of JunitTest_sc_unoapi_3 with
> checking: [sc.ScDDELinkObj::com::sun:⭐:util::XRefreshable] is iface: [com.sun.star.util.XRefreshable] testcode: [ifc.util._XRefreshable]
> LOG> Execute: refresh()
> LOG> starting required method: addRefreshListener()
> LOG> Execute: addRefreshListener()
> Method addRefreshListener() finished with state OK
> LOG> addRefreshListener(): COMPLETED.OK
> warn:unotools.misc:30768:84:unotools/source/misc/mediadescriptor.cxx:690: caught Exception "" while opening <file:///data/lo/core/sc/qa/unoapi/testdocuments/ScDDELinksObj.ods>
> warn:filter.config:30768:84:filter/source/config/cache/typedetection.cxx:455: caught Exception "Could not open stream for <file:///data/lo/core/sc/qa/unoapi/testdocuments/ScDDELinksObj.ods>" while querying type of <file:///data/lo/core/sc/qa/unoapi/testdocuments/ScDDELinksObj.ods>
> Method refresh() finished with state FAILED
and it appears that all of sc.ScDDELinkObj, sc.ScDDELinksObj, and
sc.ScIndexEnumeration_DDELinksEnumeration try to open that file (necessarily for
writing?), and the first two are in JunitTest_sc_unoapi_3 (so are executed
sequentially), but the last one is in JunitTest_sc_unoapi_4 (so may be executed
in parallel with the others), so that may be the reason for such sporadic
failure. Easiest workaround appears to be to move the third test into the same
JunitTest as the other two...
Change-Id: Iefb94cf657bdc9c1eac92dd49ee6257eb5e80905
With this our xref stream output is close enough to Acrobat so that the
existing signature verifier runs without any problems.
Change-Id: I6eca7966890365759c269b465e4bf4d86d335219
...as that, somewhat surprisingly, causes 'make MODULE.all' do additional
targets that a plain top-level 'make' would never do. See discussion in mail
thread starting at
<https://lists.freedesktop.org/archives/libreoffice/2016-November/075797.html>
"[Libreoffice-commits] core.git: Branch 'feature/dialog-screenshots' [...]".
Change-Id: I460f3c91cf00d3398c61833fdcd5eaebdc87fbf2
Its last user was
writerfilter::dmapper::DomainMapperTableHandler::getTable(), removed in
commit 6ea66657ebca5b3ec63f93b496b812888e0d53c9 (loplugin:unusedmethods
writerfilter, 2015-07-20).
Change-Id: Ibaf536d4dd8f01f4413c3cec033db7438501e58c
so we don't have to specify the source type
Change-Id: I4106705a39874a8043f0f294a11374404d6cfc3a
Reviewed-on: https://gerrit.libreoffice.org/30713
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
