> On 3 May 2017, at 15:14, Issac Goldstand <mar...@beamartyr.net> wrote:
> On 5/3/2017 3:59 PM, Dirk-Willem van Gulik wrote:
>>> On 3 May 2017, at 14:53, Issac Goldstand <mar...@beamartyr.net
>>> <mailto:mar...@beamartyr.net>> wrote:
>>> On 5/3/2017 12:46 PM, Dirk-Willem van Gulik wrote:
>>>> On 3 May 2017, at 10:03, Issac Goldstand <mar...@beamartyr.net
>>>> <mailto:mar...@beamartyr.net>> wrote:
>>>>> +1 on the idea
>>>>> So far I'm -0 about all of the proposed implementations for 2 reasons:
>>>>> 1) Mr and Mrs normal (whom are our primary customers in the original
>>>>> proposal) usually download Apache from their distro or some other
>>>>> binary.  Their Apache sources are usually not up-to-date, and in the
>>>>> scenario that a new vulnerability is found it would take ages to
>>>>> propagate to them, anyway
>>>>> 2) For those users who are comfortable building their own source, they
>>>> ….
>>>> So how about ‘us’ taking the lead here. 
>>> That's the part I was always +1 on :)
>>>> We, here, simply define ‘one’ setting as the industry best standard -
>>>> which roughly corresponds to what ssllabs their test would get you an
>>>> A+ and that pretty much meets or exceeds the various NIST et.al.
>>>> recommendations for key lengths for the next 5 years. 
>>> The problem is, that we don't know what's going to be good going forward
>>> five years, and IMHO the best standards are shaped at least equally by
>>> removing "negatives" often because of high-risk vulnerabilities, as by
>>> adding new "positives" due to new available ciphers/tools
>> Right - so I think there are two things
>> 1)the general advice of NIST et.al. - summarized nicely at:
>> https://www.keylength.com
>> which tells us what our `best acceptable’ choises are in any release
>> going out and their likely vailidy for the next 5 years.
>> And then there is our response to things that become known; such as
>> vulnerability - for which we have a proven update proces that is
>> dovetailed by us sending mail to announce, the security mailing lists
>> and similar outreach.
> Which, IMHO, we can safely expect Mr and Mrs Normal to never see.  Mr
> and Mrs normal aren't on the mailing list of most pieces of software,
> even if they use them.
> If we truly want to cater to them (and by doing so, do our part in
> advocating a safer and more secure internet) then I maintain that we'd
> need to do better.

Right - but then we are in the land of automatic updates; binary package 
fetching and what not ? Or at the very least - pulling down a file over the 
internet from ‘us’ that is sufficiently protected yet robust, etc ?

That is a whole new land?


Reply via email to