[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Pan-devel] at b2069b3 now -- I think I figured-out one little thing

From: Heinrich Mueller
Subject: Re: [Pan-devel] at b2069b3 now -- I think I figured-out one little thing (Re: ANN: SSL Support))
Date: Sat, 12 Nov 2011 11:48:53 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111108 Thunderbird/8.0

Am 11.11.2011 23:35, schrieb SciFi:

Another thing…

On Fri, 11 Nov 2011 22:17:03 +0000, SciFi wrote:

(I thought I would check the list while fixing supper
  and before laying down)

On Fri, 11 Nov 2011 22:32:57 +0100, Heinrich Mueller wrote:
Am 11.11.2011 21:03, schrieb SciFi:
It might be that the pem file needs to match
the "officially registered" names for the certs.
And for Pan keep track of that gook, somehow.   ;)


Does this make any sort of sense at all?
(honestly asking)

Yes, my code as of yet reads the pem files and
matches them with the filename. Perhaps I'll just a map-based
approach with a file telling which certificate belongs to
which server and i just name them after the md5 checksum or
That was just the simplest thing for me, because normally the
user doesn't rename his certificates as pan stores them automatically.
I think I'll implement an option in the servers.xml file.

I guess the thing to remember is something like this:
Us mere mortals wouldn't normally need to worry about
matching these things together properly.  We would
expect things to "just work" by the code doing
whatever "magic" is required.   ;)

For us geeks trying to iron-out this present anomaly,
I still cannot find what the "proper name" should be
for the gn and gmane certs/pems.

However, I suppose discovering the aw name was
more of an "accident" it seems to work that way.  ;)

I then suppose the OpenSSL APIs will have something
to offer for the app to keep-track of these certs?
(Other software, that support SSL, seem to handle
  all this tracking automatically.  The app only
  needs to know whether to use SSL-mode or not.)

Thanks again.
Another thought:
I believe most apps that support SSL
will keep the cert(s)&  details in RAM
for the duration of the session(s).
The app won't record anything SSL-related to disk
nor will the app "ask" to "accept" the cert.
That means there will be "handshaking"
once a session is (re)started
every time
yes every time.
This might also necessarily change the
encryption keys etc. for each session/thread
but I would think it'd be "safer" this way.

(sometimes a bit of good food
  helps my noggin do some thinkin'<g>)

(but what do I really know about this stuff)

(I will probably go lay down now)

Pan-devel mailing list
You're partly right: SSL stores the encryption keys/certificates etc.
in RAM, but at initialization it gets its certificates _also_ by parsing
files on the disk. SSL trusts those and never "untrusts" them, so
to speak, as long as the SSL context or certificate store exists.
That means I only have to init the certificates once at startup, and
what seemed most feasible not to annoy the user was to do this
with a disk-based approach. I also chmod the files so only the user using
pan can actually read them.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]