I'm the author of qpdf.  You are certainly correct to be concerned about the security exposure of qpdf, and I'd be the last one to say that it is 100% of any potential for security problems.  However I believe that it is in relatively good shape from a security perspective, and I'll briefly outline why I think this is the case.

QPDF is very careful with memory management.  Almost all of the memory used by QPDF is managed using reference-counted smart pointers.  QPDF makes heavy use of a bound-checked buffer class.  QPDF rarely reads large amounts of data into memory and, in particular, does not read arbitrary streams from user files into memory at once.  The large file tests of QPDF run with a memory footprint much smaller than the size of the largest stream in the file.

QPDF has a very thorough test suite with nearly complete code coverage.  QPDF actually makes use of an explicit coverage technique I presented a paper on in 2004.  Specifically it marks certain parts of the code with a call that essentially checks to make sure a certain condition occurred during the run of test suite.  The test suite contains many examples of invalid files, though I admit that most of these are files I specifically created to exercise certain error conditions.  Before every release, I run the entire test suite through valgrind and never release if there are any errors.

At a previous job, I had access to the Klocwork static analyzer.  When I ran qpdf through it, never having previously exposed qpdf to a static analyzer, it only found one real issue (two instances of not exiting after reporting an error that a file couldn't be opened), and one case where it was hard to tell that memory was being properly checked.  In the second case, I just clarified the code, but there wasn't actually an error condition.  You can see the commit on github: https://github.com/qpdf/qpdf/commit/0ded90eff979c0a329736861995b2516139de114.

I have tried to code QPDF in a manner that is careful from a security perspective.  I would refer you to https://github.com/qpdf/qpdf/blob/master/libqpdf/QPDF.cc and the method read_xrefTable.  This method reads lines from the input file but adds constraints to make sure it never reads more than 50 bytes per line, thus preventing a file whose xref offset points to a place with extremely long lines from making qpdf allocate a huge amount of memory.  When it reads xref entries, it validates each entry against a regular expression and throws an exception if it doesn't match.  Only then does it actually trust the offsets.

As I read the code carefully, I see that there may be opportunities to force qpdf to try to read outside the bounds of a file by constructing a PDF file with object streams that have invalid offsets.  I will audit this part of the code and strengthen it before the next release.  In spite of this, qpdf never writes to memory associated with the input file, so causing it to write past a buffer boundary would be very difficult, and I can't think of any way of causing it to take action such as creating a file in the file system, exposing credentials, or anything of that sort.

I have a pretty strong background in dealing with security issues in code.  I've been programming in C or C++ since 1985, spent a little time working on the Kerberos design and implementation teams between 1988 and 1991, and I am  the debian maintainer for tiff and ICU, both of which have relatively regular security issues.  Understanding and, in some cases, backporting those security fixes has also improved my understanding of the kinds of pitfalls programmers often fall into.

Finally, if there are any security issues found, I will be very responsive in fixing them.

So, while adding qpdf to main is not risk-free from a security angle, I think the risks are relatively low, and I believe qpdf is probably in better shape from a security angle than many of the packages already in main.  I would be happy to address any specific concerns you might have in this area.