On Thu, Apr 28, 2016 at 8:39 AM, Jeff King <peff@xxxxxxxx> wrote: > On Thu, Apr 28, 2016 at 08:37:10AM -0700, Jacob Keller wrote: > >> I think I prefer a blacklist approach, since it reduces the need for >> future changes, since most cases will either not put config on the >> environment or (based on feedback on the mailing list and bug reports) >> the user will believe it should be applied. >> >> A black list which only removed configurations we know are harmful >> would be easier to maintain but risks new additions forgetting to do >> so. A whitelist means we only fix things as they come up but also >> means we aren't "breaking" anything that works today, where as a >> blacklist could break something that works today. > > I think the key thing with a blacklist is somebody has to go to the work > to audit the existing keys. Would it be sufficient to wait until someone screams at the mailing list for some key to be blacklisted? (I mean in the short term that would be of less quality, but relying on the larger community would result in a better end result? So your going through is just a jump start this process of listening to the community?) Thanks, Stefan > > -Peff > -- > To unsubscribe from this list: send the line "unsubscribe git" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html