From: Alexander Holler <holler@ahsoftware.de>
To: David Woodhouse <dwmw2@infradead.org>
Cc: David Howells <dhowells@redhat.com>,
rusty@rustcorp.com.au, torvalds@linux-foundation.org,
keyrings@linux-nfs.org, Josh Boyer <jwboyer@redhat.com>,
linux-kernel@vger.kernel.org, stable@vger.kernel.org
Subject: Re: [PATCH] X.509: Remove certificate date checks
Date: Thu, 14 Mar 2013 17:22:42 +0100 [thread overview]
Message-ID: <5141F952.8000204@ahsoftware.de> (raw)
In-Reply-To: <1363265300.4853.37.camel@i7.infradead.org>
Am 14.03.2013 13:48, schrieb David Woodhouse:
> On Thu, 2013-03-14 at 12:34 +0000, David Howells wrote:
>> 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?
>
> While the date check is entirely bogus for the specific case of module
> signing, I don't think we necessarily ought to rip it out of our generic
> X.509 support entirely.
>
> Some use cases *might* want to check the dates, and should be permitted
> to do so. Just don't refuse to even *parse* the key outside its valid
> date range... :)
Agreed (thats what my patch did).
I've introduced a new config option because I don't know if something (a
use case I don't know) relies on the validity check of the dates in the
parser. If there currently isn't such a user, just removing the validity
check in the parser might be enough. Offering the parsed dates for later
usage is still a good idea.
Regards,
Alexander
next prev parent reply other threads:[~2013-03-14 16:33 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-14 12:34 [PATCH] X.509: Remove certificate date checks David Howells
2013-03-14 12:48 ` David Woodhouse
2013-03-14 16:22 ` Alexander Holler [this message]
2013-03-14 17:09 ` David Woodhouse
2013-03-14 17:42 ` Alexander Holler
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5141F952.8000204@ahsoftware.de \
--to=holler@ahsoftware.de \
--cc=dhowells@redhat.com \
--cc=dwmw2@infradead.org \
--cc=jwboyer@redhat.com \
--cc=keyrings@linux-nfs.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rusty@rustcorp.com.au \
--cc=stable@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.