Libdigidocpp library offers creating, signing and verification of digitally signed documents, according to XAdES and XML-DSIG standards. Documentation http://open-eid.github.io/libdigidocpp
License: Other
On Gentoo, when using OpenSSL-1.1.1d or lower, qdigidoc4 works for both verifying and creating signatures. However, on OpenSSL-1.1.1f, there are some issues:
ERROR [TSL.cpp:250] - TSL EE.xml status: TSL EE Signature is signed with untrusted certificate
INFO [X509CertStore.cpp:84] - Loaded 0 certificates into TSL certificate store.
ASiC_E.cpp:347 Failed to sign container.
SignatureXAdES_LT.cpp:227 Could not find certificate issuer 'CN=ESTEID2018,organizationIdentifier=NTREE-10747013,O=SK ID Solutions AS,C=EE' in certificate store.
Downgrading back to 1.1.1d solves these issues.
Koodis:
libdigidocpp/src/util/ZipSerialize.cpp
Line 71 in 74c9ca6
Veateade rakendusest: ZipSerialize.cpp:71 Failed to create ZIP file '//saialill/home$/kasutaja/TestFail2015.bdoc'
Compile failed for me on Ubuntu 17.04 with all dependencies installed.
libdigidocpp/build$ cmake ../
CMake Error at CMakeLists.txt:9 (include):
include could not find load file:
VersionInfo
CMake Error at CMakeLists.txt:12 (set_env):
Unknown CMake command "set_env".
-- Configuring incomplete, errors occurred!
See also "libdigidocpp/build/CMakeFiles/CMakeOutput.log".
digidoc-tool is hard-coded to use setSignatureProductionPlaceV2 for all signers:
libdigidocpp/src/digidoc-tool.cpp
Lines 774 to 775 in 852f13e
This was fine before, but ever since 16fc2b4 using this function forces the signer to use the XAdES EN profile. digidoc-tool is now unable to produce non-EN signatures, even if --XAdESEN is omitted.
digidoc-tool version: 3.13.9.1386
libdigidocpp version: 3.13.9.1386_ddoc
Hi,
I’m trying to use libdigidocpp to work with a Slovak version of XAdES, and it appears it is too strict to the input data. I’m feeding it an ASiC-E file with a signed XML as produced e.g. by zep.disig.sk:
Failed to parse container
Exception:
ASiC_E.cpp:321 code(General) Failed to parse manifest
ASiC_E.cpp:288 code(General) Failed to parse signature 'META-INF/signatures1.xml'.
SignatureXAdES_B.cpp:1194 code(General) Signature contains more than one signers certificate
When I comment out the relevant checks, it manages to proceed:
Version
digidoc-tool version: 3.14.3.0
libdigidocpp version: 3.14.3.0
2020-06-10T11:02:25Z D [Connect.cpp:50] - Connecting to URL: https://ec.europa.eu/tools/lotl/eu-lotl.xml
2020-06-10T11:02:25Z D [Connect.cpp:72] - Connecting to Host: ec.europa.eu:443 timeout: 10
2020-06-10T11:02:26Z D [TSL.cpp:573] - Remote ETag: "5bcdb-5a742052bf400"
2020-06-10T11:02:26Z D [TSL.cpp:579] - Cached ETag: "5bcdb-5a742052bf400"
2020-06-10T11:02:26Z D [TSL.cpp:248] - TSL eu-lotl.xml (267) signature is valid
2020-06-10T11:02:26Z I [X509CertStore.cpp:84] - Loaded 0 certificates into TSL certificate store.
2020-06-10T11:02:26Z D [ASiC_S.cpp:189] - detectContainerFormat(path = 'FUZZ 2.xdc.asice')
2020-06-10T11:02:26Z D [ASiC_S.cpp:237] - ASiC Format: 2
2020-06-10T11:02:26Z D [ASiC_E.cpp:162] - ASiC_E::openInternal(FUZZ 2.xdc.asice)
2020-06-10T11:02:26Z D [ASiContainer.cpp:90] - ASiContainer::ASiContainer(path = 'FUZZ 2.xdc.asice')
2020-06-10T11:02:26Z D [ZipSerialize.cpp:69] - ZipSerialize::open(FUZZ 2.xdc.asice)
2020-06-10T11:02:26Z D [ZipSerialize.cpp:133] - ZipSerializePrivate::extract(mimetype)
2020-06-10T11:02:26Z D [ASiContainer.cpp:298] - ASiContainer::readMimetype()
2020-06-10T11:02:26Z D [ASiContainer.cpp:106] - mimetype = 'application/vnd.etsi.asic-e+zip'
2020-06-10T11:02:26Z D [ASiC_E.cpp:212] - ASiC_E::readManifest()
2020-06-10T11:02:26Z D [ZipSerialize.cpp:133] - ZipSerializePrivate::extract(META-INF/manifest.xml)
2020-06-10T11:02:26Z D [ASiC_E.cpp:234] - full_path = '/', media_type = 'application/vnd.etsi.asic-e+zip'
2020-06-10T11:02:26Z D [ASiC_E.cpp:234] - full_path = 'FUZZ 2.xdc.xml', media_type = 'application/vnd.gov.sk.xmldatacontainer+xml'
2020-06-10T11:02:26Z D [ZipSerialize.cpp:133] - ZipSerializePrivate::extract(FUZZ 2.xdc.xml)
2020-06-10T11:02:26Z D [ASiC_E.cpp:234] - full_path = 'META-INF/signatures1.xml', media_type = 'text/xml'
2020-06-10T11:02:26Z D [ZipSerialize.cpp:133] - ZipSerializePrivate::extract(META-INF/signatures1.xml)
2020-06-10T11:02:26Z D [ZipSerialize.cpp:133] - ZipSerializePrivate::extract(META-INF/signatures1.xml)
2020-06-10T11:02:26Z D [ZipSerialize.cpp:83] - ZipSerialize::~ZipSerialize()
Container file: FUZZ 2.xdc.asice
Container type: application/vnd.etsi.asic-e+zip
Documents (2):
Document (application/vnd.gov.sk.xmldatacontainer+xml): FUZZ 2.xdc.xml (166051 bytes)
Document (text/xml): META-INF/signatures1.xml (19424 bytes)
Signatures (1):
Signature 0 (BES/time-stamp):
2020-06-10T11:02:26Z D [SignatureXAdES_B.cpp:444] - SignatureXAdES_B::validate(POLv2)
DEBUG [SignatureXAdES_B.cpp:752] - Digest { F5 55 17 61 8C 62 A6 93 09 AE 8B D0 10 49 25 4C 20 28 A0 9C DB CE 5B 9C 12 F7 DB 81 44 99 7D 20 }:32
2020-06-10T11:02:26Z D [Connect.cpp:50] - Connecting to URL: https://ec.europa.eu/tools/lotl/eu-lotl.xml
2020-06-10T11:02:26Z D [Connect.cpp:72] - Connecting to Host: ec.europa.eu:443 timeout: 10
2020-06-10T11:02:26Z D [TSL.cpp:573] - Remote ETag: "5bcdb-5a742052bf400"
2020-06-10T11:02:26Z D [TSL.cpp:579] - Cached ETag: "5bcdb-5a742052bf400"
2020-06-10T11:02:26Z D [TSL.cpp:248] - TSL eu-lotl.xml (267) signature is valid
2020-06-10T11:02:26Z W [TSL.cpp:110] - Failed to parse TSL /home/andrewsh/.digidocpp/tsl//SK.xml: /home/andrewsh/.digidocpp/tsl//SK.xml:1:2 error: invalid document structure
2020-06-10T11:02:26Z E [TSL.cpp:250] - TSL SK.xml status: Failed to parse XML
2020-06-10T11:02:26Z D [Connect.cpp:50] - Connecting to URL: http://tl.nbu.gov.sk/kca/tsl/tsl.xml
2020-06-10T11:02:26Z D [Connect.cpp:72] - Connecting to Host: tl.nbu.gov.sk:80 timeout: 10
2020-06-10T11:02:30Z W [TSL.cpp:335] - Found critical extension TakenOverByType 'National Agency for Network and Electronic Services'
2020-06-10T11:02:30Z W [TSL.cpp:335] - Found critical extension TakenOverByType 'National Agency for Network and Electronic Services'
2020-06-10T11:02:30Z W [TSL.cpp:335] - Found critical extension TakenOverByType 'National Agency for Network and Electronic Services'
2020-06-10T11:02:30Z W [TSL.cpp:335] - Found critical extension TakenOverByType 'National Agency for Network and Electronic Services'
2020-06-10T11:02:30Z W [TSL.cpp:335] - Found critical extension TakenOverByType 'National Agency for Network and Electronic Services'
2020-06-10T11:02:30Z W [TSL.cpp:335] - Found critical extension TakenOverByType 'National Agency for Network and Electronic Services'
2020-06-10T11:02:30Z W [TSL.cpp:335] - Found critical extension TakenOverByType 'National Agency for Network and Electronic Services'
2020-06-10T11:02:30Z W [TSL.cpp:335] - Found critical extension TakenOverByType 'National Agency for Network and Electronic Services'
2020-06-10T11:02:30Z W [TSL.cpp:335] - Found critical extension TakenOverByType 'National Agency for Network and Electronic Services'
2020-06-10T11:02:30Z W [TSL.cpp:335] - Found critical extension TakenOverByType 'National Agency for Network and Electronic Services'
2020-06-10T11:02:30Z W [TSL.cpp:335] - Found critical extension TakenOverByType 'National Agency for Network and Electronic Services'
2020-06-10T11:02:30Z W [TSL.cpp:335] - Found critical extension TakenOverByType 'National Agency for Network and Electronic Services'
2020-06-10T11:02:30Z W [TSL.cpp:335] - Found critical extension TakenOverByType 'National Agency for Network and Electronic Services'
2020-06-10T11:02:30Z W [TSL.cpp:335] - Found critical extension TakenOverByType 'First certification authority, a.s.'
2020-06-10T11:02:30Z W [TSL.cpp:335] - Found critical extension TakenOverByType 'First certification authority, a.s.'
2020-06-10T11:02:30Z W [TSL.cpp:335] - Found critical extension TakenOverByType 'First certification authority, a.s.'
2020-06-10T11:02:30Z W [TSL.cpp:335] - Found critical extension TakenOverByType 'First certification authority, a.s.'
2020-06-10T11:02:30Z W [TSL.cpp:335] - Found critical extension TakenOverByType 'First certification authority, a.s.'
2020-06-10T11:02:30Z W [TSL.cpp:335] - Found critical extension TakenOverByType 'First certification authority, a.s.'
2020-06-10T11:02:30Z W [TSL.cpp:335] - Found critical extension TakenOverByType 'First certification authority, a.s.'
2020-06-10T11:02:30Z W [TSL.cpp:335] - Found critical extension TakenOverByType 'First certification authority, a.s.'
2020-06-10T11:02:30Z W [TSL.cpp:335] - Found critical extension TakenOverByType 'First certification authority, a.s.'
2020-06-10T11:02:30Z W [TSL.cpp:335] - Found critical extension TakenOverByType 'First certification authority, a.s.'
2020-06-10T11:02:30Z W [TSL.cpp:335] - Found critical extension TakenOverByType 'First certification authority, a.s.'
2020-06-10T11:02:30Z W [TSL.cpp:335] - Found critical extension TakenOverByType 'First certification authority, a.s.'
2020-06-10T11:02:30Z W [TSL.cpp:335] - Found critical extension TakenOverByType 'First certification authority, a.s.'
2020-06-10T11:02:30Z D [TSL.cpp:282] - TSL SK.xml (65) signature is valid
2020-06-10T11:02:30Z I [X509CertStore.cpp:84] - Loaded 111 certificates into TSL certificate store.
Validation: FAILED (Invalid)
Exception:
Signature validation
Manifest datafile not listed in signature references META-INF/signatures1.xml
RevocationValues object is missing
EPES policy:
SPUri:
Signature method: http://www.w3.org/2001/04/xmldsig-more#rsa-sha256
Signing time: 2019-04-19T09:51:45.035Z
Signing cert: Andrej Shadura
Signed by: Andrej Shadura
Produced At:
OCSP Responder:
Message imprint (51): 30 31 30 0D 06 09 60 86 48 01 65 03 04 02 01 05 00 04 20 75 BB B3 8E 5A 74 DD 61 95 FB C4 99 62 31 AD 56 E6 F1 B7 DA FD 7E 73 B0 EE E7 C1 3F 8C 06 E8 25
TS: TSA Disig TSU 1
TS time: 2019-04-19T09:51:57Z
TSA:
TSA time:
So apparently the change itself is "okay" but something else is missing. I’m willing to provide the file on request, but I cannot publish it without revealing too much of private info.
digidoc-tool create --file=asd demo-container.bdoc
Version
digidoc-tool version: 3.13.2.1355
libdigidocpp version: 3.13.2.1355_ddoc
DEBUG [Connect.cpp:53] - Connecting to URL: https://ec.europa.eu/information_society/policy/esignature/trusted-list/tl-mp.sha2
DEBUG [Connect.cpp:75] - Connecting to Host: ec.europa.eu:443
DEBUG [Connect.cpp:53] - Connecting to URL: https://ec.europa.eu/information_society/policy/esignature/trusted-list/tl-mp.xml
DEBUG [Connect.cpp:75] - Connecting to Host: ec.europa.eu:443
DEBUG [TSL.cpp:549] - Last modified: Tue, 17 Oct 2017 14:33:47 GMT
DEBUG [TSL.cpp:559] - Cached timestamp: Tue, 17 Oct 2017 14:33:47 GMT
DEBUG [TSL.cpp:246] - TSL tl-mp.xml signature is valid
DEBUG [Connect.cpp:53] - Connecting to URL: https://sr.riik.ee/tsl/estonian-tsl.sha2
DEBUG [Connect.cpp:75] - Connecting to Host: sr.riik.ee:443
DEBUG [TSL.cpp:246] - TSL EE.xml signature is valid
INFO [X509CertStore.cpp:84] - Loaded 42 certificates into TSL certificate store.
DEBUG [PKCS11Signer.cpp:138] - PKCS11Signer(driver = 'opensc-pkcs11.so')
DEBUG [PKCS11Signer.cpp:182] - PKCS11Signer::getCert()
Available certificates:
label: XXXX,XXX,XXXXX
Selected:
label: XXXX,XXX,XXXXX
DEBUG [PKCS11Signer.cpp:310] - sign(mehthod = http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha256, digest = length=32)
Please enter PIN for token 'XXXX,XXX,XXXXX' or <enter> to cancel:
DEBUG [PKCS11Signer.cpp:157] - ~PKCS11Signer()
Caught Exception:
ASiC_E.cpp:348 code(General) Failed to sign BDOC container.
PKCS11Signer.cpp:384 code(General) Failed to sign digest
In UI I get following error:
ASiC_E.cpp:348 Failed to sign BDOC container.
QSigner.cpp:448 Dokumendi allkirjastamine ebaõnnestus
Doesn't matter if I select BDOC or ASIC-E format
Seems like digest is missing for some reason
Using Arch linux, packages installed from AUR, there seems to be problem with Arch https://aur.archlinux.org/packages/qesteidutil/
Any help?
I am not sure whether what I want to do is conceptually possible. Spelled out in code, this is what I want to do:
void fun(/* ... */) {
// Slot/CardReader has dedicated PIN Pad, hence no subclass with pin method
auto signer = digidoc::PKCS11Signer(opensc_0_20_0_driver);
auto sign = [&](std::string const& from, std::string const& to) {
std::unique_ptr<digidoc::Container> doc{digidoc::Container::open(from)};
digidoc::Signature *signature = doc->sign(&signer);
assert(signature);
signature->validate();
doc->save(to);
};
// succeeds
sign(unsigned_asice_in1, signed_asice_out1);
// throws "Failed to sign container", cause "Failed to sign digest"
sign(unsigned_asice_in2, signed_asice_out2);
}
My goal is to sign multiple documents in one batch (as much as the user wants). For ease of use I hoped that it is possible to enter the PIN2 of the Estonian ID card only once when signing the first document and being cached thereafter. IIUC, this should be possible if one uses a card reader without a dedicated PIN pad by subclassing the PKCS11Signer class and cache the user-entered PIN2 within the application. However, in my setting the card reader has a dedicated PIN pad (and hence caching the PIN within the application is impossible IIUC).
The toy code (not compiled, just a reduced version of my code which hopefully still illustrates the workflow) successfully signs (after entering the PIN2 on the dedicated PIN pad) and saves the first ASiC-E container, however the second doc->sign call (which reuses the PKCS11Signer object) fails with "Failed to sign digest" (without asking for a PIN2). Is this the intended result?
The debugger shows that in the second invocation of doc->sign PKCS11Signer.cpp:327 returns CKR_USER_ALREADY_LOGGED_IN, but PKCS11Signer.cpp:382 returns 0x101 (CKR_USER_NOT_LOGGED_IN), hence it throws.
I use the new OpenSC driver 0.20.0 (barely a week old, which natively supports the Estonian ID card, and it worked when using with the DigiDoc4 client) on Debian Buster.
The CKR_.. return values seem contradictory, hence I am puzzled: Am I trying to achieve something impossible and I instead must create a new signer for each container (forcing the user to enter the PIN2 for each container), or is this a bug in libdigidocpp or in OpenSC 0.2.0? Sadly I am missing any expertise whatsoever concerning PKCS#11 and the Estonian ID Card, hence I don't know where to start looking for a bug fix (if it is a bug at all).
export OPENSSL_ROOT_DIR="/usr/local/opt/[email protected]"
./build-library.sh osx
Undefined symbols for architecture arm64:
"_ASN1_ANY_it", referenced from:
QCStatement_seq_tt in X509Cert.cpp.o
I have libdigidocpp-3.13.8.1379 installed on windows 10
xsdcxx väljakutsumisel kasutatakse --std valikut, mis on saadaval alates xsd-4.0.0 versioonist.
http://www.codesynthesis.com/pipermail/xsd-announcements/2014/000041.html
The signature policy identifier for
http://id.ee/public/bdoc-spec212-eng.pdf
should be:
urn:oid:1.3.6.1.4.1.10015.1000.3.2.3
instead we have:
urn:oid:1.3.6.1.4.1.10015.1000.3.2.1
https://github.com/open-eid/libdigidocpp/blob/master/src/SignatureXAdES_B.cpp#L66
Hello there,
I'd like to use the documented USE_TSL build parameter (https://open-eid.github.io/libdigidocpp/manual.html#initialization). I tried it with CMake (cmake -DUSE_TSL=false [...]) which did not work, and apparently USE_TSL is only mentioned ever in RELEASE-NOTES.md and other documentation files. I suspect that this is no longer a valid approach to disabling TSL?
My long term goal is to create containers without the library talking to the internet. Right now looking at https://open-eid.github.io/libdigidocpp/manual.html#TSL-init step 3 "The officially published hash value is downloaded", this looks like accessing the Internet is inevitable (if USE_TSL really is no longer around)?
Do I have any options here or do I need to fallback to creating the containers myself instead?
Thank you for your time.
Similar to #342
You can totally do WASM C++ in the browser
Please add the zlib dependency to step 1 of readme.
I installed the zlib1g-dev package to make cmake work.
Current podofo version (0.9.6) dropped pdfsiginc API:
"
Remove obsolete PdfSigInc* API
See tools/podofosign/podofosign.cpp for the replacement of it.
"
causing libdigidocpp to no longer build
https://github.com/svn2github/podofo/blob/master/tools/podofosign/podofosign.cpp.
Please consider supporting current podofo.
Hello,
I suggest improving the documentation on ownership of pointers handed back and forth in the Container class. Especially, I was bitten by the function Container::addDataStream(std::istream* ptr, ...). Being used to using std::unique_ptr for (idiomatic) ownership transfer, I used code as follows:
std::istringstream infile(in_filename);
auto container = std::unique_ptr<digidoc::Container>{digidoc::Container::create(out_filename)};
container->addDataFile(&stream, in_container_filename, "application/octet-stream");
container->save();
This blew up with a double free and it took me some time to realize (after reading documentation and the boost tests) that the API actually takes ownership.
Container::create returning a raw pointer also required me to look through documentation and tests whether there is some library internal memory management magic, as the developer guidelines don't show a std::unique_ptr here, nor are they mentioning ownership in any case. Only a look into the boost tests gave me certainty that the caller becomes the owner of the objects.
The same applies to the other methods taking or returning a pointer. It seems like Container::dataFiles is not transferring ownership to the caller? Container::prepareSignature and Container::sign probably do? (I did not require those methods, yet, hence I have not looked up further documentation / tests / library internals to verify any of those hypotheses.) I have not looked at any other parts of the libdigidocpp API, so there may be potential for clarification, too.
I understand that due to API backwards compatibility it may not be feasible to migrate to a more idiomatic API. However, I suggest to at least improve the documentation (may it be as short as "takes ownership of [argument]" / "hands ownership of result to the caller"). This would have saved me an hour or two of gdb, searching documentation, reading tests, reading library internals.
I do not intend to criticize any of your work, I am merely suggesting an improvement.
Best Regards.
Building on Linux 5.8.5-arch1-1 #1 SMP PREEMPT Thu, 27 Aug 2020 18:53:02 +0000 x86_64 GNU/Linux results in lots of build errors around the xalan-c API:
.......
/home/silur/.cache/yay/libdigidocpp/src/src/Container.cpp:134:9: error: ‘XPathEvaluator’ has not been declared
134 | XPathEvaluator::initialize();
| ^~~~~~~~~~~~~~
/home/silur/.cache/yay/libdigidocpp/src/src/Container.cpp:135:9: error: ‘XalanTransformer’ has not been declared
135 | XalanTransformer::initialize();
| ^~~~~~~~~~~~~~~~
/home/silur/.cache/yay/libdigidocpp/src/src/Container.cpp: In function ‘void digidoc::terminate()’:
/home/silur/.cache/yay/libdigidocpp/src/src/Container.cpp:185:5: error: ‘XalanTransformer’ has not been declared
185 | XalanTransformer::terminate();
| ^~~~~~~~~~~~~~~~
/home/silur/.cache/yay/libdigidocpp/src/src/Container.cpp:186:5: error: ‘XPathEvaluator’ has not been declared
186 | XPathEvaluator::terminate();
| ^~~~~~~~~~~~~~
[ 64%] Building CXX object src/CMakeFiles/digidocpp.dir/SiVaContainer.cpp.o
cd /tmp
curl -L -O 'https://github.com/open-eid/libdigidocpp/releases/download/v3.14.3/libdigidocpp-3.14.3.tar.gz'
tar -xvzf libdigidocpp-3.14.3.tar.gz
cd libdigidocpp-3.14.3/
mkdir build
cd build
cmake ..
makecommit 10287ae#diff-b96d913077879e2814ffaccd2d949913 changed the decltype but maybe missed ? some
libdigidocpp/src/crypto/Connect.cpp
Line 98 in 15a83ba
Based on #342 a colleague of mine was able to do some C++ magic and verify the signature.
there may be some marker in the validation response that proves e-residency, but I don't see a clear one at this time.
Asking because we would like to offer some services to E-Residents only. Not discriminatory, just enjoying building new lego blocks od decentralized governance if that makes sense ⚡️⚡️⚡️
I was unable to build libdigidocpp. This is newly installed W10 machine (with nothing but Visual Studio 2017, and the requirements that were listed (7Zip, Perl, etc)).
prepare_win_build_environment.ps1 has references to old versions, that I locally fixed, but in some point I was getting nothing but:
C:\build\xerces-c-3.2.0\x64RelWithDebInfo>if "" NEQ "14.0" (
if "" GEQ "1"
exit /B 0
)
The system cannot find the path specified.
x
ERROR: Can't allocate required memory!
When running the same line second time, nothing happend - just nothing.
PS. Is that correct, that I need to build this my self to provide "examples/DigiDocCSharp" some includes. This line was a bit misleading:
Add the C# source files files from include\digidocpp_csharp folder to the digidoc folder of the opened > project (in Solution Explorer view, right click on the digidoc folder, choose Add->Existing item)
would be nice to have, it fixes compile errors with xml-security-c-2.x versions.
What is the reason for showing signature as invalid then it's OCSP response of signer certificate was produced at more than 24 hours after signature timestamp was created?
SignatureTS.cpp
161 else if(producedAtT - timeT > 24 * 60 * 60) // 24h
162 EXCEPTION_ADD(exception, "TimeStamp time and OCSP producedAt are over 24h");
It is impossible to use release tarballs to build a package, since submodule folders are empty. Is it possible to use --recursive checkout to form release tarballs?
WinSigner accepts 4 different ways to sign. The closest is "selectFirst". Please add 5th option to accept filter like thumbprint or some hash to select cert. And in that case WinSigner would read cert from cert store: software keys.
Usecase: today signing with KLASS3 cert uses PKCS12Signer that accepts cert as file (path, password). Storing files in file system is not the best practice. WinSigner is closest to provide this functionality, but accepts only hardware keys.
BUILD/libdigidocpp-3.12.1/src/util/File.cpp:649] -> [libdigidocpp-3.12.1/src/util/File.cpp:644]: (warning) Missing bounds check for extra iterator increment in loop.
Source code is
data[2] = *(++i);
data[3] = *(++i);
Suggest sanity check i is in range before incrementing it.
Currently the bundled minizip get included even when the system minizip is found:
[ 80%] Building CXX object src/CMakeFiles/digidocpp.dir/util/ZipSerialize.cpp.o
cd /var/tmp/portage/dev-libs/libdigidocpp-3.11.0_p1296/work/libdigidocpp-3.11.0.1296/src && /usr/bin/c++ -DBUILD_DATE=\"14.08.2015\" -DBUILD_VER=1296 -DDIGIDOCPP_CONFIG_DIR=\"/usr/local/etc/digidocpp\" -DDOMAINURL=\"ria.ee\" -DLINKED_LIBDIGIDOC -DMAJOR_VER=3 -DMINOR_VER=11 -DORG=\"RIA\" -DPKCS11_MODULE=\"opensc-pkcs11.so\" -DRELEASE_VER=0 -DTSA_URL=\"http://tsa.sk.ee\" -DTSL_URL=\"https://ec.europa.eu/information_society/policy/esignature/trusted-list/tl-mp.xml\" -DVER_SUFFIX=\"\" -Ddigidocpp_EXPORTS -fvisibility=hidden -fvisibility-inlines-hidden -std=c++11 -fPIC -I/var/tmp/portage/dev-libs/libdigidocpp-3.11.0_p1296/work/libdigidocpp-3.11.0.1296/src -I/usr/include/minizip -o CMakeFiles/digidocpp.dir/util/ZipSerialize.cpp.o -c /var/tmp/portage/dev-libs/libdigidocpp-3.11.0_p1296/work/libdigidocpp-3.11.0.1296/src/util/ZipSerialize.cpp
In file included from /var/tmp/portage/dev-libs/libdigidocpp-3.11.0_p1296/work/libdigidocpp-3.11.0.1296/src/minizip/zip.h:54:0,
from /var/tmp/portage/dev-libs/libdigidocpp-3.11.0_p1296/work/libdigidocpp-3.11.0.1296/src/util/ZipSerialize.cpp:25:
/var/tmp/portage/dev-libs/libdigidocpp-3.11.0_p1296/work/libdigidocpp-3.11.0.1296/src/minizip/ioapi.h:135:51: error:
expected initializer before ‘OF’
typedef voidpf (ZCALLBACK *open_file_func) OF((voidpf opaque, const char* filename, int mode));
^
-I/usr/include/minizip is passed in, but bundled minizip is somehow used anyway.
When bundled minizip is deleted (via rm -r src/minizip) build succeeds.
I am having some trouble building from master and I am not sure where this one comes from?
Can someone help?
[ 1%] Built target docs
[ 40%] Built target digidocpp_priv
[ 45%] Built target minizip
[ 46%] Building CXX object src/CMakeFiles/digidocpp.dir/Container.cpp.o
/home/hector/git/libdigidocpp/src/Container.cpp: In instantiation of ‘static void digidoc::Container::addContainerImplementation() [with T = digidoc::PDF]’:
/home/hector/git/libdigidocpp/src/Container.cpp:158:48: required from here
/home/hector/git/libdigidocpp/src/Container.cpp:423:27: error: no matching function for call to ‘push_back(digidoc::Container* (*)(const string&))’
423 | m_createList.push_back(&T::createInternal);
| ~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~
In file included from /usr/include/c++/10/vector:67,
from /home/hector/git/libdigidocpp/src/Container.h:26,
from /home/hector/git/libdigidocpp/src/Container.cpp:20:
/usr/include/c++/10/bits/stl_vector.h:1187:7: note: candidate: ‘void std::vector<_Tp, _Alloc>::push_back(const value_type&) [with _Tp = std::unique_ptr<digidoc::Container> (*)(const std::__cxx11::basic_string<char>&); _Alloc = std::allocator<std::unique_ptr<digidoc::Container> (*)(const std::__cxx11::basic_string<char>&)>; std::vector<_Tp, _Alloc>::value_type = std::unique_ptr<digidoc::Container> (*)(const std::__cxx11::basic_string<char>&)]’ (near match)
1187 | push_back(const value_type& __x)
| ^~~~~~~~~
/usr/include/c++/10/bits/stl_vector.h:1187:7: note: conversion of argument 1 would be ill-formed:
/home/hector/git/libdigidocpp/src/Container.cpp:423:27: error: invalid conversion from ‘digidoc::Container* (*)(const string&)’ {aka ‘digidoc::Container* (*)(const std::__cxx11::basic_string<char>&)’} to ‘std::vector<std::unique_ptr<digidoc::Container> (*)(const std::__cxx11::basic_string<char>&)>::value_type’ {aka ‘std::unique_ptr<digidoc::Container> (*)(const std::__cxx11::basic_string<char>&)’} [-fpermissive]
423 | m_createList.push_back(&T::createInternal);
| ~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~
| |
| digidoc::Container* (*)(const string&) {aka digidoc::Container* (*)(const std::__cxx11::basic_string<char>&)}
In file included from /usr/include/c++/10/vector:67,
from /home/hector/git/libdigidocpp/src/Container.h:26,
from /home/hector/git/libdigidocpp/src/Container.cpp:20:
/usr/include/c++/10/bits/stl_vector.h:1203:7: note: candidate: ‘void std::vector<_Tp, _Alloc>::push_back(std::vector<_Tp, _Alloc>::value_type&&) [with _Tp = std::unique_ptr<digidoc::Container> (*)(const std::__cxx11::basic_string<char>&); _Alloc = std::allocator<std::unique_ptr<digidoc::Container> (*)(const std::__cxx11::basic_string<char>&)>; std::vector<_Tp, _Alloc>::value_type = std::unique_ptr<digidoc::Container> (*)(const std::__cxx11::basic_string<char>&)]’ (near match)
1203 | push_back(value_type&& __x)
| ^~~~~~~~~
/usr/include/c++/10/bits/stl_vector.h:1203:7: note: conversion of argument 1 would be ill-formed:
/home/hector/git/libdigidocpp/src/Container.cpp:423:27: error: invalid conversion from ‘digidoc::Container* (*)(const string&)’ {aka ‘digidoc::Container* (*)(const std::__cxx11::basic_string<char>&)’} to ‘std::vector<std::unique_ptr<digidoc::Container> (*)(const std::__cxx11::basic_string<char>&)>::value_type’ {aka ‘std::unique_ptr<digidoc::Container> (*)(const std::__cxx11::basic_string<char>&)’} [-fpermissive]
423 | m_createList.push_back(&T::createInternal);
| ~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~
| |
| digidoc::Container* (*)(const string&) {aka digidoc::Container* (*)(const std::__cxx11::basic_string<char>&)}
/home/hector/git/libdigidocpp/src/Container.cpp:424:25: error: no matching function for call to ‘push_back(digidoc::Container* (*)(const string&))’
424 | m_openList.push_back(&T::openInternal);
| ~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~
In file included from /usr/include/c++/10/vector:67,
from /home/hector/git/libdigidocpp/src/Container.h:26,
from /home/hector/git/libdigidocpp/src/Container.cpp:20:
/usr/include/c++/10/bits/stl_vector.h:1187:7: note: candidate: ‘void std::vector<_Tp, _Alloc>::push_back(const value_type&) [with _Tp = std::unique_ptr<digidoc::Container> (*)(const std::__cxx11::basic_string<char>&); _Alloc = std::allocator<std::unique_ptr<digidoc::Container> (*)(const std::__cxx11::basic_string<char>&)>; std::vector<_Tp, _Alloc>::value_type = std::unique_ptr<digidoc::Container> (*)(const std::__cxx11::basic_string<char>&)]’ (near match)
1187 | push_back(const value_type& __x)
| ^~~~~~~~~
/usr/include/c++/10/bits/stl_vector.h:1187:7: note: conversion of argument 1 would be ill-formed:
/home/hector/git/libdigidocpp/src/Container.cpp:424:25: error: invalid conversion from ‘digidoc::Container* (*)(const string&)’ {aka ‘digidoc::Container* (*)(const std::__cxx11::basic_string<char>&)’} to ‘std::vector<std::unique_ptr<digidoc::Container> (*)(const std::__cxx11::basic_string<char>&)>::value_type’ {aka ‘std::unique_ptr<digidoc::Container> (*)(const std::__cxx11::basic_string<char>&)’} [-fpermissive]
424 | m_openList.push_back(&T::openInternal);
| ~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~
| |
| digidoc::Container* (*)(const string&) {aka digidoc::Container* (*)(const std::__cxx11::basic_string<char>&)}
In file included from /usr/include/c++/10/vector:67,
from /home/hector/git/libdigidocpp/src/Container.h:26,
from /home/hector/git/libdigidocpp/src/Container.cpp:20:
/usr/include/c++/10/bits/stl_vector.h:1203:7: note: candidate: ‘void std::vector<_Tp, _Alloc>::push_back(std::vector<_Tp, _Alloc>::value_type&&) [with _Tp = std::unique_ptr<digidoc::Container> (*)(const std::__cxx11::basic_string<char>&); _Alloc = std::allocator<std::unique_ptr<digidoc::Container> (*)(const std::__cxx11::basic_string<char>&)>; std::vector<_Tp, _Alloc>::value_type = std::unique_ptr<digidoc::Container> (*)(const std::__cxx11::basic_string<char>&)]’ (near match)
1203 | push_back(value_type&& __x)
| ^~~~~~~~~
/usr/include/c++/10/bits/stl_vector.h:1203:7: note: conversion of argument 1 would be ill-formed:
/home/hector/git/libdigidocpp/src/Container.cpp:424:25: error: invalid conversion from ‘digidoc::Container* (*)(const string&)’ {aka ‘digidoc::Container* (*)(const std::__cxx11::basic_string<char>&)’} to ‘std::vector<std::unique_ptr<digidoc::Container> (*)(const std::__cxx11::basic_string<char>&)>::value_type’ {aka ‘std::unique_ptr<digidoc::Container> (*)(const std::__cxx11::basic_string<char>&)’} [-fpermissive]
424 | m_openList.push_back(&T::openInternal);
| ~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~
| |
| digidoc::Container* (*)(const string&) {aka digidoc::Container* (*)(const std::__cxx11::basic_string<char>&)}
make[2]: *** [src/CMakeFiles/digidocpp.dir/build.make:194: src/CMakeFiles/digidocpp.dir/Container.cpp.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:222: src/CMakeFiles/digidocpp.dir/all] Error 2
make: *** [Makefile:160: all] Error 2Hello,
im trying to run CSharp Example project.
after entering my PIN for document singning i get this errors.
INFO [X509CertStore.cpp:84] - Loaded 42 certificates into TSL certificate store.
Creating file: test.bdoc
Failed to sign BDOC container.
Failed to parse TS response.
error:0D0680A8:asn1 encoding routines:ASN1_CHECK_TLEN:wrong tag
error:0D07803A:asn1 encoding routines:ASN1_ITEM_EX_D2I:nested asn1 error
i found on the internet that its maybe because of the wrong characters in certificate.
but its probably not the case.
why do i have this error?
and how can i fix it?
Why do we recacularte the certID again but not reuse the one sent with OCSP request?
Recalculaltion of certID in method void OCSP::verifyResponse(const X509Cert &cert) const
https://github.com/open-eid/libdigidocpp/blob/master/src/crypto/OCSP.cpp#L328,L339
But not reuse the OCSP_CERTID *certId sent with OCSP request to OCSP responder in method OCSP::OCSP
https://github.com/open-eid/libdigidocpp/blob/master/src/crypto/OCSP.cpp#L102,L105
Also it is possible to use this library to very cert file -- certificate not originated from ssl context.?
Documentation is not clear what is it for, how is it used
Hey,
Possibly related to #142.
http://open-eid.github.io/libdigidocpp/manual.html#signature-notes states:
When validating a BDOC-TS document then the difference between OCSP validity confirmation's production time (producedAt field) and time-stamp's production time (getTime field) is checked. An exception is thrown if the OCSP confirmation's time is earlier than time-stamp's time.
However BDOC v2.1.2 seems to have removed that requirement as per https://www.id.ee/?id=36110. I haven't checked whether the implementation still checks that or it's just an out-of-date manual. I've got an XAdES implementation soon to be released for https://rahvaalgatus.ee that'll start requesting the time stamp and an OCSP response in parallel and their creation times are likely to be randomly ordered, so if libdigidocpp insists one precedes the other, it'll definitely become an issue.
Cheers
The documentations fails to mention the dependency on libxalan-c, and cmake also fails to check that it is installed. Thus, if libxalan-c is not installed, compilation fails with
libdigidocpp/src/Container.cpp:41:43: fatal error: xalanc/XPath/XPathEvaluator.hpp: No such file or directory
#include <xalanc/XPath/XPathEvaluator.hpp>
^
compilation terminated.
Currently there is not possible to change URL of the time-stamping service (ts.url) with digidoc-tool
libdigidocpp/src/digidoc-tool.cpp
Lines 278 to 338 in 7f8f580
Another issue is that in manual default TSA url is "http://tsa.sk.ee/"
http://open-eid.github.io/libdigidocpp/manual.html#TS-settings
but actually it is configured to use "http://dd-at.ria.ee/tsa" by default
Line 16 in 0b81460
After building and installing the software I've got an error:
0 (libdigidocpp:master) sofa% /usr/local/bin/digidoc-tool
/usr/local/bin/digidoc-tool: error while loading shared libraries: libdigidocpp.so.1: cannot open shared object file: No such file or directory
127 (libdigidocpp:master) sofa% find ./ -name '*.so'
./src/libdigidocpp.so
0 (libdigidocpp:master) sofa% ldconfig -p |grep digido
1 (libdigidocpp:master) sofa%
I found that shared object has been installed in /usr/local/lib but ldconfig didn't know about it.
After running ldconfig the software starts as expected.
[ 45s] [ 30%] Building CXX object src/CMakeFiles/digidocpp_priv.dir/crypto/TSL.cpp.o
[ 45s] cd /home/abuild/rpmbuild/BUILD/libdigidocpp/src && /usr/bin/g++-9 -DBUILD_DATE="13.08.2010" -DBUILD_VER=0 -DMAJOR_VER=3 -DMINOR_VER=14 -DRELEASE_VER=5 -DVER_SUFFIX="" -Ddigidocpp_EXPORTS -I/home/abuild/rpmbuild/BUILD/libdigidocpp/src -std=gnu++11 -O2 -g -DNDEBUG -fPIC -fvisibility=hidden -fvisibility-inlines-hidden -std=gnu++11 -o CMakeFiles/digidocpp_priv.dir/crypto/TSL.cpp.o -c /home/abuild/rpmbuild/BUILD/libdigidocpp/src/crypto/TSL.cpp
[ 46s] /home/abuild/rpmbuild/BUILD/libdigidocpp/src/crypto/TSL.cpp: In member function 'void digidoc::TSL::validate(const std::vectordigidoc::X509Cert&)':
[ 46s] /home/abuild/rpmbuild/BUILD/libdigidocpp/src/crypto/TSL.cpp:521:38: error: invalid conversion from 'const char16_t*' to 'const XMLCh*' {aka 'const short unsigned int*'} [-fpermissive]
[ 46s] 521 | sig->registerIdAttributeName(u"ID");
[ 46s] | ^~~~~
[ 46s] | |
[ 46s] | const char16_t*
[ 46s] In file included from /usr/include/xsec/framework/XSECProvider.hpp:33,
[ 46s] from /home/abuild/rpmbuild/BUILD/libdigidocpp/src/crypto/TSL.cpp:37:
[ 46s] /usr/include/xsec/dsig/DSIGSignature.hpp:933:45: note: initializing argument 1 of 'void DSIGSignature::registerIdAttributeName(const XMLCh*)'
[ 46s] 933 | void registerIdAttributeName(const XMLCh * name);
[ 46s] | ~~~~~~~~~~~~~~^~~~
[ 46s] make[2]: *** [src/CMakeFiles/digidocpp_priv.dir/build.make:353: src/CMakeFiles/digidocpp_priv.dir/crypto/TSL.cpp.o] Error 1
[ 46s] make[2]: Leaving directory '/home/abuild/rpmbuild/BUILD/libdigidocpp'
[ 46s] make[1]: *** [CMakeFiles/Makefile2:162: src/CMakeFiles/digidocpp_priv.dir/all] Error 2
[ 46s] make[1]: Leaving directory '/home/abuild/rpmbuild/BUILD/libdigidocpp'
[ 46s] make: *** [Makefile:161: all] Error 2
[ 46s] error: Bad exit status from /var/tmp/rpm-tmp.tdjZMl (%build
Currently, it is possible to create a container with a file named mimetype but it is then impossible to open the container.
$ digidoc-tool create --dontsign --file=mimetype test.asice
Version
digidoc-tool version: 3.14.4.1401
libdigidocpp version: 3.14.4.1401
2020-10-29T21:51:12Z D [Connect.cpp:50] - Connecting to URL: https://ec.europa.eu/tools/lotl/eu-lotl.xml
2020-10-29T21:51:12Z D [Connect.cpp:72] - Connecting to Host: ec.europa.eu:443 timeout: 10
2020-10-29T21:51:12Z D [TSL.cpp:573] - Remote ETag: "60eb3-5b22f5b72a3c0"
2020-10-29T21:51:12Z D [TSL.cpp:579] - Cached ETag: "60eb3-5b22f5b72a3c0"
2020-10-29T21:51:12Z D [TSL.cpp:248] - TSL eu-lotl.xml (275) signature is valid
2020-10-29T21:51:13Z D [Connect.cpp:50] - Connecting to URL: https://sr.riik.ee/tsl/estonian-tsl.xml
2020-10-29T21:51:13Z D [Connect.cpp:72] - Connecting to Host: sr.riik.ee:443 timeout: 10
2020-10-29T21:51:13Z D [TSL.cpp:573] - Remote ETag: "46935-5b05e7d1cb100-gzip"
2020-10-29T21:51:13Z D [TSL.cpp:579] - Cached ETag: "46935-5b05e7d1cb100-gzip"
2020-10-29T21:51:13Z D [TSL.cpp:248] - TSL EE.xml (50) signature is valid
2020-10-29T21:51:13Z I [X509CertStore.cpp:84] - Loaded 47 certificates into TSL certificate store.
2020-10-29T21:51:13Z D [ASiC_E.cpp:132] - ASiC_E::createInternal(test.asice)
2020-10-29T21:51:13Z D [ZipSerialize.cpp:62] - ZipSerialize::create(test.asice)
2020-10-29T21:51:13Z D [ZipSerialize.cpp:182] - ZipSerialize::addFile(mimetype)
2020-10-29T21:51:13Z D [ASiC_E.cpp:179] - ASiC_E::createManifest()
2020-10-29T21:51:13Z D [ZipSerialize.cpp:182] - ZipSerialize::addFile(META-INF/manifest.xml)
2020-10-29T21:51:13Z D [ZipSerialize.cpp:182] - ZipSerialize::addFile(mimetype)
2020-10-29T21:51:13Z D [ZipSerialize.cpp:83] - ZipSerialize::~ZipSerialize()
$ digidoc-tool open test.asice
Version
digidoc-tool version: 3.14.4.1401
libdigidocpp version: 3.14.4.1401
2020-10-29T21:51:26Z D [Connect.cpp:50] - Connecting to URL: https://ec.europa.eu/tools/lotl/eu-lotl.xml
2020-10-29T21:51:26Z D [Connect.cpp:72] - Connecting to Host: ec.europa.eu:443 timeout: 10
2020-10-29T21:51:27Z D [TSL.cpp:573] - Remote ETag: "60eb3-5b22f5b72a3c0"
2020-10-29T21:51:27Z D [TSL.cpp:579] - Cached ETag: "60eb3-5b22f5b72a3c0"
2020-10-29T21:51:27Z D [TSL.cpp:248] - TSL eu-lotl.xml (275) signature is valid
2020-10-29T21:51:27Z D [Connect.cpp:50] - Connecting to URL: https://sr.riik.ee/tsl/estonian-tsl.xml
2020-10-29T21:51:27Z D [Connect.cpp:72] - Connecting to Host: sr.riik.ee:443 timeout: 10
2020-10-29T21:51:27Z D [TSL.cpp:573] - Remote ETag: "46935-5b05e7d1cb100-gzip"
2020-10-29T21:51:27Z D [TSL.cpp:579] - Cached ETag: "46935-5b05e7d1cb100-gzip"
2020-10-29T21:51:27Z D [TSL.cpp:248] - TSL EE.xml (50) signature is valid
2020-10-29T21:51:27Z I [X509CertStore.cpp:84] - Loaded 47 certificates into TSL certificate store.
2020-10-29T21:51:27Z D [ASiC_S.cpp:181] - isContainerSimpleFormat(path = 'test.asice')
2020-10-29T21:51:27Z D [ASiC_E.cpp:163] - ASiC_E::openInternal(test.asice)
2020-10-29T21:51:27Z D [ASiContainer.cpp:90] - ASiContainer::ASiContainer(path = 'test.asice')
2020-10-29T21:51:27Z D [ZipSerialize.cpp:69] - ZipSerialize::open(test.asice)
2020-10-29T21:51:27Z D [ZipSerialize.cpp:133] - ZipSerializePrivate::extract(mimetype)
2020-10-29T21:51:27Z D [ASiContainer.cpp:298] - ASiContainer::readMimetype()
2020-10-29T21:51:27Z D [ASiContainer.cpp:106] - mimetype = 'application/vnd.etsi.asic-e+zip'
2020-10-29T21:51:27Z D [ASiC_E.cpp:216] - ASiC_E::readManifest()
2020-10-29T21:51:27Z D [ZipSerialize.cpp:133] - ZipSerializePrivate::extract(META-INF/manifest.xml)
2020-10-29T21:51:27Z D [ASiC_E.cpp:238] - full_path = '/', media_type = 'application/vnd.etsi.asic-e+zip'
2020-10-29T21:51:27Z D [ASiC_E.cpp:238] - full_path = 'mimetype', media_type = 'application/octet-stream'
2020-10-29T21:51:27Z D [ZipSerialize.cpp:83] - ZipSerialize::~ZipSerialize()
Failed to parse container
Exception:
ASiC_E.cpp:324 code(General) Failed to parse manifest
ASiC_E.cpp:258 code(General) Found multiple references of file 'mimetype' in zip container.
It is a valid zip file of course:
$ unzip -lq test.asice
Length Date Time Name
--------- ---------- ----- ----
31 2020-10-29 21:51 mimetype
369 2020-10-29 21:51 META-INF/manifest.xml
6 2020-10-29 21:51 mimetype
--------- -------
406 3 files
I'm guessing it would make sense to error out on creation (similar to trying to add two files with the same name).
In "src/SignatureBES.cpp" there is a check that compares ds:X509IssuerName with the issuer name found in issuer's certificate. The check does not detect mismatching issuer names.
How to reproduce:
Sign using certificate issued by ESTEID 2011, but include "CN=ESTEID-SK 2015,2.5.4.97=#0c0e4e545245452d3130373437303133,O=AS Sertifitseerimiskeskus,C=EE" in the ds:X509IssuerName field.
Would it be possible to support XDG base directory specification?
If you are not familiar with XDG then there is a nice blog that explains benefits of it.
Currently .digidocpp folder is cluttering a bit my $HOME.
Found a place in source where that is set.
I don't fully understand the purpose of that folder, but I sense that it is either a cache or application data.
I was super excited to see this on the pull request, and waited a while but didn't see it being merged. I also cloned the pdf branch from ~metsma/libdigidocpp and compiled, and using an unsigned pdf file in 'digidoc-tool sign' but the tool baild out.
Is it considered in working status on ~metsma/libdigidocpp pdf branch? Thanks!
Would be nice to have an upstream provided tarball, so that it can be linked for packaging as the source.
https://www.id.ee/index.php?id=38861
The easiest way is to open DigiDoc4 Client through which you can access the contents of the documents and verify signatures.
Both https://www.dokobit.com/ and https://www.eesti.ee/en/ require registration.
Not everyone can install software on their computer, think corporate machines with security policy.
It would be super cool to have a public website that allows verifying signatures and public API.
(can limit to 100 per day per IP address without API key)
POST the filevoid digidoc::Signature::validate();, link to the docThat's something 100% totally doable and I think it could facilitate adoption.
How do create signed container when using https://github.com/SK-EID/MID when I get back signature.value?
This comes from open-eid/qdigidoc#94.
A signature that validates successfully on Windows and OS X, is displayed as invalid on Linux, with the following errors:
SignatureXAdES_B.cpp:529 Failed to validate signature: Reference URI="metadata/signableMetadata0.xml" failed to verify
Reference URI="metadata/signableMetadata0.xml" failed to verify
Reference URI="metadata/signableMetadata0.xml" failed to verify
I suspect this could be due to file system case-sensitivity, but that's just a guess.
In src/util/DateTime.cpp get_time and strptime are used to parse timestamps. These are locale-aware and will fail when using pretty much anything except english locales.
Most obvious sign of that happening is log lines like this:
WARN [TSL.cpp:585] - Failed to parse TSL last modified date: Invalid HTTP Full Date format: 'Fri, 08 Jun 2018 15:45:19 GMT'
I'm not certain, but it migh mess with caching.
I get an error when trying to "open" a DigiDoc:
$ ./digidoc-tool open /home/user/Downloads/payment.bdoc
Version
digidoc-tool version: 3.13.5.0
libdigidocpp version: 3.13.5.0
ERROR [TSL.cpp:248] - TSL tl-mp.xml status: Failed to parse XML
DEBUG [Connect.cpp:48] - Connecting to URL: https://ec.europa.eu/information_society/policy/esignature/trusted-list/tl-mp.xml
DEBUG [Connect.cpp:70] - Connecting to Host: ec.europa.eu:443 timeout: 10
[1] 14143 segmentation fault (core dumped) ./digidoc-tool open /home/user/Downloads/payment.bdoc
No issue with downloading the same XML file manually, so it's not a network issue:
$ wget https://ec.europa.eu/information_society/policy/esignature/trusted-list/tl-mp.xml
--2018-03-08 23:53:39-- https://ec.europa.eu/information_society/policy/esignature/trusted-list/tl-mp.xml
Resolving ec.europa.eu (ec.europa.eu)... 147.67.136.61, 147.67.119.61, 147.67.119.136, ...
Connecting to ec.europa.eu (ec.europa.eu)|147.67.136.61|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 398813 (389K) [text/xml]
Saving to: ‘tl-mp.xml’
tl-mp.xml 100%[========================================================================================>] 389.47K 962KB/s in 0.4s
2018-03-08 23:53:40 (962 KB/s) - ‘tl-mp.xml’ saved [398813/398813]
Coming from open-eid/qdigidoc#94. Please allow validation of BES signatures as well as XAdES T.
Building library depends on XSD, downloaded copy is 32bit executable that is no longer supported on macOS.
bad CPU type in executable: ./bin/xsd
The message says:
SignatureXAdES_LT.cpp:177 TimeStamp time and OCSP producedAt are over 15m TS: 20170808074717Z OCSP: 2017-07-12T05:23:09Z
it seems the two arguments are swapped here.
Also, the English message is somewhat cryptic. Shouldn't it end with something like "are over 15 minutes off"?
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.