Detect Signatures in PDF files using Aspose.PDF for .NET - ContainsSignature is slow on small PDFs

Aspose.PDF Product Family
1

Aspose.PDF 20.8

I am using the following code to check whether PDF is digitally signed.

var pdf = new Document(path);
if (!pdf.IsEncrypted)
{
    using (var pdfSign = new PdfFileSignature())
    {
        pdfSign.BindPdf(p);
        if (pdfSign.ContainsSignature())
        {
            return true
        }

        pdfSign.Close();
    }
}
return false;

ContainsSignature is executed for more than 30 seconds on really small PDF (attached). It causes big delays in application for no visible reason.

sample.pdf (440.6 KB)

For internal usage: MDP-9998, DD-3653, MDP-9739, MDP-9920.

2

@licenses

We were able to notice the delay and logged an issue as PDFNET-48659 in our issue tracking system. We will further check it in details and keep you posted with the status of its correction. Please be patient and spare us some time.

We are sorry for the inconvenience.

3

Hi.

I found one more issue related to ContainsSignature method.

As you already know, when application thread enters ContainsSignature, it may “hang” there for 40-60 seconds (see PDFNET-48659 reported above).

I tried to implement a temporary workaround until the issue is not fixed. The idea was to execute ContainsSignature in the separate thread (will refer to it as signature thread) and abort it when timeout expires.

Code sample

public static void TestPdfHelper(string p)
{
    var started = DateTime.Now;

    var pdf = new Document(p);
    if (!pdf.IsEncrypted)
    {
        using (var pdfSign = new PdfFileSignature())
        {
            pdfSign.BindPdf(p);
            if (pdfSign.ContainsSignature())
            {
                var IsDigitallySigned = true;
            }
        }
    }
    var spent = DateTime.Now - started;
}
//-------------------------------------------------

var th = new Thread(() =>
{
    TestPdfHelper("sample.pdf");
});

th.Start();
Thread.Sleep(15000);
th.Abort();
th.Join();

Issue

  • Abort method does not abort signature thread. Probably, because signature thread is executing unmanaged code inside ContainsSignature.
  • But what even worse, it seems that signature thread never exits ContainsSignature method, if Thread.Abort is called.

I tested with the PDF document attached in the first post. I waited for more than 20 minutes and signature thread was still somewhere in the ContainsSignature method. One more time, to make it clear.

  • If Thread.Abort is not called, ContainsSignature finishes in approximately 30 seconds (PDFNET-48659).
  • If Thread.Abort is called, then signature thread is not aborted and never exits ContainsSignature method.
4

@licenses

We have updated the issue information under the ticket ID PDFNET-48659 and will surely investigate it accordingly. We will inform you as soon as the ticket is resolved. Please spare us little time.

5

Hi.

More and more customers are reporting the issue in my app.

Could you please give an update?.

  • Have the dev team identified the cause of the issue?
  • Do devs know how to fix the issue?
  • When this issue is going to be fixed?

Thanks.

6

@licenses

We really apologize for the inconvenience caused by this issue. Please note that the investigation against your issue is currently underway. The ticket is being handled on the basis of first come first serve and we will surely resolve it. As soon as its analysis is completed, we will be able to share some reliable ETA with you. We will inform you as soon as we have additional updates in this regard. Please give us some time.

We are sorry for the inconvenience.

7

Sorry for bothering you again.

But I am getting more and more angry customers.

Could you please give an update?

  • Have the dev team identified the cause of the issue?
  • Do devs know how to fix the issue?
  • When this issue is going to be fixed?

Thanks.

8

@licenses

We regret that earlier logged ticket is not yet resolved. Please note that performance related issues are used to be complex in nature and require significant amount of time in order to get resolved. We have however logged your concerns and raised the issue to next level of priority. We will surely inform you as soon as it is investigated and we have some news about its ETA. We highly appreciate your patience in this matter.

We are sorry for the inconvenience caused.

9

Is it being looked at (are developers working on it now)?
If not, when are developers going to work on the issue?
Or the issue was put in a long queue of other issues?

I need to know the answers. Please be honest. We cannot wait forever. W/o knowing details (dates) we will have to search for alternatives to Aspose.PDF.

10

@licenses

The earlier logged ticket is under investigation phase and we have already escalated it to next priority level. We are currently investigating it and as soon as we are done with analysis, we will be able to share some ETA with you. We highly appreciate your patience and cooperation in this matter. Please give us some time.

We apologize for your inconvenience.

11

Hi.

What is the status of the issue. Is it being worked on? Or it sits in the backlog?

Thanks.

12

@licenses

The issue is still being investigated and we are afraid that it could not get resolved yet. We will surely inform you as soon as we have some definite updates regarding its fix. We highly appreciate your patience and comprehension in this regard.

We apologize for the inconvenience.

13

The issues you have found earlier (filed as PDFNET-48659) have been fixed in Aspose.PDF for .NET 21.9.