Age | Commit message (Collapse) | Author |
|
https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/NSS_3.35_release_notes
NSS 3.35 and later will automatically migrate migrate profiles from the
old "dbm:" BDB format to the new "sql:" SQLite format.
The new format can be read by NSS 3.12 and later, which is old enough that
it can be assumed to be available.
However LibreOffice still shouldn't migrate the profile on its own:
LO typically uses a Mozilla Firefox or Thunderbird profile, and if it is
a system Firefox with system NSS libraries, then it's probably a bad
idea for LO to migrate the profile under Firefox's nose, particularly
considering the "partial migration" scenario if the profile is
password-protected.
Try to avoid this by checking if the profile is the old format and
explicitly using the "dbm:" prefix to prevent the migration.
Change-Id: I06480522f830ce74e2fb7bf79fee84ad80979b82
Reviewed-on: https://gerrit.libreoffice.org/58756
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
(cherry picked from commit 61688aa1abd9db9adbb8dc5d5aacc6269b21fd27)
Reviewed-on: https://gerrit.libreoffice.org/58974
(cherry picked from commit dc5474b2e2f361eec981c6955630dbb020442eae)
|
|
Leaving Signer as an empty reference will do exactly what we want: the
signature will be considered invalid.
(cherry picked from commit 18aa83acfa243741eb4c79a2e11aec6eaf1a9f02)
Change-Id: I25d7cbd260384110173fe953fc24f3dcf6b9acd5
Reviewed-on: https://gerrit.libreoffice.org/37813
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I474968d566a31fba29bcdc1f74749de8e86fedce
Reviewed-on: https://gerrit.libreoffice.org/33754
Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
Tested-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
(cherry picked from commit 1478f81f236b88377293432a642def218e228145)
Reviewed-on: https://gerrit.libreoffice.org/33780
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
Tested-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
|
|
The code already knew if the signature was AdES-enabled or not, but that
info wasn't available on the UI.
The values are all names of standards, Andras says it's OK to have them
non-translatable.
(cherry picked from commit 81f7824a9839d3230b4e58424a64a393e8ee0223)
Change-Id: I20baf0871fe2c84b04b7fc64014061e341744db8
Reviewed-on: https://gerrit.libreoffice.org/31724
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
|
|
This was the last unit test that was disabled on Windows due to missing
implementation.
(cherry picked from commit e58ed17e35989350afe3e9fd77b24515df782eac)
Change-Id: Ia7d84f72bcdf79267c7de17cd8822ed02c378642
Reviewed-on: https://gerrit.libreoffice.org/31618
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Miklos Vajna <vmiklos@collabora.co.uk>
|
|
That is what the default libxmlsec error handler,
xmlSecMSCryptoErrorsDefaultCallback(), does. Why show less information
in our own handler?
Also, bin a copy-pasted comment that is meaningless here and a useless 'using'.
Change-Id: Ibc9f9b5066536d0f5cabbf2bda6d1fa14eca5613
Reviewed-on: https://gerrit.libreoffice.org/31159
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
This is a combination of 5 commits:
1) xmlsecurity PDF verify: don't abort read on partial sign
Map it to the partially signed (not all streams) ODF concept instead.
(cherry picked from commit e84993486b46ed86a8540b985355e82db5559720)
2) xmlsecurity PDF verify: fix reading names containing ']'
Also fix parsing '<< /Foo [ /Bar ] >>'.
(cherry picked from commit cdf2ae1b6611976816fa60aae370893657c622d0)
3) xmlsecurity PDF verify: handle no EOL at EOF
From a comment's point of view, EOF is just a terminator, similar to \r
or \n.
(cherry picked from commit b1f91c0a04dd751d4f6cb8352bcbaa16c9388285)
4) xmlsecurity PDF verify: avoid seeking before the start of the stream
Happened when the doc was smaller than 1024 bytes.
(cherry picked from commit c4cb8b5d1460bbf080366817d26c08685490d541)
5) xmlsecurity PDF verify: don't hide signatures where digest match is uncertain
Use case: the bugdoc has 2 signatures, one normal one and one with
SubFilter=ETSI.RFC3161. By not hiding the second signature it's possible
to counter-sign the document, even if we don't handle the contents of
the second one.
(cherry picked from commit 61c81c4500e5d5849b43d3a9d3efdabba94d513b)
Change-Id: I580e1211072ec9839f01b529b569c98b702b6534
Reviewed-on: https://gerrit.libreoffice.org/31557
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
|
|
This is a combination of 6 commits:
1) xmlsecurity PDF verify: look for the signingCertificateV2 attribute
This is a required part of the PAdES spec, but so far we only wrote it.
As a start just expose if the attribute exists or not.
(cherry picked from commit bef9ba5e062b340b1835db94620f7ea4fa0b123b)
2) xmlsecurity: don't write unchanged signatures back to the file
It's not useful, OTOH it can happen that something goes wrong and the
result does not match the original.
One situation when this can happen is when non-XAdES signatures are
read, but the checkbox to write XAdES signature is enabled.
(cherry picked from commit 7226ee0586191a495f427c2adbde68b1a47d2dbc)
3) xmlsecurity PDF verify: support non-detached signatures
And a couple of other changes to accept the bugdoc from
<https://github.com/esig/dss/
dss-pades/target/test-classes/plugtest/esig2014/ESIG-PAdES/RO/Signature-P-RO-4.pdf>.
(cherry picked from commit 055fd58711d57af4d96214aebd71b713303d5527)
4) xmlsecurity PDF verify: tolerate missing %%EOF in incremental updates
This is broken, but work it around to avoid an infinite loop.
(cherry picked from commit 0233ff952372e9a15edf92beccba463d74c46c33)
5) xmlsecurity PDF verify: CR is also a terminator of a comment
If we skip to the first NL, then we start tokenizing some XML as PDF
data and soon error out due to an unexpected keyword.
(cherry picked from commit 9b526a43e10a565875c879063f6df4bfe2ba9a80)
6) xmlsecurity PDF verify: handle boolean type as dictionary value
This caused not finding the length of a stream -> could not actually
verify signature.
(cherry picked from commit c623a9f846c713b19a0d58337af4f4354aeffa6e)
Change-Id: I696b6da49525eb53f7575c27f619d2116be51f1d
Reviewed-on: https://gerrit.libreoffice.org/31503
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
|
|
This is a combination of 6 commits:
1) CppunitTest_xmlsecurity_signing: fix this on Windows with non-empty cert store
The NSS code earlier started to save the hash algo ID of the signature
into the signature structure and I also added a unit test for this. This
failed on Windows when the system had at least one signing certificate
installed, as the mscrypto part of the patch was missing.
(cherry picked from commit fd3db1cf77c86cd787f912b7bb2ba3ad894203f3)
2) vcl mscrypto PDF sign: don't assume that header length is always 2 bytes
For now just assert that the short form doesn't try to handle larger
values than expected, the long form has to be implemented once we hit
the assert.
(cherry picked from commit 5bf32e4e78ffbe34f3b2840a9677ded34e5b4da7)
3) vcl mscrypto PDF sign: write IssuerSerial sequence
It fixes a problem detected by the PAdES validator from
<https://github.com/esig/dss>, and with this the Windows output is in
sync with NSS.
(cherry picked from commit e1446e9e25f784a730c0399ba64b52b36a01a91c)
4) vcl mscrypto PDF sign: fix typo in GetDERLengthOfLength()
When id-aa-signingCertificateV2 had a value that was larger than 255
bytes, then the header size is expected to be 4 bytes, but it was only
3. The length part of the header is 3 bytes: one byte declaring the
length-of-length, and 3 bytes for the length. We added this additional
byte to the result too early, that way we counted that e.g. 278 (the
number) fits into a single uint8_t, which is not the case.
Also introduce named constants for some of the hardwired numbers in the
code for better readability.
(cherry picked from commit 7339a3d39035ccc7541fbbddc858121ce464dc68)
5) CppunitTest_xmlsecurity_signing: add 2 more ODF / XAdES tests
Make sure we handle the case when the document has a signature
stream, but it's empty.
Make sure we find a given XAdES-enabled ODF document valid.
Previously this was tested only dynamically, i.e. breaking both the
import and the export at the same time went unnoticed.
(cherry picked from commit deaa4701e609f698999c3e05ce79b15f4cb94670)
6) CppunitTest_xmlsecurity_pdfsigning: add first PAdES test
As a start just make sure we accept "ETSI.CAdES.detached" as a valid
SubFilter value.
(cherry picked from commit 568e0394868114457c9dbf7cc1af5bc863ae2a4d)
Change-Id: I19f480a5a24df0f451261d6d9a0dd9bd72ff6cc1
Reviewed-on: https://gerrit.libreoffice.org/31435
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Miklos Vajna <vmiklos@collabora.co.uk>
|
|
This is a combination of 6 commits:
1) vcl mscrypto PDF sign: add initial 'signing-certificate' signed attribute
Equivalent of the earlier NSS commit, payload is just an empty sequence
at the moment.
(cherry picked from commit cb851cbb09adc637bb6e8095050292f7a8c6a7b1)
2) vcl mscrypto PDF sign: write ESSCertIDv2
With this, the value of signing-certificate conforms to the RFC on
Windows as well.
(cherry picked from commit b12410f212658996fdb5fb291a06038e9ac39b2e)
3) xmlsecurity mscrypto PDF sign: conditionally add back CAdES SubFilter
We can now write that on Windows as well when requested, after the
signing-certificate attribute is implemented using mscrypto.
With this, the PAdES validator at
<http://signatures-conformance-checker.etsi.org/protected/upload.php?sigtype=padesconf>
finds our Windows signature valid.
(cherry picked from commit 8a279d7de4cf94c99f655f6edd0da0c24ab4003c)
4) CppunitTest_xmlsecurity_signing: don't assume we always have a signing cert
This makes this suite in sync with CppunitTest_xmlsecurity_pdfsigning. A
signing certificate is available on 64bit NSS platforms, as there we
provide a pre-created NSS db, but on other platforms by default there is
just no signing certificate. The certificate.crt I added earlier is not
enough, that's just the certificate, but it doesn't provide a private
key.
(cherry picked from commit 748f778d0f42f2cbb78a7ca7e013bfbd77cdf2b7)
5) CppunitTest_xmlsecurity_signing: add XAdES testcase
Assert the two user-visible changes: SHA-256 hashes and the digest of
the signing certificate.
(cherry picked from commit 426495cb441e6a83cd0d1f74b0ddf656322815b5)
6) CppunitTest_xmlsecurity_pdfsigning: add PAdES testcase
Assert the two user-visible changes: SHA-256 hashes and the SubFilter of the
signature.
(cherry picked from commit 5cb580144c286117db485e605c79ce1139cb94fb)
Change-Id: I12a2355e2ddfc368bed4430a7b5ad244b5778afe
Reviewed-on: https://gerrit.libreoffice.org/31316
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Miklos Vajna <vmiklos@collabora.co.uk>
|
|
Also:
- avoid writing ETSI.CAdES.detached for now on Windows till doing so
results in an invalid signature in Acrobat
- extend the SEC_OID_PKCS1_SHA1_WITH_RSA_ENCRYPTION hack to do the same
for SHA256 and SHA512 as well, as Acrobat and NSS accepts such
signatures
Change-Id: Ibb0a204504b29230dd712ffb709d2037c1007218
|
|
Change-Id: If26be2b51a1fd8a6ad3e96928e2d142d1ced2845
Reviewed-on: https://gerrit.libreoffice.org/31074
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
|
|
That's where the implementation of such internal test binaries usually
are.
Change-Id: Ib7d2eb95de96d0d82e90e51f58da3a0c15a2ec71
Reviewed-on: https://gerrit.libreoffice.org/31073
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
|
|
Change-Id: I28bb2a33c02d8eadced584d3d3f2b62b2e847324
|
|
this is motivated by the new screenshot feature
the initial proposed solution involved running make screenshot once per lang
which took ~6 hours for --with-lang=ALL on tb68 a reasonnably big
windows slavebot.
with this patch, one can run make screenshot just once and get all the screenshot
the elapsed time is 36 inutes on the same box/same config a 10x improvement.
Change-Id: I4339caebf915c118aa455de2a7e56e1a4e413939
Reviewed-on: https://gerrit.libreoffice.org/30970
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Norbert Thiebaud <nthiebaud@gmail.com>
|
|
Change-Id: Iac3d2206388fde23d2f3d7a05b23978851cf2800
|
|
Change-Id: Ife64ab3683479baf152357a6167718f13c9b6089
Reviewed-on: https://gerrit.libreoffice.org/30964
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
|
|
Change-Id: I15a00a8c6f8c8e735694baa25e06ed4db0875d43
|
|
not randomly scattered through the code
found with something like:
git ls-files *.cpp | xargs grep -Pzl "(?s){.*#include"
Change-Id: I9c242fa4ef99e8677f2800d7ec9f16d16e488351
Reviewed-on: https://gerrit.libreoffice.org/30952
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Page 21 of "PAdES baseline signatures" specification from
<http://www.etsi.org/deliver/etsi_en/319100_319199/31914201/01.01.01_60/en_31914201v010101p.pdf>
says:
"The Signature Dictionary shall contain a value of ETSI.CAdES.detached
for the key SubFilter."
So in case the UI has the adescompliant checkbox enabled, write that
value instead of the Adobe default.
Change-Id: I69e606a32fb09bebd5e9b25b32150d1b8672f544
|
|
Change-Id: I90db6e3c69a6dc90ce1df0dbb5b9d7a81cd1bbea
|
|
And rename it to AdES, as the PDF PAdES generation will be affected by
this checkbox in the near future.
Change-Id: I06121e4eb9debac7a55a737a71780c2fa5c4d084
Reviewed-on: https://gerrit.libreoffice.org/30908
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Tor Lillqvist <tml@collabora.com>
|
|
Change-Id: Ic7aa466c62eb8850d3c6b50c0e10b0575bd9b82e
|
|
Change-Id: Ic15c34c77ff24a506b59ed02db3cfbb6722d0f25
|
|
Change-Id: If5793cd8a721ac5b4fce5280b6180f2827c72501
|
|
Change-Id: I3e38b1d445c368c28e807202b94c603bd2b2c672
Reviewed-on: https://gerrit.libreoffice.org/30872
Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
Tested-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
|
|
Change-Id: I8ed5242a4337da2ec1568d92bebfdad4915e6128
|
|
These files had a consistent style previously, keep them that way.
Change-Id: I6347efd4a301ddd758f4661778c0dfb68585940d
|
|
Change-Id: Ie6713d1bdf0010e5bc0bb70ca995c4dd36408673
|
|
Probably cid#1394297 was a fallout from that?
Change-Id: I98134ccbbbe8bc0b7d3c172ffddcdc3666f436f6
|
|
Change-Id: I64239dfcfbc2383c2bf53c0cb86196d3f2c79330
|
|
Hopefully it's easier to read this way.
Change-Id: I145e00f8e57e20f2663d1c9ee494af5d93c014c7
|
|
Accept and store a set of EncapsulatedX509Certificate data for a
signature.
Change-Id: Iae69502bc8caa0287c8f6d6c352256bdda22406b
|
|
Change-Id: I4302d0d767a1bf50fd34a78e9aa0ad6d6b0c7a22
|
|
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
|
|
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
|
|
With this our xref stream output is close enough to Acrobat so that the
existing signature verifier runs without any problems.
Change-Id: I6eca7966890365759c269b465e4bf4d86d335219
|
|
Change-Id: I8f2963c9b6b1c8717ea4d19453815fffa6e68484
|
|
This way it's a bit smaller for large files and our output is closer to
what Acrobat produces.
Change-Id: Ide5f7b58a74a9d6ad7d806814eb57cb6931023cc
Reviewed-on: https://gerrit.libreoffice.org/30726
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
|
|
So that when we have a single signature with ID="Signature2", then we
use "Signature3" for the next ID, not "Signature2". (Acrobat uses that ID
for the first signature.)
Change-Id: I7032fbf014184da2a5be24730a92abc32a9a1258
Reviewed-on: https://gerrit.libreoffice.org/30725
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
|
|
In case the input document used a PDF 1.5 xref stream, not an old xref
table, then write that as part of the incremental update. Acrobat seems
to require this.
Change-Id: I9f1f73140c26308f8720aa1ffe1b905d0e60ede0
Reviewed-on: https://gerrit.libreoffice.org/30724
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
|
|
Normally it's a direct dictionary, but it's OK to have it as a reference, and
then the referenced object is a dictionary.
Change-Id: If09edaf23501883be68148e430c42e721ec68247
Reviewed-on: https://gerrit.libreoffice.org/30719
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
|
|
Sure, using a namespace means we have to decorate each function with the
XMLSECURITY_DLLPUBLIC, but who cares.
Change-Id: If9a364d1be9c5f4cd02f3f146e8b01bd608b373e
|
|
Change-Id: Id9daf4f5e3208eca8d3d845983b58ab056557621
|
|
Normally it's a direct array, but it's OK to have it as a reference, and
then the referenced object is an array.
Change-Id: I191150632c2d8317ee6fd8c8169a90996298faa4
Reviewed-on: https://gerrit.libreoffice.org/30718
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
|
|
In case our xref table doesn't have an entry for "free" object types,
then the table size won't provide a valid id for a next object. That
resulted in creating all new objects with the same ID.
With this, our verifier at least can see the new signature when
appending one to a signed PDF 1.6 file.
Change-Id: Iac39a400706cfcd23dd814d2b81cb8b950c69fc6
Reviewed-on: https://gerrit.libreoffice.org/30704
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
|
|
Don't give up signing just because PDF 1.4 trailer is missing, provided
that PDF 1.5 xref stream is available.
Change-Id: I03360d428346537583a4398aa3a94b195b428713
Reviewed-on: https://gerrit.libreoffice.org/30703
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
|
|
This will need cross-reference stream write support, just don't crash
for now.
Change-Id: Id48c131b22d4ed96174693f3e96b14c273d596a8
Reviewed-on: https://gerrit.libreoffice.org/30702
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
|