> Well, sure we need that - but what is the surrounding concept
That cert validity can overlap in time, that certs may not
be rolled out globally instantly, and many may be issued
to server clusters, behind service engines, etc.
> what do we need to document
Fetchmail only.
> what needs to be reported to the user
The fingerprint matched, or failure because of no match.
The rest is in debug or the rc.
> how and where do we direct support inquiries?
FAQ, email 'forum', open wiki.
> How do we present issues to the user?
What issues. Users have issues.
> Do we want to do some pinning or certificate/issuer logging?
Pinning fingerprints, yes.
Logging beyond fingerprint, no, there are tools for examining certs.
And without pinning any other cert params should be viewed suspect anyways.
> What kind of hashes do we support? MD5 alone doesn't cut the mustard
> these days any more.
Legacy is md5 sha1, current is sha256, use whatever the cert world uses
so you can talk the same thing. I formerly thought to add sha2 / sha3,
that was before the cert world decided to move off broken md5 / sha1.
> What kind of other libraries to we port fetchmail onto, to alleviate
> both certificate management, as well as licensing? The GPL exemption
https://en.wikipedia.org/wiki/Comparison_of_TLS_implementations
There have also been at least one, maybe two, recent new
libraries besides LibreSSL. Ask on metzdowd for them.
> (user support)
Offload it, give them a fetchmail wiki. torproject even has success
with generic user:pass posted on wiki front page. Fill it with
starter links to learn. Post man2html pages.
https://en.wikipedia.org/wiki/Transport_Layer_Security
> I certainly don't want users asking the list with issues their ISPs
If those kind of users are expected, punt them to their favorite
form of support, chatter and bloat... a "forum", simplemachines is
fine. Never post or read it and move yourself to a -dev list :)
> I am open to and soliciting input on the "concept" parts. It should not
> amount to novel-like text quantities, but a few well-thought bullet
> points on concept, threat scenario, user interface, "what kind of
> documentation do we need", steering support load, would surely help.
> I am also inviting users to review the legacy_64 and master ("7.0.0
> alpha") branches in Git and have a loot at their SSL/TLS/crypto
> approach. Not radically different, but noticable
I previously commented / ticketed at least at some length on
- support for TLS stuff and usage
- refactoring the fetchmail rc file
I likely owe a revisit on followup I missed.
If you expect to get a 7.x out, I'd abandon 6.x except for critical fixes.
> and to clean up some
> of the burdens of the past, when someone thought "STARTTLS means TLS
> v1.0 and SSL-wrapped means SSLv2 or v3"...
Wiki links to good definitions and examples.
Github offers wiki page, though not a end-user level thing.
|
