>From a slightly weirder angle, as network engineers we are trained to build for universal reachability first, then layer on policy in an attempt to limit and control reachability. It's bizarre, self-defeating behavior. Everything is a product though in IT, even though a router is not an iPad, it goes through the same product management lifecycle with the same considerations. The effect here is that everything has a lot of knobs and functionality and it's own interfaces (CLI, APIs, etc), packaging, and even IT subcultures around it.
It's the antithesis of actual engineering. Data flow specs are long gone because there is an assumption that reachability will exist. People install products with no idea what traffic is actually flowing in and out of the "box" (be that hardware or software). It's like we reached the state of Idiocracy in IT... Anyway, that's what this quote from this book reminded me of. On Mon, Apr 28, 2014 at 8:24 AM, Meredith L. Patterson <clonea...@gmail.com>wrote: > On Mon, Apr 28, 2014 at 12:15 PM, Nils Dagsson Moskopp < > n...@dieweltistgarnichtso.net> wrote: > >> A solution might avoid protocol complexity by only implementing parts >> below a specific complexity. Fefe recently wrote that he would only >> accept DER encoded data (unambiguous length encoding) even if the >> standard mentions BER encoded data: <https://blog.fefe.de/?ts=ada94b9c> >> > > It's really good to see this being addressed in a larger venue; I've been > arguing that HTTPS Everywhere is useless without DER Everywhere for a while > now. > > >> Do you consider accepting only a safe subset of a language a proper >> course of action? >> > > That was pretty much the exact point of Dejector, which defined a "safe > subset" of SQL as "the subset of rules necessary to generate the queries > the developer expects the application to generate under correct operation." > > Cheers, > --mlp > > _______________________________________________ > langsec-discuss mailing list > langsec-discuss@mail.langsec.org > https://mail.langsec.org/cgi-bin/mailman/listinfo/langsec-discuss > >
_______________________________________________ langsec-discuss mailing list langsec-discuss@mail.langsec.org https://mail.langsec.org/cgi-bin/mailman/listinfo/langsec-discuss