Kung-Fu Nemerle или безопасNый код
От: kochetkov.vladimir Россия https://kochetkov.github.io
Дата: 21.06.11 23:26
Оценка: 54 (7)
http://vkochetkov.blogspot.com/2011/06/nemerle.html


[Интервью] .NET Security — это просто
Автор: kochetkov.vladimir
Дата: 07.11.17
Re: Kung-Fu Nemerle или безопасNый код
От: shakirov.ruslan  
Дата: 22.06.11 15:14
Оценка:
Очень субъективная статья.

Наличие unsafe в c# можно преподнести как фича для экспертов (чем и является), а различного рода иньекции являются не следствием используемого языка, а необученности или безответственности программиста.

Логичнее было бы сравнивать с таким же безопасным кодом на c# и сделать вывод о том, что Nemerle, благодаря макросам, позволяет писать безопасный код гораздо лаконичнее и читабельнее.
Re[2]: Kung-Fu Nemerle или безопасNый код
От: _nn_ www.nemerleweb.com
Дата: 22.06.11 15:22
Оценка:
Здравствуйте, shakirov.ruslan, Вы писали:

SR>Очень субъективная статья.


SR>Наличие unsafe в c# можно преподнести как фича для экспертов (чем и является), а различного рода иньекции являются не следствием используемого языка, а необученности или безответственности программиста.


SR>Логичнее было бы сравнивать с таким же безопасным кодом на c# и сделать вывод о том, что Nemerle, благодаря макросам, позволяет писать безопасный код гораздо лаконичнее и читабельнее.


Тут не только макросы.

Иммутабельность по умолчанию также способствует уменьшению ошибок.
А поддержка туплов уменьшает количество методов с ref/out и снова избавляемся от мутабельных переменных.
http://rsdn.nemerleweb.com
http://nemerleweb.com
Re[2]: Kung-Fu Nemerle или безопасNый код
От: kochetkov.vladimir Россия https://kochetkov.github.io
Дата: 22.06.11 15:56
Оценка:
Здравствуйте, shakirov.ruslan, Вы писали:

SR>Очень субъективная статья.


SR>Наличие unsafe в c# можно преподнести как фича для экспертов (чем и является)


А можно, как фичу, позволяющую внести в свой продукт уязвимости, нехарактерные для управляемых сред (чем она точно также является) Вопрос только в том, пессимист или оптимист будет ее преподносить.

SR>, а различного рода иньекции являются не следствием используемого языка, а необученности или безответственности программиста.


Нет. Они являются следствием И используемого языка И действий разработчика (но не его квалификации). Именно поэтому, кто-либо здесь, вряд ли сможет продемонстрировать к примеру Lisp-код, приводящий к переполнению буфера. Используемый язык является техническим фактором, которым мы можем управлять почти с математической точностью. Действия разработчика (а чаще, команды разработчиков), являются человеческим фактором и управлению поддаются крайне тяжело. Ошибку переполнения вполне может допустить и квалифицированный программист по той простой причине, что он человек, которому свойственно иногда быть невнимательным, невыспавшимся, спешащим, не умеющим объять необъятное и т.п.

SR>Логичнее было бы сравнивать с таким же безопасным кодом на c#


Во всех остальных разделах именно такое сравнение и приводится. Пример же с unsafe демонстрирует, что принимая на поддержку или security-ревью проект на C#, вы не можете быть уверены в том, что там отсутствует довольно широкий класс уязвимостей. Вы должны будете убедиться в этом, что несколько расширяет рамки поддержки и увеличивает план проведения ревью. В случае с Nemerle кодом, это не так, если в проекте нет компонентов, реализованных на неуправлямых языках, взаимодействие с которыми Nemerle-кода осуществляется через механизмы интеропа.

SR>и сделать вывод о том, что Nemerle, благодаря макросам, позволяет писать безопасный код гораздо лаконичнее и читабельнее.


Вообще-то, именно этому выводу и посвящена вся заметка, если что

[Интервью] .NET Security — это просто
Автор: kochetkov.vladimir
Дата: 07.11.17
Re[3]: Kung-Fu Nemerle или безопасNый код
От: hardcase Пират http://nemerle.org
Дата: 06.07.11 07:11
Оценка:
Здравствуйте, kochetkov.vladimir, Вы писали:

KV>кто-либо здесь, вряд ли сможет продемонстрировать к примеру Lisp-код, приводящий к переполнению буфера.


На самом деле эта вероятность значительно больше нуля: есть у меня на примете LISP-система с JIT-ом, позволяющая жестко интеропить с COM и WinApi.
/* иЗвиНите зА неРовнЫй поЧерК */
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.