Bug 61472 - imap certs Just Don't Know Their Place !
imap certs Just Don't Know Their Place !
Status: CLOSED NOTABUG
Product: Red Hat Linux
Classification: Retired
Component: imap (Show other bugs)
6.2
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Mike A. Harris
David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-03-20 01:58 EST by Bishop Clark
Modified: 2007-04-18 12:41 EDT (History)
1 user (show)

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


Attachments (Terms of Use)

  None (edit)
Description Bishop Clark 2002-03-20 01:58:15 EST
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 02:10:56 EST
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 12:42:03 EDT
LOL
Comment 3 Mike A. Harris 2002-05-21 12:47:23 EDT
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 13:49:55 EDT
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 17:38:59 EDT
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.