Update ChangeLog and manual for openssl crypto provider

This commit is contained in:
Jay Berkenbilt 2020-04-06 09:24:12 -04:00
parent 3d0de5b924
commit 1360b530ec
2 changed files with 47 additions and 24 deletions

View File

@ -1,3 +1,9 @@
2020-04-06 Jay Berkenbilt <ejb@ql.org>
* Add openssl crypto provider, contributed by Dean Scarff. This
provider is implemented using OpenSSL and also works with
BoringSSL.
2020-04-04 Jay Berkenbilt <ejb@ql.org>
* Add a new provideStreamData method for StreamDataProvider that

View File

@ -138,7 +138,9 @@
<para>
<emphasis>Recommended but not required:</emphasis> gnutls:
<ulink url="https://www.gnutls.org/">https://www.gnutls.org/</ulink>
to be able to use the gnutls crypto provider
to be able to use the gnutls crypto provider, and/or openssl:
<ulink url="https://openssl.org/">https://openssl.org/</ulink>
to be able to use the openssl crypto provider.
</para>
</listitem>
<listitem>
@ -271,10 +273,11 @@ make
</para>
<para>
Starting with qpdf version 9.1.0, the available implementations
are <literal>native</literal> and <literal>gnutls</literal>.
Additional implementations may be added if needed. It is also
possible for a developer to provide their own implementation
without modifying the qpdf library.
are <literal>native</literal> and <literal>gnutls</literal>. In
qpdf 10.0.0, <literal>openssl</literal> was added. Additional
implementations may be added if needed. It is also possible for a
developer to provide their own implementation without modifying
the qpdf library.
</para>
<sect2 id="ref.crypto.build">
<title>Build Support For Crypto Providers</title>
@ -344,9 +347,10 @@ make
own external dependencies that can be omitted if the crypto
provider is not used. For example, if you are building qpdf
yourself and are using an environment that does not support
gnutls, you can ensure that <literal>USE_CRYPTO_NATIVE</literal>
is defined, <literal>USE_CRYPTO_GNUTLS</literal> is not defined,
and <literal>DEFAULT_CRYPTO</literal> is defined to
gnutls or openssl, you can ensure that
<literal>USE_CRYPTO_NATIVE</literal> is defined,
<literal>USE_CRYPTO_GNUTLS</literal> is not defined, and
<literal>DEFAULT_CRYPTO</literal> is defined to
<literal>"native"</literal>. Then you must include the source
files used in the native implementation, some of which were added
or renamed from earlier versions, to your build, and you can
@ -4794,6 +4798,35 @@ print "\n";
</listitem>
</itemizedlist>
</listitem>
<listitem>
<para>
Build/Packaging Changes
</para>
<itemizedlist>
<listitem>
<para>
Add a <literal>openssl</literal> crypto provider, which is
implemented with OpenSSL and also works with BoringSSL.
Thanks to Dean Scarff for this contribution. If you maintain
qpdf for a distribution, pay special attention to make sure
that you are including support for the crypto providers you
want. Package maintainers will have to weigh the advantages
of allowing users to pick a crypto provider at runtime
against the disadvantages of adding more dependencies to
qpdf.
</para>
</listitem>
<listitem>
<para>
Allow qpdf to built on stripped down systems whose C/C++
libraries lack the <classname>wchar_t</classname> type.
Search for <classname>wchar_t</classname> in qpdf's
README.md for details. This should be very rare, but it is
known to be helpful in some embedded environments.
</para>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<para>
CLI Enhancements
@ -4944,22 +4977,6 @@ print "\n";
</listitem>
</itemizedlist>
</listitem>
<listitem>
<para>
Build Changes
</para>
<itemizedlist>
<listitem>
<para>
Allow qpdf to built on stripped down systems whose C/C++
libraries lack the <classname>wchar_t</classname> type.
Search for <classname>wchar_t</classname> in qpdf's
README.md for details. This should be very rare, but it is
known to be helpful in some embedded environments.
</para>
</listitem>
</itemizedlist>
</listitem>
</itemizedlist>
</listitem>
</varlistentry>