>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

Reply via email to