This is an automated email from the git hooks/post-receive script.
sparks pushed a commit to branch master
in repository defensive-coding-guide.
commit dc0ff1a16e89bdd14cf0f157bacc40a15367702f
Author: Florian Weimer <fweimer(a)redhat.com>
Date: Fri Jun 6 13:26:37 2014 +0200
Packaging: Add section on delayed certificate generation
---
defensive-coding/en-US/Tasks-Packaging.xml | 37 +++++++++++++++++++++++++++++-
1 file changed, 36 insertions(+), 1 deletion(-)
diff --git a/defensive-coding/en-US/Tasks-Packaging.xml
b/defensive-coding/en-US/Tasks-Packaging.xml
index 95bfbc6..07ee072 100644
--- a/defensive-coding/en-US/Tasks-Packaging.xml
+++ b/defensive-coding/en-US/Tasks-Packaging.xml
@@ -20,7 +20,8 @@
such use, generating the key pair at package installation time
when preparing system images for use in the cluster is
reasonable. For other use cases, it is necessary to generate
- the key pair before the service is started for the first time.
+ the key pair before the service is started for the first time,
+ see <xref
linkend="sect-Defensive_Coding-Tasks-Packaging-Certificates-Service"/>.
</para>
<important>
<para>
@@ -128,4 +129,38 @@ fi
<application>chmod</application> invocation.
</para>
</section>
+ <section
id="sect-Defensive_Coding-Tasks-Packaging-Certificates-Service">
+ <title>Generating X.509 self-signed certificates before service
+ start</title>
+ <para>
+ An alternative way to automatically provide an X.509 key pair is
+ to create it just before the service is started for the first
+ time. This ensures that installation images which are created
+ from installed RPM packages receive different key material.
+ Creating the key pair at package installation time (see <xref
+ linkend="sect-Defensive_Coding-Tasks-Packaging-Certificates"/>)
+ would put the key into the image, which may or may not make
+ sense.
+ </para>
+ <important>
+ <para>
+ The caveats about the way the key is generated in <xref
+ linkend="sect-Defensive_Coding-Tasks-Packaging-Certificates"/>
+ apply to this procedure as well.
+ </para>
+ </important>
+ <para>
+ Generating key material before service start may happen very
+ early during boot, when the kernel randomness pool has not yet
+ been initialized. Currently, the only way to check for the
+ initialization is to look for the kernel message
+ <literal>random: nonblocking pool is initialized</literal>. In
+ theory, it is also possible to read from
+ <filename>/dev/random</filename> while generating the key
+ material (instead of <filename>/dev/urandom</filename>), but
+ this can block not just during the boot process, but also much
+ later at run time, and generally results in a poor user
+ experience.
+ </para>
+ </section>
</chapter>
--
To stop receiving notification emails like this one, please contact
the administrator of this repository.
Show replies by date