Bug 61472 - imap certs Just Don't Know Their Place !
Summary: imap certs Just Don't Know Their Place !
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: imap (Show other bugs)
(Show other bugs)
Version: 6.2
Hardware: i386 Linux
medium
medium
Target Milestone: ---
Assignee: Mike A. Harris
QA Contact: David Lawrence
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2002-03-20 06:58 UTC by Bishop Clark
Modified: 2007-04-18 16:41 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2002-05-21 17:50:01 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

Description Bishop Clark 2002-03-20 06:58:15 UTC
Description of Problem:
imap-2000c-1.6.1 is trying to place (zero-length. huh?) certs in
/usr/share/ssl/certs/ , whereas the 'normal' place is /etc/ssl/certs .  I'm only
assuming that it's IMAP that's at fault;  otherwise, I'll open an openssl RFE.

Version-Release number of selected component (if applicable):
imap-2000c-1.6.1
openssl-0.9.6-1

How Reproducible:
oh, it's there all right.  it's not really a 'reproduce' thing, more of a
'voyeur' thing.  How kinky.

Steps to Reproduce:
1. rpm -ql imap | grep certs
2. rpm -ql openssl | grep certs
3. 

Actual Results:
certs are misplaced, homeless, and probably depressed with the notion that
they're nothing (0-length) and worthless.  Just place-holders in our society,
marking time until a REAL cert pushes it aside.  it's tragic, I tell you.

Expected Results:
certs know their place, they go there, and that's where they stay !

Additional Information:
Yes, please.  Tell me how to activate the imaps.  Just an inetd.conf edit?  Oh,
right, then, forget about it, sorry, didn't mean to bother.

Comment 1 Bishop Clark 2002-03-20 07:10:56 UTC
Hey Mike,

I just realized my openssl *is* rogue.  I'm so ashamed.  I'm off to rebuild
openssl under 0.9.5a-7.6 and see if the problem persists.  

Sorry to tease you like this.  I'm *so* gonna get written on the whiteboard now,
aren't I?

 - bish

Comment 2 Mike A. Harris 2002-05-21 16:42:03 UTC
LOL

Comment 3 Mike A. Harris 2002-05-21 16:47:23 UTC
After thinking about it, /usr/share/ssl/certs/ does seem like the
wrong place to put ssl certificates IMHO.  I'd think /etc/ssl would
be more sensible.  But that would be an openssl thing, not an imap
thing.  I'm not the resident ssl expert however, so....

Nalin, doesn't /etc/ssl/certs make more sense for ssl certs?  If not,
please brain-smack both of us.  ;o)

Comment 4 Bishop Clark 2002-05-21 17:49:55 UTC
Nah, Mike, while I think that /etc/ssl may be the better place, there's a whole
shi(p)load of packages in RH, all the way to RH73 (the deJeff Release) that
you'd have to go into and change.  MDK, I think, has theirs in /etc/ssl, and
it's the standard place if you build wu-imap from scratch, for example, but
consider the work involved in all that!  It's huge!  You'd be a crazy man!

There are way more important things - like getting Apache to be FHS compliant
(/var:  temporary and transient data) - than moving datadir/ssl into /etc , and
it's not that strong a case for /etc over %datadir in the dirst place;  sure,
actually move some config stuff into /etc, but I'm not sure if anything there
really is 'configure' type data;  it's all just ssl-specific data, of use and
used by many ssl-enabled apps, which seems to beg for %datadir/ssl as a location.

Imho.  

(Nalin - it was so hard to resist plugging apache PR6397 above.  -DI'll
-Dharrass -Dyou -Dlater)



Comment 5 Mike A. Harris 2002-05-22 21:38:59 UTC
Now that the imap/pop cert creation code has been well tested in current
versions of RHL, I have changed the spec file to default to creating pem
files during installation in RHL 6.2 builds also.  This change is only
in the spec file in rawhide, and so wont be seen probably until imap 2002
is released, and 6.2 erratum is warranted.

Closing bug as NOTABUG for now.


Note You need to log in before you can comment on or make changes to this bug.