Hide Forgot
Description of problem: Version-Release number of selected component (if applicable): httpd-2.2.17-10 How reproducible: Always Steps to Reproduce: 1. grep x509 httpd.spec Actual results: 1. -x509 -days 365 -set_serial $RANDOM -extensions v3_req Expected results: 1. -x509 -days 36500 -set_serial $RANDOM -extensions v3_req Additional info: Why make the certificate expiry so short? The certwatch utility conveniently ignores any certificate with a CN of localhost.localdomain (amazing that a completely independent rpm has inner knowledge of httpd's certificate generation process, and even more amazing that it colludes to ignore it) so when the certificate does expire after 1 year nobody except httpd clients will get to see it. The owner of the certificate might be the last to know. Why not just give the certificate an expiry of 100 years?
1) Tone down the rhetoric, please. 2) Anybody relying on the expiry time of this cert rather than getting a real cert for a public site is screwed anyway. The expiry time is arbitrary, and I'm not going to get into a bikeshed painting exercise about this.
Who said anything about a public site? I certainly didn't. Besides, that has absolutely nothing to do with the price of fish (or bikeshed painting whatever that is). The question is: why create a self-signed certificate with a limit life? What is the point of doing that? And since creating a certificate that lasts for 100 years has zero cost, why not do that? Tone down your illogicality please!
c.f. http://lightblue.bikeshed.com/ The only point of creating a cert here is so that we can ship a working mod_ssl configuration. That is the only point. Anybody relying on the test cert for any other use is screwed. Please don't abuse bugzilla by re-opening bugs if you disagree with the maintainer's decision.
For goodness sake. You are so damned lazy you wont even consider changing 365 to 36500. What is your problem?
> Please don't abuse bugzilla by re-opening bugs if > you disagree with the maintainer's decision. Ok then, what procedure should one follow if one disagrees with the maintainer? Because quite clearly the maintainer is 100% wrong on this matter.
> Ok then, what procedure should one follow if one disagrees with the maintainer? http://fedoraproject.org/wiki/Fedora_Engineering_Steering_Committee Please do not re-open this bug again.