<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-toradex.git/crypto/asymmetric_keys, branch v3.16-rc1</title>
<subtitle>Linux kernel for Apalis and Colibri modules</subtitle>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/'/>
<entry>
<title>Revert "KEYS: verify a certificate is signed by a 'trusted' key"</title>
<updated>2013-11-24T00:38:17+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2013-11-24T00:38:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=4c1cc40a2d49500d84038ff751bc6cd183e729b5'/>
<id>4c1cc40a2d49500d84038ff751bc6cd183e729b5</id>
<content type='text'>
This reverts commit 09fbc47373826d67531380662b516de2da120545, which
caused the following build errors:

  crypto/asymmetric_keys/x509_public_key.c: In function ‘x509_key_preparse’:
  crypto/asymmetric_keys/x509_public_key.c:237:35: error: ‘system_trusted_keyring’ undeclared (first use in this function)
   ret = x509_validate_trust(cert, system_trusted_keyring);
                                   ^
  crypto/asymmetric_keys/x509_public_key.c:237:35: note: each undeclared identifier is reported only once for each function it appears in

reported by Jim Davis. Mimi says:

 "I made the classic mistake of requesting this patch to be upstreamed
  at the last second, rather than waiting until the next open window.

  At this point, the best course would probably be to revert the two
  commits and fix them for the next open window"

Reported-by: Jim Davis &lt;jim.epost@gmail.com&gt;
Acked-by: Mimi Zohar &lt;zohar@linux.vnet.ibm.com&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This reverts commit 09fbc47373826d67531380662b516de2da120545, which
caused the following build errors:

  crypto/asymmetric_keys/x509_public_key.c: In function ‘x509_key_preparse’:
  crypto/asymmetric_keys/x509_public_key.c:237:35: error: ‘system_trusted_keyring’ undeclared (first use in this function)
   ret = x509_validate_trust(cert, system_trusted_keyring);
                                   ^
  crypto/asymmetric_keys/x509_public_key.c:237:35: note: each undeclared identifier is reported only once for each function it appears in

reported by Jim Davis. Mimi says:

 "I made the classic mistake of requesting this patch to be upstreamed
  at the last second, rather than waiting until the next open window.

  At this point, the best course would probably be to revert the two
  commits and fix them for the next open window"

Reported-by: Jim Davis &lt;jim.epost@gmail.com&gt;
Acked-by: Mimi Zohar &lt;zohar@linux.vnet.ibm.com&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6</title>
<updated>2013-11-24T00:18:25+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2013-11-24T00:18:25+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=26b265cd29dde56bf0901c421eabc7ae815f38c4'/>
<id>26b265cd29dde56bf0901c421eabc7ae815f38c4</id>
<content type='text'>
Pull crypto update from Herbert Xu:
 - Made x86 ablk_helper generic for ARM
 - Phase out chainiv in favour of eseqiv (affects IPsec)
 - Fixed aes-cbc IV corruption on s390
 - Added constant-time crypto_memneq which replaces memcmp
 - Fixed aes-ctr in omap-aes
 - Added OMAP3 ROM RNG support
 - Add PRNG support for MSM SoC's
 - Add and use Job Ring API in caam
 - Misc fixes

[ NOTE! This pull request was sent within the merge window, but Herbert
  has some questionable email sending setup that makes him public enemy
  #1 as far as gmail is concerned.  So most of his emails seem to be
  trapped by gmail as spam, resulting in me not seeing them.  - Linus ]

* git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6: (49 commits)
  crypto: s390 - Fix aes-cbc IV corruption
  crypto: omap-aes - Fix CTR mode counter length
  crypto: omap-sham - Add missing modalias
  padata: make the sequence counter an atomic_t
  crypto: caam - Modify the interface layers to use JR API's
  crypto: caam - Add API's to allocate/free Job Rings
  crypto: caam - Add Platform driver for Job Ring
  hwrng: msm - Add PRNG support for MSM SoC's
  ARM: DT: msm: Add Qualcomm's PRNG driver binding document
  crypto: skcipher - Use eseqiv even on UP machines
  crypto: talitos - Simplify key parsing
  crypto: picoxcell - Simplify and harden key parsing
  crypto: ixp4xx - Simplify and harden key parsing
  crypto: authencesn - Simplify key parsing
  crypto: authenc - Export key parsing helper function
  crypto: mv_cesa: remove deprecated IRQF_DISABLED
  hwrng: OMAP3 ROM Random Number Generator support
  crypto: sha256_ssse3 - also test for BMI2
  crypto: mv_cesa - Remove redundant of_match_ptr
  crypto: sahara - Remove redundant of_match_ptr
  ...
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Pull crypto update from Herbert Xu:
 - Made x86 ablk_helper generic for ARM
 - Phase out chainiv in favour of eseqiv (affects IPsec)
 - Fixed aes-cbc IV corruption on s390
 - Added constant-time crypto_memneq which replaces memcmp
 - Fixed aes-ctr in omap-aes
 - Added OMAP3 ROM RNG support
 - Add PRNG support for MSM SoC's
 - Add and use Job Ring API in caam
 - Misc fixes

[ NOTE! This pull request was sent within the merge window, but Herbert
  has some questionable email sending setup that makes him public enemy
  #1 as far as gmail is concerned.  So most of his emails seem to be
  trapped by gmail as spam, resulting in me not seeing them.  - Linus ]

* git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6: (49 commits)
  crypto: s390 - Fix aes-cbc IV corruption
  crypto: omap-aes - Fix CTR mode counter length
  crypto: omap-sham - Add missing modalias
  padata: make the sequence counter an atomic_t
  crypto: caam - Modify the interface layers to use JR API's
  crypto: caam - Add API's to allocate/free Job Rings
  crypto: caam - Add Platform driver for Job Ring
  hwrng: msm - Add PRNG support for MSM SoC's
  ARM: DT: msm: Add Qualcomm's PRNG driver binding document
  crypto: skcipher - Use eseqiv even on UP machines
  crypto: talitos - Simplify key parsing
  crypto: picoxcell - Simplify and harden key parsing
  crypto: ixp4xx - Simplify and harden key parsing
  crypto: authencesn - Simplify key parsing
  crypto: authenc - Export key parsing helper function
  crypto: mv_cesa: remove deprecated IRQF_DISABLED
  hwrng: OMAP3 ROM Random Number Generator support
  crypto: sha256_ssse3 - also test for BMI2
  crypto: mv_cesa - Remove redundant of_match_ptr
  crypto: sahara - Remove redundant of_match_ptr
  ...
</pre>
</div>
</content>
</entry>
<entry>
<title>KEYS: The RSA public key algorithm needs to select MPILIB</title>
<updated>2013-11-01T15:24:51+00:00</updated>
<author>
<name>David Howells</name>
<email>dhowells@redhat.com</email>
</author>
<published>2013-11-01T15:11:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=dbed71416332d24e4e9ba26dcf90cd86a93c06f1'/>
<id>dbed71416332d24e4e9ba26dcf90cd86a93c06f1</id>
<content type='text'>
The RSA public key algorithm needs to select MPILIB directly in Kconfig as the
'select' directive is not recursive and is thus MPILIB is not enabled by
selecting MPILIB_EXTRA.

Without this, the following errors can occur:

	crypto/built-in.o: In function `RSA_verify_signature':
	rsa.c:(.text+0x1d347): undefined reference to `mpi_get_nbits'
	rsa.c:(.text+0x1d354): undefined reference to `mpi_get_nbits'
	rsa.c:(.text+0x1d36e): undefined reference to `mpi_cmp_ui'
	rsa.c:(.text+0x1d382): undefined reference to `mpi_cmp'
	rsa.c:(.text+0x1d391): undefined reference to `mpi_alloc'
	rsa.c:(.text+0x1d3b0): undefined reference to `mpi_powm'
	rsa.c:(.text+0x1d3c3): undefined reference to `mpi_free'
	rsa.c:(.text+0x1d3d8): undefined reference to `mpi_get_buffer'
	rsa.c:(.text+0x1d4d4): undefined reference to `mpi_free'
	rsa.c:(.text+0x1d503): undefined reference to `mpi_get_nbits'

Reported-by: Randy Dunlap &lt;rdunlap@infradead.org&gt;
Signed-off-by: David Howells &lt;dhowells@redhat.com&gt;
Acked-by: Randy Dunlap &lt;rdunlap@infradead.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The RSA public key algorithm needs to select MPILIB directly in Kconfig as the
'select' directive is not recursive and is thus MPILIB is not enabled by
selecting MPILIB_EXTRA.

Without this, the following errors can occur:

	crypto/built-in.o: In function `RSA_verify_signature':
	rsa.c:(.text+0x1d347): undefined reference to `mpi_get_nbits'
	rsa.c:(.text+0x1d354): undefined reference to `mpi_get_nbits'
	rsa.c:(.text+0x1d36e): undefined reference to `mpi_cmp_ui'
	rsa.c:(.text+0x1d382): undefined reference to `mpi_cmp'
	rsa.c:(.text+0x1d391): undefined reference to `mpi_alloc'
	rsa.c:(.text+0x1d3b0): undefined reference to `mpi_powm'
	rsa.c:(.text+0x1d3c3): undefined reference to `mpi_free'
	rsa.c:(.text+0x1d3d8): undefined reference to `mpi_get_buffer'
	rsa.c:(.text+0x1d4d4): undefined reference to `mpi_free'
	rsa.c:(.text+0x1d503): undefined reference to `mpi_get_nbits'

Reported-by: Randy Dunlap &lt;rdunlap@infradead.org&gt;
Signed-off-by: David Howells &lt;dhowells@redhat.com&gt;
Acked-by: Randy Dunlap &lt;rdunlap@infradead.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ima: provide support for arbitrary hash algorithms</title>
<updated>2013-10-25T21:16:58+00:00</updated>
<author>
<name>Dmitry Kasatkin</name>
<email>d.kasatkin@samsung.com</email>
</author>
<published>2013-04-25T07:43:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=c7c8bb237fdbff932b5e431aebee5ce862ea07d1'/>
<id>c7c8bb237fdbff932b5e431aebee5ce862ea07d1</id>
<content type='text'>
In preparation of supporting more hash algorithms with larger hash sizes
needed for signature verification, this patch replaces the 20 byte sized
digest, with a more flexible structure.  The new structure includes the
hash algorithm, digest size, and digest.

Changelog:
- recalculate filedata hash for the measurement list, if the signature
  hash digest size is greater than 20 bytes.
- use generic HASH_ALGO_
- make ima_calc_file_hash static
- scripts lindent and checkpatch fixes

Signed-off-by: Dmitry Kasatkin &lt;d.kasatkin@samsung.com&gt;
Signed-off-by: Mimi Zohar &lt;zohar@linux.vnet.ibm.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
In preparation of supporting more hash algorithms with larger hash sizes
needed for signature verification, this patch replaces the 20 byte sized
digest, with a more flexible structure.  The new structure includes the
hash algorithm, digest size, and digest.

Changelog:
- recalculate filedata hash for the measurement list, if the signature
  hash digest size is greater than 20 bytes.
- use generic HASH_ALGO_
- make ima_calc_file_hash static
- scripts lindent and checkpatch fixes

Signed-off-by: Dmitry Kasatkin &lt;d.kasatkin@samsung.com&gt;
Signed-off-by: Mimi Zohar &lt;zohar@linux.vnet.ibm.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>keys: change asymmetric keys to use common hash definitions</title>
<updated>2013-10-25T21:15:18+00:00</updated>
<author>
<name>Dmitry Kasatkin</name>
<email>d.kasatkin@samsung.com</email>
</author>
<published>2013-05-06T12:58:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=3fe78ca2fb1d61ea598e63fcbf38aec76b36b3a8'/>
<id>3fe78ca2fb1d61ea598e63fcbf38aec76b36b3a8</id>
<content type='text'>
This patch makes use of the newly defined common hash algorithm info,
replacing, for example, PKEY_HASH with HASH_ALGO.

Changelog:
- Lindent fixes - Mimi

CC: David Howells &lt;dhowells@redhat.com&gt;
Signed-off-by: Dmitry Kasatkin &lt;d.kasatkin@samsung.com&gt;
Signed-off-by: Mimi Zohar &lt;zohar@linux.vnet.ibm.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This patch makes use of the newly defined common hash algorithm info,
replacing, for example, PKEY_HASH with HASH_ALGO.

Changelog:
- Lindent fixes - Mimi

CC: David Howells &lt;dhowells@redhat.com&gt;
Signed-off-by: Dmitry Kasatkin &lt;d.kasatkin@samsung.com&gt;
Signed-off-by: Mimi Zohar &lt;zohar@linux.vnet.ibm.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>crypto: crypto_memneq - add equality testing of memory regions w/o timing leaks</title>
<updated>2013-10-07T06:17:06+00:00</updated>
<author>
<name>James Yonan</name>
<email>james@openvpn.net</email>
</author>
<published>2013-09-26T08:20:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=6bf37e5aa90f18baf5acf4874bca505dd667c37f'/>
<id>6bf37e5aa90f18baf5acf4874bca505dd667c37f</id>
<content type='text'>
When comparing MAC hashes, AEAD authentication tags, or other hash
values in the context of authentication or integrity checking, it
is important not to leak timing information to a potential attacker,
i.e. when communication happens over a network.

Bytewise memory comparisons (such as memcmp) are usually optimized so
that they return a nonzero value as soon as a mismatch is found. E.g,
on x86_64/i5 for 512 bytes this can be ~50 cyc for a full mismatch
and up to ~850 cyc for a full match (cold). This early-return behavior
can leak timing information as a side channel, allowing an attacker to
iteratively guess the correct result.

This patch adds a new method crypto_memneq ("memory not equal to each
other") to the crypto API that compares memory areas of the same length
in roughly "constant time" (cache misses could change the timing, but
since they don't reveal information about the content of the strings
being compared, they are effectively benign). Iow, best and worst case
behaviour take the same amount of time to complete (in contrast to
memcmp).

Note that crypto_memneq (unlike memcmp) can only be used to test for
equality or inequality, NOT for lexicographical order. This, however,
is not an issue for its use-cases within the crypto API.

We tried to locate all of the places in the crypto API where memcmp was
being used for authentication or integrity checking, and convert them
over to crypto_memneq.

crypto_memneq is declared noinline, placed in its own source file,
and compiled with optimizations that might increase code size disabled
("Os") because a smart compiler (or LTO) might notice that the return
value is always compared against zero/nonzero, and might then
reintroduce the same early-return optimization that we are trying to
avoid.

Using #pragma or __attribute__ optimization annotations of the code
for disabling optimization was avoided as it seems to be considered
broken or unmaintained for long time in GCC [1]. Therefore, we work
around that by specifying the compile flag for memneq.o directly in
the Makefile. We found that this seems to be most appropriate.

As we use ("Os"), this patch also provides a loop-free "fast-path" for
frequently used 16 byte digests. Similarly to kernel library string
functions, leave an option for future even further optimized architecture
specific assembler implementations.

This was a joint work of James Yonan and Daniel Borkmann. Also thanks
for feedback from Florian Weimer on this and earlier proposals [2].

  [1] http://gcc.gnu.org/ml/gcc/2012-07/msg00211.html
  [2] https://lkml.org/lkml/2013/2/10/131

Signed-off-by: James Yonan &lt;james@openvpn.net&gt;
Signed-off-by: Daniel Borkmann &lt;dborkman@redhat.com&gt;
Cc: Florian Weimer &lt;fw@deneb.enyo.de&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
When comparing MAC hashes, AEAD authentication tags, or other hash
values in the context of authentication or integrity checking, it
is important not to leak timing information to a potential attacker,
i.e. when communication happens over a network.

Bytewise memory comparisons (such as memcmp) are usually optimized so
that they return a nonzero value as soon as a mismatch is found. E.g,
on x86_64/i5 for 512 bytes this can be ~50 cyc for a full mismatch
and up to ~850 cyc for a full match (cold). This early-return behavior
can leak timing information as a side channel, allowing an attacker to
iteratively guess the correct result.

This patch adds a new method crypto_memneq ("memory not equal to each
other") to the crypto API that compares memory areas of the same length
in roughly "constant time" (cache misses could change the timing, but
since they don't reveal information about the content of the strings
being compared, they are effectively benign). Iow, best and worst case
behaviour take the same amount of time to complete (in contrast to
memcmp).

Note that crypto_memneq (unlike memcmp) can only be used to test for
equality or inequality, NOT for lexicographical order. This, however,
is not an issue for its use-cases within the crypto API.

We tried to locate all of the places in the crypto API where memcmp was
being used for authentication or integrity checking, and convert them
over to crypto_memneq.

crypto_memneq is declared noinline, placed in its own source file,
and compiled with optimizations that might increase code size disabled
("Os") because a smart compiler (or LTO) might notice that the return
value is always compared against zero/nonzero, and might then
reintroduce the same early-return optimization that we are trying to
avoid.

Using #pragma or __attribute__ optimization annotations of the code
for disabling optimization was avoided as it seems to be considered
broken or unmaintained for long time in GCC [1]. Therefore, we work
around that by specifying the compile flag for memneq.o directly in
the Makefile. We found that this seems to be most appropriate.

As we use ("Os"), this patch also provides a loop-free "fast-path" for
frequently used 16 byte digests. Similarly to kernel library string
functions, leave an option for future even further optimized architecture
specific assembler implementations.

This was a joint work of James Yonan and Daniel Borkmann. Also thanks
for feedback from Florian Weimer on this and earlier proposals [2].

  [1] http://gcc.gnu.org/ml/gcc/2012-07/msg00211.html
  [2] https://lkml.org/lkml/2013/2/10/131

Signed-off-by: James Yonan &lt;james@openvpn.net&gt;
Signed-off-by: Daniel Borkmann &lt;dborkman@redhat.com&gt;
Cc: Florian Weimer &lt;fw@deneb.enyo.de&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>X.509: add module description and license</title>
<updated>2013-09-25T16:17:01+00:00</updated>
<author>
<name>Konstantin Khlebnikov</name>
<email>khlebnikov@openvz.org</email>
</author>
<published>2013-09-17T11:14:55+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=e19aaa7d43bed3bf6740a2931878beef5da9d7d9'/>
<id>e19aaa7d43bed3bf6740a2931878beef5da9d7d9</id>
<content type='text'>
This patch fixes lack of license, otherwise x509_key_parser.ko taints kernel.

Signed-off-by: Konstantin Khlebnikov &lt;khlebnikov@openvz.org&gt;
Signed-off-by: David Howells &lt;dhowells@redhat.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This patch fixes lack of license, otherwise x509_key_parser.ko taints kernel.

Signed-off-by: Konstantin Khlebnikov &lt;khlebnikov@openvz.org&gt;
Signed-off-by: David Howells &lt;dhowells@redhat.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>KEYS: verify a certificate is signed by a 'trusted' key</title>
<updated>2013-09-25T16:17:01+00:00</updated>
<author>
<name>Mimi Zohar</name>
<email>zohar@linux.vnet.ibm.com</email>
</author>
<published>2013-08-20T18:36:27+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=09fbc47373826d67531380662b516de2da120545'/>
<id>09fbc47373826d67531380662b516de2da120545</id>
<content type='text'>
Only public keys, with certificates signed by an existing
'trusted' key on the system trusted keyring, should be added
to a trusted keyring.  This patch adds support for verifying
a certificate's signature.

This is derived from David Howells pkcs7_request_asymmetric_key() patch.

Signed-off-by: Mimi Zohar &lt;zohar@linux.vnet.ibm.com&gt;
Signed-off-by: David Howells &lt;dhowells@redhat.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Only public keys, with certificates signed by an existing
'trusted' key on the system trusted keyring, should be added
to a trusted keyring.  This patch adds support for verifying
a certificate's signature.

This is derived from David Howells pkcs7_request_asymmetric_key() patch.

Signed-off-by: Mimi Zohar &lt;zohar@linux.vnet.ibm.com&gt;
Signed-off-by: David Howells &lt;dhowells@redhat.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>KEYS: Set the asymmetric-key type default search method</title>
<updated>2013-09-25T16:17:01+00:00</updated>
<author>
<name>David Howells</name>
<email>dhowells@redhat.com</email>
</author>
<published>2013-09-04T18:28:03+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=cd0421dcd0230d3e402ae9c6d012610132c3f078'/>
<id>cd0421dcd0230d3e402ae9c6d012610132c3f078</id>
<content type='text'>
The keyring expansion patches introduces a new search method by which
key_search() attempts to walk directly to the key that has exactly the same
description as the requested one.

However, this causes inexact matching of asymmetric keys to fail.  The
solution to this is to select iterative rather than direct search as the
default search type for asymmetric keys.

As an example, the kernel might have a key like this:

	Magrathea: Glacier signing key: 6a2a0f82bad7e396665f465e4e3e1f9bd24b1226

and:

	keyctl search &lt;keyring-ID&gt; asymmetric id:d24b1226

should find the key, despite that not being its exact description.

Signed-off-by: David Howells &lt;dhowells@redhat.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The keyring expansion patches introduces a new search method by which
key_search() attempts to walk directly to the key that has exactly the same
description as the requested one.

However, this causes inexact matching of asymmetric keys to fail.  The
solution to this is to select iterative rather than direct search as the
default search type for asymmetric keys.

As an example, the kernel might have a key like this:

	Magrathea: Glacier signing key: 6a2a0f82bad7e396665f465e4e3e1f9bd24b1226

and:

	keyctl search &lt;keyring-ID&gt; asymmetric id:d24b1226

should find the key, despite that not being its exact description.

Signed-off-by: David Howells &lt;dhowells@redhat.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>X.509: Remove certificate date checks</title>
<updated>2013-09-25T16:17:01+00:00</updated>
<author>
<name>David Howells</name>
<email>dhowells@redhat.com</email>
</author>
<published>2013-06-18T16:40:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=124df926090b32a998483f6e43ebeccdbe5b5302'/>
<id>124df926090b32a998483f6e43ebeccdbe5b5302</id>
<content type='text'>
Remove the certificate date checks that are performed when a certificate is
parsed.  There are two checks: a valid from and a valid to.  The first check is
causing a lot of problems with system clocks that don't keep good time and the
second places an implicit expiry date upon the kernel when used for module
signing, so do we really need them?

Signed-off-by: David Howells &lt;dhowells@redhat.com&gt;
cc: David Woodhouse &lt;dwmw2@infradead.org&gt;
cc: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
cc: Josh Boyer &lt;jwboyer@redhat.com&gt;
cc: Alexander Holler &lt;holler@ahsoftware.de&gt;
cc: stable@vger.kernel.org
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Remove the certificate date checks that are performed when a certificate is
parsed.  There are two checks: a valid from and a valid to.  The first check is
causing a lot of problems with system clocks that don't keep good time and the
second places an implicit expiry date upon the kernel when used for module
signing, so do we really need them?

Signed-off-by: David Howells &lt;dhowells@redhat.com&gt;
cc: David Woodhouse &lt;dwmw2@infradead.org&gt;
cc: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
cc: Josh Boyer &lt;jwboyer@redhat.com&gt;
cc: Alexander Holler &lt;holler@ahsoftware.de&gt;
cc: stable@vger.kernel.org
</pre>
</div>
</content>
</entry>
</feed>
