Re: [PATCH] X.509: Remove certificate date checks
Am 14.03.2013 18:09, schrieb David Woodhouse: On Thu, 2013-03-14 at 17:22 +0100, Alexander Holler wrote: 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. Is there *is* such a user, it's broken already. The key could have been loaded (and passed the existing check) *months* ago, expired seconds after it was loaded, and your hypothetical user could still be happily trusting it. As the user (program or whatever) calls the parser, he knows if he can trust it to validate dates. So there might be something for which the current implementation works (parsing date = using date). I just don't know, because I've only discovered that glitch while trying to use modsign to be sure no unsigned module (I've compiled myself) will be become loaded (I compile the kernel and delete the keys right afterwards). So I don't know anything if and how the crypto-api to load x.509 keys is used besides modsign. ;) Regards, Alexander -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] X.509: Remove certificate date checks
On Thu, 2013-03-14 at 17:22 +0100, Alexander Holler wrote: > > 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. Is there *is* such a user, it's broken already. The key could have been loaded (and passed the existing check) *months* ago, expired seconds after it was loaded, and your hypothetical user could still be happily trusting it. > Offering the parsed dates for later usage is still a good idea. Right. -- dwmw2 smime.p7s Description: S/MIME cryptographic signature
Re: [PATCH] X.509: Remove certificate date checks
Am 14.03.2013 13:48, schrieb David Woodhouse: On Thu, 2013-03-14 at 12:34 +, 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] X.509: Remove certificate date checks
On Thu, 2013-03-14 at 12:34 +, 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... :) -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation smime.p7s Description: S/MIME cryptographic signature
