From: Matthias A. <mat...@gm...> - 2015-12-16 18:06:16
|
Am 16.12.2015 um 09:21 schrieb grarpamp: > I've mentioned this before in a pile of crypto support > stuff for fetchmail 7. Here's an example of a popular, > likely geolocated / multihomed / proxied / etc, service where > pinning one cert isn't enough in particular if the user is > using global VPN-like services. Well, sure we need that - but what is the surrounding concept, what do we need to document, what needs to be reported to the user, and how and where do we direct support inquiries? How do we present issues to the user? Do we want to do some pinning or certificate/issuer logging? What kind of hashes do we support? MD5 alone doesn't cut the mustard these days any more. What kind of other libraries to we port fetchmail onto, to alleviate both certificate management, as well as licensing? The GPL exemption clauses for OpenSSL's advertising clauses are cumbersome to some. As end user you won't care, a distributor or someone who plans to embed fetchmail into other applications, however, will. I certainly don't want users asking the list with issues their ISPs cause with underdocumentation, negligence, or otherwise, and that's not laziness, but about putting the support efforts where they belong (and probably also response times). Just slapping features onto fetchmail is the easy part, casting everything into a sound concept, however, is the work that needs to be done before. 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, 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"... |