Hi,
>>> * ssl_only really does two separate things:
>>
>>> 1. It forces SSL for *fetching* configs.
>>> 2. It forces SSL or STARTTLS in the *resulting* configuration when
>>> *guessing* the config.
>>
>>> Is this confusing?
>>
>> Anything else would look strongly inconsistent to me, at least in the
>> threat model I think we're considering. So I don't find it confusing.
>>
>> OTOH, I don't understand what exactly "*resulting*" means above, so
>> I may very well be entirely confused wrt. how ssl_only behaves in
>> GuessConfig city.
> With resulting I just meant the fetched config after it has been parsed.
Ok. And what do you mean by "it forces ... in the resulting", then?
Refusing to save and/or use non-SSL parts? Forcibly turn SSL on
(StartTLS? SSL?), regardless of the fetched configuration?
>> OTOH, I would find it great if we could make it clear to them what
>> risk they are taking. How hard would it be to implement this? (This
>> would be a low-priority enhancement: I don't think our current
>> Claws Mail setup has anything to say against SSL.)
> Turned out to be easier than I initially thought (thanks, exceptions!).
:)
>> In any case, the current situation makes the "Only use secure
>> protocols" checkbox a wrong statement, isn't it?
> You're right. Implemented (PATCH 6/6).
Ok.
> Since we have no icedove repo to push to
Oops, sorry, I mentionned we should get one the other day, but I did
not actually ask for it. Going to do this soon.
> I post my current work here
A Git bundle would be more useful in case anyone wants to seriously
have a look / improve / suggest.
$ git help bundle
Cheers!
--
intrigeri
| GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
| OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc
| We're dreaming of something else.
| Something more clandestine, something happier.
