i want to make digital signature valid using evince so kindly please
make a fix as every one in my office use ubuntu and it will be hard for
them to validate signature without adobe. or kindly send me any ubntu
software that can validate dsc like adobe we are working on a closed
network only i can
** Changed in: evince
Status: Confirmed => Expired
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to poppler in Ubuntu.
https://bugs.launchpad.net/bugs/740506
Title:
verify digital signatures
Status in Evince:
Expired
Status
** Changed in: poppler
Status: Confirmed => Fix Released
** Bug watch added: freedesktop.org Bugzilla #94376
https://bugs.freedesktop.org/show_bug.cgi?id=94376
** Bug watch added: freedesktop.org Bugzilla #94377
https://bugs.freedesktop.org/show_bug.cgi?id=94377
** Bug watch added:
Pushed \o/
Now, this is not "all the work".
We still need to do the glib/qt/cpp frontend work, and that will
probably mean some changes to the new code, but getting this merged is
an important step.
Wonder how to proceed, this bug has 122 comments.
Should we close this one and open different
\o/ Great job guys!
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to poppler in Ubuntu.
https://bugs.launchpad.net/bugs/740506
Title:
verify digital signatures
Status in Evince:
Confirmed
Status in Poppler:
Fix Released
Status in
Thanks Albert for merging it.
Yes it's not finished and I'm intending to pick up last summer's work on the
glib frontend part.
I agree that we should close this bug and open specific ones to track
the frontend development or any other issue we find with the core code.
--
You received this bug
I've opened these bugs
https://bugs.freedesktop.org/show_bug.cgi?id=94376
https://bugs.freedesktop.org/show_bug.cgi?id=94377
https://bugs.freedesktop.org/show_bug.cgi?id=94378
Closing this one
--
You received this bug notification because you are a member of Desktop
Packages, which is
Anyone against merging attachment 120992 and then merging the branch to
master?
I'll do it next week if noone complains.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to poppler in Ubuntu.
https://bugs.launchpad.net/bugs/740506
Title:
Ok, good, so Adrian can you commit your patch?
After that we have attachment 120992 "Load NSS root certs module" that
honestly I don't understand at all but some googleing seems to confirm
it's needed.
And that would be it to try to merge it into master?
--
You received this bug notification
Created attachment 120924
Check in ranges in ByteRange array v2
- renamed isInteger() to isIntOrInt64()
- added and use getIntOrInt64()
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to poppler in Ubuntu.
Andre and Andre what do you think of Adrian's patch?
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to poppler in Ubuntu.
https://bugs.launchpad.net/bugs/740506
Title:
verify digital signatures
Status in Evince:
Confirmed
Status in
I'm in favour of Adrian's patch. It's an improvement with additional sanity
checks on the ByteRange values.
Indeed I tried to see if you could check if a given ByteRange covers the whole
document and also found no easy way to do it with existing poppler
functions/APIs.
--
You received this
Created attachment 120992
Load NSS root certs module
This change is needed to actually do certificate validation, because as
it is NSS is trying to load the module which contains all the builtin
root certs from the Firefox profile directory where it is usually
missing. This way it will load the
(In reply to Albert Astals Cid from comment #120)
> Ok, good, so Adrian can you commit your patch?
Pushed
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to poppler in Ubuntu.
https://bugs.launchpad.net/bugs/740506
Title:
verify digital
(In reply to Markus Kilås from comment #106)
> Created attachment 120758 [details] [review]
> Fix printf for unsigned int
>
> In pdfsig.cc the NetBeans IDE gave warning:
> Mismatching the argument type "unsigned int" and conversion specifier "d"
>
> The attached patch changes from %d to %u in
(In reply to Markus Kilås from comment #108)
> Created attachment 120760 [details] [review]
> Considering offset 0 and signature only covering part of PDF
>
> Note that this patch has not been tested with a non-zero first offset
> document.
Adrian what do you think of this patch?
--
You
(In reply to Albert Astals Cid from comment #114)
> I'm not very convinced by the naming of
> GBool isInteger() { return type == objInt || type == objInt64; }
> what do you think of
> isIntOrInt64() ?
I prefer a single word instead of isXXXorYYY() but I can appreciate that
isInteger() could
(In reply to Adrian Johnson from comment #112)
> Created attachment 120889 [details] [review]
> Check in ranges in ByteRange array
>
> This is an alternative to the patch in comment 108. It checks all ranges in
> the ByteRange array.
I'm not very convinced by the naming of
GBool isInteger() {
(In reply to Andre Guerreiro from comment #105)
> Created attachment 120434 [details] [review]
> Improve robustness of SignatureHandler::validateCertificate
>
> This patch adds additional NULL-checking in
> SignatureHandler::validateCertificate() which avoids segfault for some
> signatures like
Created attachment 120889
Check in ranges in ByteRange array
This is an alternative to the patch in comment 108. It checks all ranges
in the ByteRange array.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to poppler in Ubuntu.
I don't think we need to check if the byte range covers the entire
document. Our job, when verifying the signature, is to use the byte
ranges provided in the signature dictionary. It is up to the pdf
producer to ensure the byte range covers the entire document (excluding
the signature value).
All
Created attachment 120760
Considering offset 0 and signature only covering part of PDF
Note that this patch has not been tested with a non-zero first offset
document.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to poppler in Ubuntu.
Created attachment 120758
Fix printf for unsigned int
In pdfsig.cc the NetBeans IDE gave warning:
Mismatching the argument type "unsigned int" and conversion specifier "d"
The attached patch changes from %d to %u in the printf.
--
You received this bug notification because you are a member of
(In reply to Markus Wernig from comment #104)
> I think the correct statement to issue in this case would be that a part
> ("revision") of the PDF has been signed and to show the validation result
> for that revision, ideally giving the user a chance to view only the signed
> part.
>
> This might
Created attachment 120434
Improve robustness of SignatureHandler::validateCertificate
This patch adds additional NULL-checking in
SignatureHandler::validateCertificate() which avoids segfault for some
signatures like the one contained here:
I think the correct statement to issue in this case would be that a part
("revision") of the PDF has been signed and to show the validation
result for that revision, ideally giving the user a chance to view only
the signed part.
This might even be indispensable when there are multiple signatures
(In reply to Albert Astals Cid from comment #102)
> So we're stuck on "need to use the offset" part, right?
>
> Could someone try to do make the code use it even if we don't have any pdf
> that needs it?
I am not sure if it is good to apply the robustness principle on
security functions. In
So we're stuck on "need to use the offset" part, right?
Could someone try to do make the code use it even if we don't have any
pdf that needs it?
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to poppler in Ubuntu.
(In reply to Adrian Johnson from comment #79)
> + r_values[0] = r2.isInt64() ? r2.getInt64() : r2.getInt();
> + r_values[1] = r3.isInt64() ? r3.getInt64() : r3.getInt();
> + r_values[2] = r4.isInt64() ? r4.getInt64() : r4.getInt();
>
> According the PDF Reference, the ByteRange array contains
(In reply to Markus Kilås from comment #93)
> Created attachment 119174 [details]
> Handle SEC_ERROR_UNTRUSTED_ISSUER
I pushed this and also some code to differentiate between an unknown and
an untrusted issuer (no idea what's the difference but if nss has this
difference i feel we also have to)
Created attachment 119283
Manpage improvement
Here's an improvement to the manpage.
Corrected a typo and added some missing context
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to poppler in Ubuntu.
(In reply to Adrian Johnson from comment #91)
> What is the output of "pkg-config --cflags nss"?
[user@dev-21 poppler]$ pkg-config --cflags nss
-I/usr/include/nss3 -I/usr/include/nspr4
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to
I suggest we change the pdfsig "-c" switch to "-nocert". We can easily
add a single character option if we find it is needed. But we can't get
rid of it if we later regret it.
I'm still waiting for an answer to comment 79.
--
You received this bug notification because you are a member of
(In reply to Andre Guerreiro from comment #97)
> Quoting from ISO 32000-1 section 12.8.1:
> "This range should be the entire file, including the signature dictionary
> but excluding the signature value itself (the Contents entry). Other ranges
> may be used but since they do not check for all
Created attachment 119174
Handle SEC_ERROR_UNTRUSTED_ISSUER
When verifying a PDF signed by a certificate issued by a CA not in the
trust store I would expect to get an error "Certificate isn't Trusted"
however currently the error message actually is the more generic
"Unknown issue with
(In reply to Adrian Johnson from comment #94)
> I suggest we change the pdfsig "-c" switch to "-nocert". We can easily add a
> single character option if we find it is needed. But we can't get rid of it
> if we later regret it.
>
> I'm still waiting for an answer to comment 79.
As said please
(In reply to Andre Guerreiro from comment #100)
> Created attachment 119283 [details] [review]
> Manpage improvement
Pushed
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to poppler in Ubuntu.
https://bugs.launchpad.net/bugs/740506
(In reply to Albert Astals Cid from comment #96)
> As said please let's not spend too much time on arguing over switch names,
> if you really really want -nocert, just push a patch to the
> signatureHandling branch that switches to it.
Done. I've also added a man page. If any further information
What is the output of "pkg-config --cflags nss"?
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to poppler in Ubuntu.
https://bugs.launchpad.net/bugs/740506
Title:
verify digital signatures
Status in Evince:
Confirmed
Status in
(In reply to Markus Kilås from comment #87)
> I'm trying to build the branch (on Fedora 21) but obviously I am missing
> some dependency or not having the right versions etc. Anyone having an idea?
>
> Build output:
> ---
> [user@dev-21 poppler]$ sudo yum install nspr-devel
> Loaded plugins:
I'm trying to build the branch (on Fedora 21) but obviously I am missing
some dependency or not having the right versions etc. Anyone having an
idea?
Build output:
---
[user@dev-21 poppler]$ sudo yum install nspr-devel
Loaded plugins: langpacks, post-transaction-actions, yum-qubes-hooks
Package
(In reply to Adrian Johnson from comment #89)
> (In reply to Markus Kilås from comment #88)
> > I found a workaround for my build issue by creating symlinks:
> > /usr/include/nspr -> /usr/include/nspr4
> > /usr/inclyde/nss -> /usr/include/nss3
>
> Are you using configure or cmake? The nss
(In reply to Markus Kilås from comment #88)
> I found a workaround for my build issue by creating symlinks:
> /usr/include/nspr -> /usr/include/nspr4
> /usr/inclyde/nss -> /usr/include/nss3
Are you using configure or cmake? The nss pkgconfig file should contain
the correct include path.
--
You
(In reply to Adrian Johnson from comment #80)
> (In reply to Albert Astals Cid from comment #70)
> > For the pdfsigverify it seems we kind of agreeed on the compromise to call
> > it pdfsig that only does verification right now but in the future may
> > suppport signing?
>
> This is the only
(In reply to Albert Astals Cid from comment #82)
> Honestly i don't think spending much time on discussing the option name
> makes much sense, we just need to document it properly and that's it.
I raised this issue because pdfimages uses -j for jpeg but -png, -jp2,
-jbig2, -tiff, and -ccitt for
(In reply to Andre Guerreiro from comment #76)
> Created attachment 118745 [details] [review]
> Incremental hashing + large file support
>
> With this patch I've implemented the incremental hashing plus the large file
> support.
>
> This is still untested with files larger than 2GB but is
(In reply to Adam Reichold from comment #81)
> (In reply to Adrian Johnson from comment #78)
> > I agree that the two calls to doGetChars and updateHash should be merged but
> > I don't think a for loop is the best way to process loops where the
> > increment is not exactly the same on each
(In reply to Albert Astals Cid from comment #82)
> > - Is '-c' the best option name for "don't perform certificate validation"?
>
> Honestly i don't think spending much time on discussing the option name
> makes much sense, we just need to document it properly and that's it.
It's vital to put
(In reply to Andre Guerreiro from comment #76)
> Created attachment 118745 [details] [review]
> Incremental hashing + large file support
>
> With this patch I've implemented the incremental hashing plus the large file
> support.
>
> This is still untested with files larger than 2GB but is
(In reply to Albert Astals Cid from comment #70)
> For the pdfsigverify it seems we kind of agreeed on the compromise to call
> it pdfsig that only does verification right now but in the future may
> suppport signing?
This is the only thing left that I think needs fixing before the initial
Created attachment 118745
Incremental hashing + large file support
With this patch I've implemented the incremental hashing plus the large
file support.
This is still untested with files larger than 2GB but is correct for all
the regular test cases I gathered before.
--
You received this bug
(In reply to Albert Astals Cid from comment #72)
> > Large file support.
>
> Do you think this should be a blocker for the initial release or something
> we can improve later?
I think it should be included.
--
You received this bug notification because you are a member of Desktop
Packages,
(In reply to Adrian Johnson from comment #73)
> (In reply to Albert Astals Cid from comment #72)
> > > Large file support.
> >
> > Do you think this should be a blocker for the initial release or something
> > we can improve later?
>
> I think it should be included.
Do you have any file like
(In reply to Albert Astals Cid from comment #74)
> (In reply to Adrian Johnson from comment #73)
> > (In reply to Albert Astals Cid from comment #72)
> > > > Large file support.
> > >
> > > Do you think this should be a blocker for the initial release or something
> > > we can improve later?
> >
(In reply to Adam Reichold from comment #77)
> Some minor suggestions:
>
> * The naming of BLOCK_SIZE and block_len in hashSignedDataBlock seems
> misleading to me, maybe CHUNK_SIZE and block_len?
>
> * The method hashSignedDataBlock could probably be replaced by a static
> function taking the
(In reply to Andre Guerreiro from comment #67)
> Created attachment 118449 [details] [review]
> Support for adbe.pkcs7.sha1 signatures
>
> This patch, to be applied over the previous one, adds support for
> adbe.pkcs7.sha1 signatures so now we should have a more complete coverage of
> actual
So we have two things missing, right?
* Enabling the use of other keystores
* The name of the pdfsigverify tool
I think the enabling the use of other keystores is important but maybe not
critical for the first release.
For the pdfsigverify it seems we kind of agreeed on the compromise to
(In reply to Adrian Johnson from comment #78)
> I agree that the two calls to doGetChars and updateHash should be merged but
> I don't think a for loop is the best way to process loops where the
> increment is not exactly the same on each iteration. Maybe something like
> this:
>
> void
(In reply to Albert Astals Cid from comment #70)
> So we have two things missing, right?
> * Enabling the use of other keystores
> * The name of the pdfsigverify tool
>
>
> I think the enabling the use of other keystores is important but maybe not
> critical for the first release.
>
> For the
(In reply to Andre Guerreiro from comment #66)
> Created attachment 118446 [details] [review]
> NSS conditional build
>
> This patch makes the NSS dependency optional in the CMake and Autotools
> build systems.
Commited too to the signatureHandling branch with some minor changes on
my side to
(In reply to Adrian Johnson from comment #71)
> (In reply to Albert Astals Cid from comment #70)
> > So we have two things missing, right?
> > * Enabling the use of other keystores
> > * The name of the pdfsigverify tool
> >
> >
> > I think the enabling the use of other keystores is important
+ r_values[0] = r2.isInt64() ? r2.getInt64() : r2.getInt();
+ r_values[1] = r3.isInt64() ? r3.getInt64() : r3.getInt();
+ r_values[2] = r4.isInt64() ? r4.getInt64() : r4.getInt();
According the PDF Reference, the ByteRange array contains pairs of
(offset,length).
Why do we ignore the first
Andre*2, answers to the comments from Adam, Adrian and Mantas?
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to poppler in Ubuntu.
https://bugs.launchpad.net/bugs/740506
Title:
verify digital signatures
Status in Evince:
Confirmed
@Adrian
Thanks for the tips on support for large files, progressive hashing and
the NSS includes. We'll be posting our attempts to improve these issues
as individual patches.
I also thought of adding the feature to pdfinfo but it seems wrong to
mix up something which performs various
I've commited the overflow patch, please Adrian's check if it makes you
happy.
I also like the pdfsig idea.
What do we think it's missing before we cna merge this to the mainline?
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to poppler
Created attachment 118449
Support for adbe.pkcs7.sha1 signatures
This patch, to be applied over the previous one, adds support for
adbe.pkcs7.sha1 signatures so now we should have a more complete
coverage of actual signed PDFs.
--
You received this bug notification because you are a member of
Created attachment 118446
NSS conditional build
This patch makes the NSS dependency optional in the CMake and Autotools
build systems.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to poppler in Ubuntu.
Created attachment 118398
Fix for Buffer overflow
Regarding the illegal ByteRange values which would cause overflow this
patch should fix it
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to poppler in Ubuntu.
(In reply to Andre Guerreiro from comment #63)
> I also thought of adding the feature to pdfinfo but it seems wrong to mix up
> something which performs various computations and relies on external state
> (NSS cert DB) to pdfinfo which just reads metadata from the file itself.
pdfinfo already
I've pushed your patch with some fixlets from my side to
http://cgit.freedesktop.org/poppler/poppler/log/?h=signatureHandling
I have three questions we need to answer before i merge it to master:
* Do we really want to make NSS mandatory?
* Do we want to provide a way for frontends to give
Hmm, why does this search for Firefox's profile – why not use the shared
nssdb (sql:~/.pki/nssdb) like Evolution and Chromium do?
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to poppler in Ubuntu.
https://bugs.launchpad.net/bugs/740506
I am not sure if I am just missing where this is verified earlier, but
isn't
unsigned int signed_data_len = r2.getInt()+r4.getInt();
unsigned char *to_check = (unsigned char *)gmalloc(signed_data_len);
//Read the 2 slices of data that are signed
doc->getBaseStream()->setPos(0);
@Albert
Thanks for the improvements.
Regarding your 3 questions:
1- I've no objection to make the feature optional. I understand there
are people building more minimal versions of poppler that dislike
additional dependencies.
2- Yes we should. Our defaults are meant to take advantage of the
I don't think NSS should be mandatory. It is not required for rendering
PDFs. configure/cmake should include NSS in the "building poppler with
support for" summary.
> byte_range->arrayGet(1, );
> byte_range->arrayGet(2, );
> byte_range->arrayGet(3, );
>
> unsigned int signed_data_len =
Created attachment 118195
poppler nss signature support - v6
Sorry, there were still some missing NULL checks and a useless new(),
here's a new one.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to poppler in Ubuntu.
Created attachment 118193
poppler nss signature support - v5 - refactor
Here's a new patch following Albert's recommendations.
We've expanded the FormFieldSignature and FormFieldWidget classes to expose the
signature method.
We also added checking for non-supported signature types as we only
Sorry for the succession of patches. This one fixes some remaining leaks
in the new PDFDoc methods and improves the indentation
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to poppler in Ubuntu.
https://bugs.launchpad.net/bugs/740506
Created attachment 118027
memory leaks fixed
So here I tried fixing most memory leaks.
André Guerreiro implemented the cmake way of pkgconfig.
thoughts?
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to poppler in Ubuntu.
Created attachment 118050
poppler nss signature support - v4
Minor changes fixing what Albert pointed out.
Fixed bug in countSignatures() for documents without signatures
pdfsigverify does go through all code paths up to PDFDoc, it doesn't go
up to poppler-doccument.
But we do have a patch for
Created attachment 118036
poppler nss signature support - v3
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to poppler in Ubuntu.
https://bugs.launchpad.net/bugs/740506
Title:
verify digital signatures
Status in Evince:
Confirmed
Another file that aborts
https://bugs.freedesktop.org/attachment.cgi?id=12982
Also
+/* Build against libcurl. */
+#cmakedefine ENABLE_OPENSSL 1
+
i guess just sneaked in to the patch and is not needed?
Also please use our own error() function instead of perror
Also one question, does
I've had look at the code (in poppler/ not glib/ i'll leave that to the
glib/ experts) and have some minor and some major comments.
Minor:
* There's 3 use of malloc i could find, for completion i guess it's better if
you use gmalloc
* SigStatusStruct should be a C++ class
Medium:
* I'm not
Nice work.
Some small things that need fixing.
the cmake way of using pkgconfig is very simple, see
./cmake/modules/FindGTK.cmake for example
You need to free more Objects, every time you do a get object an object
you have to free it, e.g. in countSignatures you need to free fields, f,
type,
Created attachment 117885
PDF signature verification using NSS
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to poppler in Ubuntu.
https://bugs.launchpad.net/bugs/740506
Title:
verify digital signatures
Status in Evince:
Confirmed
Sorry for the long absence and here's another attempt at solving this
issue.
I just attached a patch developed by me and André Esser which adds signature
verification support to poppler core and the glib frontend.
It uses the NSS CMS API for the crypto operations (signature and certificate
When was this bug's importance last considered? It was opened in 2008.
Digital signing and validation of PDFs, including using multiple
timestamps from Time Stamp Authorities, is now commonplace on Windows
given support in Acrobat, commercial PDF-producing libraries, etc. The
free desktop needs
The bug importance doesn't matter, what matters is that if there's
someone with the time to work on this.
I'd say there's not much people (or noone) in the current team with such
amount of time.
--
You received this bug notification because you are a member of Desktop
Packages, which is
Hi all
Funding is all very well, and +1 for the initiative!
But first we'll need to find developers who are willing to take up the
task.
Is there anyone interested in implementing this (immensely important,
believe me!) feature? Can we spur his or her interest with money?
Or can we say that
** Bug watch added: freedesktop.org Bugzilla #83940
https://bugs.freedesktop.org/show_bug.cgi?id=83940
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to poppler in Ubuntu.
https://bugs.launchpad.net/bugs/740506
Title:
verify digital
** Also affects: evince via
https://bugzilla.gnome.org/show_bug.cgi?id=614929
Importance: Unknown
Status: Unknown
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to poppler in Ubuntu.
https://bugs.launchpad.net/bugs/740506
** Changed in: evince
Status: Unknown = Confirmed
** Changed in: evince
Importance: Unknown = Wishlist
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to poppler in Ubuntu.
https://bugs.launchpad.net/bugs/740506
Title:
verify
There is now a new sponsor. Bounty is up to US $300.
I hope there will be some more progress here soon.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to poppler in Ubuntu.
https://bugs.launchpad.net/bugs/740506
Title:
verify digital
(In reply to comment #37)
Hi, as I cannot help with coding (on this specific issue), I've opened a
bounty on FreedomSponsors:
http://www.freedomsponsors.org/core/issue/319/support-for-digital-signatures
Anyone interested on this bug is welcome to pledge more money by visiting
the above
(In reply to comment #38)
(In reply to comment #37)
Hi, as I cannot help with coding (on this specific issue), I've opened a
bounty on FreedomSponsors:
http://www.freedomsponsors.org/core/issue/319/support-for-digital-signatures
Anyone interested on this bug is welcome to pledge
(In reply to comment #37)
Hi, as I cannot help with coding (on this specific issue), I've opened a
bounty on FreedomSponsors:
http://www.freedomsponsors.org/core/issue/319/support-for-digital-signatures
Anyone interested on this bug is welcome to pledge more money by visiting
the above
Hi, as I cannot help with coding (on this specific issue), I've opened a
bounty on FreedomSponsors:
http://www.freedomsponsors.org/core/issue/319/support-for-digital-
signatures
Anyone interested on this bug is welcome to pledge more money by
visiting the above link, this money will probably not
Comment on attachment 37425
Initial patch for parsing digitally signed PDFs
diff --git a/poppler/Form.cc b/poppler/Form.cc
index 4df8a7d..1da9776 100644
--- a/poppler/Form.cc
+++ b/poppler/Form.cc
@@ -1107,11 +1107,28 @@ void FormFieldChoice::_createChoicesTab ()
(In reply to comment #33)
OK, NSS with shared DB is what I'll pursue from now on.
Thanks everyone for the input.
Andre, any update on the status of this? Thanks
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to poppler in Ubuntu.
weibo?
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to poppler in Ubuntu.
https://bugs.launchpad.net/bugs/740506
Title:
verify digital signatures
Status in Poppler:
Confirmed
Status in “poppler” package in Ubuntu:
Triaged
Bug
So if I understood correctly Qt is only using the dlopen approach to overcome
restrictions to crypto exports but not (L)GPL incompatibilities, like stated
here:
http://qt-project.org/doc/qt-4.8/ssl.html
Getting back to our point I'll need the definitive opinion from Poppler
maintainers on
1 - 100 of 121 matches
Mail list logo
