On 5/3/2017 4:22 PM, Dirk-Willem van Gulik wrote: > >> 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? > > Dw. >
Agreed, it is a whole new land. However, if we truly want a simple "turnkey" method for MR and Mrs Normal, I don't see any other way that will have fast-enough turnaround when vulnerabilities are discovered. There's precedent for this sort of update mechanism inside the ASF with SpamAssassin. However, IMHO it doesn't make sense to reach out to them to hear their thoughts of how sa-upadate deals with that land or otherwise overthink this until we have some internal consensus that this is an avenue that we would hypothetically be ok supporting. If it's not turn-key, I don't see Mr and Mrs normal using it, and then we could solve this for the rest of our users with a docs update. The macros ideas are nifty, but I can't think of any use case where, for example, a sysadmin (most definately NOT mr or mrs normal) would want to configure multiple sets of macros on a single instance.
