« first day (1546 days earlier)      last day (1767 days later) » 

6:30 AM
@vp_arth недавно = в последние 7 дней.
 
7:04 AM
21
A: What changes have resulted from SE network sites becoming a source of income?

Tim PostThere's a lot of this I can't answer because I'd need to convey context surrounding departures from the company and that's, well, private. I also can't really speak about strategy when it comes to the business end of the company specifically enough to provide you a thorough answer to your questio...

 
 
4 hours later…
10:49 AM
@PavelMayorov И её сертифицировали с таким хаком? o_O
 
11:01 AM
@vp_arth А, ну разве что сбоку несертифицированный хак
 
11:39 AM
@VladD так ведь сертификация не чистоту архитектуры проверяет...
 
@PavelMayorov Ну, вопрос-то не в чистоте, решение не должно ж быть опасным? Если я вместо штатного вызова виртуальной функции буду через unsafe-код работать прямо с ТВМ, это ж не проблема дизайна, а хрупкая реализация.
 
12:04 PM
@VladD вот именно, она хрупкая, но не опасная. Чтобы оно стало уязвимостью - надо сначала найти такую комбинацию версий КриптоПРО и .NET Framework, на которой оно поломается, но не упадет; потом найти того кто эту комбинацию (нерабочую!) использует; и только потом можно будет начать искать вектора атаки (на нерабочий сервер!!!)
@VladD замечу, что подмена метода происходит ещё до JIT-компиляции (иначе она просто не сможет работать), а значит всякие банальности вроде лишнего параметра и разрушения стека работать не будут: JIT предупредит если сигнатура метода окажется некорректна.
 
@PavelMayorov Любая линукс-реализация?
 
@VladD а что не так с линукс-реализациями? Вот допустим поставил я .NET-библиотеку на линукс, добавил в GAC (ха-ха), что дальше?
 
@PavelMayorov Ну, бинарный стандарт же не такой под ним?
А, вы говорите, подмена на уровне IL-кода
 
Подмена на уровне служебных таблиц фреймворка. IL-код как раз неизменный.
 
Но сама подмена IL-кода осуществляется каким образом?
 
12:09 PM
IL-код не модифицируется.
 
Изменяется на диске библиотека из BCL?
 
Нет, изменяется указатель в памяти.
 
Ну вот. А определение того, где ж этот указатель лежит, делается на основе чего?
 
На основе знания этих структур.
На линуксе нет .NET Framework, а с ним и проблемы тоже нет. Библиотека от КриптоПРО просто не запустится.
 
На основе реверс-инжинеринга этих структур, потому что официальной гарантии их неизменности, как я понимаю, нету?
 
12:12 PM
@VladD ну да
 
Грязновато
Плюс если Майкрософт выпустит патч безопасности, меняющий бинарный layout, то его накатывать нельзя, т. к. хак КриптоПРО в лучшем случае просто отвалится
А почему нельзя было пойти официальным путём и спросить у Майкрософт, какой официальный метод? Для чего вообще понадобилось влазить в код, не предназначенный для расширения?
Потому что сама идея выглядит странно
 
А вы посмотрите на эту порнографию: referencesource.microsoft.com/#System.Security/system/security/…
По мне, так реализация от Microsoft выглядит еще более странно чем обход от КриптоПРО
И это не единственное подобное место
А заменять на свой класс нельзя - тогда придется писать свою реализацию WS-Security для WCF, то есть делать свой вариант каждого стандартного биндинга.
И тогда поломается уже встроенная в студию генерация корректного WCF-клиента для сервиса (придется ходить по конфигу и править каждый биндинг)
 
12:54 PM
@PavelMayorov А что там не так? switch? Они по крайней мере не делают низкоуровневых хаков. То есть я правильно понимаю, что Майкрософт поддерживает фиксированный набор криптографических алгоритмов, а КриптоПРО хочет этот набор расширить своим алгоритмом в обход официального канала?
 
@VladD да. Вот только вопрос: а какого фига набор алгоритмов - нерасширяемый?
Вы как будто не знаете как работают официальные каналы Microsoft. "Да-да, это очень важно, лет через пять мы исправим эту проблему, а пока крутитесь как знаете"
4
 
1:14 PM
@PavelMayorov аж глаз зачесался
 
@PavelMayorov так вот значит у кого SE пример берут (¬‿¬ )
@PavelMayorov Kreygasm
 
1:32 PM
@PavelMayorov Примерно по той же причине, по какой и большинство методов BCL невиртуальные: где гарантия, что расширение будет поддерживать нужные инварианты?
 
@VladD у вас там контрактов/интерфейсов нет?
 
@vp_arth Контракты есть. Интерфейсы есть. Но инварианты интерфейсом или контрактом не опишешь.
 
Вы про инварианты в плане дженериков?
 
@VladD какие такие особые инварианты нужны криптоалгоритму?
 
Не, ну пусть невиртуальный, но не switch, а мапа по registered_engines какому-нибудь, why not?
 
1:41 PM
И вообще, в таких случаях хорошо работает обратная логика: точка расширения есть, а как сделать чтобы оно заработало - задача автора расширения.
Вот серьезно, не представляю себе человека, который установит КриптоПРО, подключит ГОСТовый сертификат, напорется на ошибку, и обвинит в ней Microsoft
 
@PavelMayorov Не знаю. Я опасно некомпетентен в криптографии
@vp_arth А в чём отличие? Фактически — ни в чём.
 
@VladD отличие в том, что добавляя свой engine(за который несу ответственность) я не сломаю существующие.
 
@VladD приглядитесь внимательнее: там метод принимает любую реализацию одного из известных алгоритмов. Он никак не защищен от ошибок реализации алгоритма.
Все от чего он "защищен" - от передачи алгоритма не из белого списка.
Так какие инварианты могут быть нарушены при передаче ГОСТ-алгоритма, но не могут быть нарушены при передаче ошибочной реализации SHA1?
 
> Избавьте себя от проблем. Не используйте криптографию
Такой себе вывод)
 
@vp_arth Ну так так и можно сделать все методы виртуальными, ведь тот, кто перекрыл, несёт ответственность. Только по факту ответственность теперь несёт любая сторонняя библиотека.
 
1:49 PM
Невозможность подобного расширения, с другой стороны, диктует выбор используемого инструмента не в пользу .Net
Существует класс продуктов, в которых нельзя использовать что-то кроме CryptoPro(Ну или VipNet)
 
@VladD ну, в java они так и сделаны по умолчанию
@VladD но ситуации "все методы виртуальные" и "заменили switch на словарь" принципиально разные, не притворяйтесь что не видите в них разницы.
Фокус в том, что там уже есть точка расширения, но она закрыта "только для своих".
Кстати, можно и с другой стороны зайти: этот метод нарушает LSP.
 
@PavelMayorov Ну хорошо, почему бы тогда не назвать свой алгоритм разрешённым именем?
@PavelMayorov Да, и это мне кажется серьёзной ошибкой
Оно идёт вровень с этим:
7
A: Нужно ли виртуальные методы объявлять как protected?

Pavel MayorovС методом Dispose никаких проблем нет: его логика очень проста. Но обычно в базовом классе если какой-то более сложный алгоритм, точка расширения которого находится посередине а не с краю. Потому и нужен отдельный метод: interface IValidator { ValidationResult Validate(object obj); } clas...

@PavelMayorov Одно и то же по сути: разрешили небиблиотечному коду расширять функциональность библиотеки
@PavelMayorov Да, это понятно как раз. Потому что за свои расширения Майкрософт ответственна
@PavelMayorov Нарушает, да. Вот появятся ADT, они перепишут.
 
2:11 PM
@VladD потому что тогда в итоговый документ попадет неправильный идентификатор алгоритма, что противоречит задаче (получить валидный подписанный xml-докeмент)
@VladD в "этом" ответе, вообще-то, приведен корректный способ делать точки расширения
@VladD а это что, плохо?
@VladD но ведь туда можно передать чужое расширение. Ладно бы KeyedHashAlgorithm имел internal конструктор - тогда бы я понял зачем так сделано.
Но проблема в том, что у библиотеки System.Security предусмотрено расширение чужими криптопровайдерами (причем аж двух видов), и есть специальное API для этого! Которое работает всюду, кроме SignedXml!
 
Солидный холивар, аж попкорна захотелось :)
 
3:01 PM
@PavelMayorov Да, согласен, так тоже плохо. Идея снимается.
@PavelMayorov Это в некритических случаях, когда не страшно, если инвариант нарушен.
Вот я, допустим, очень недоволен возможностью классов реализовать IComparable<TSelf> нетранзитивно
Потому что если алгоритм сортировки зависнет, кто виноват? Автор класса, который реализовал неправильно? Или это я дурак, что сортирую?
@PavelMayorov А вот это аргумент. Почему же тогда для SignedXml не предусмотрено? Это баг?
 
3:17 PM
Почему бы разработчикам не законтрибьютить фикс в corefx?
 
3:44 PM
@VladD а как ты можешь это ограничить?
 
@Grundy Задать белый список правильных классов) Остальные объявить "обладающими фатальным недостатком"
 
4:09 PM
@vp_arth эм, транзитивность?
 
@Grundy и она тоже. Нельзя же быть недовольным своими собственными классами
 
@vp_arth можно.
Особенно, если это язык, где классов нет.
Да, @Grundy?
 
@Suvitruf Недовольным быть можно, но это нельзя!
 
4:40 PM
@Grundy Никак, система типов существующих языков слаба, и не может выразить такое ограничение. Ну по крайней мере тех, которые я знаю.
Хотя. Было бы неплохо, если бы язык мог обложить каждую реализацию интерфейса отдельно специфицированными пред- и постусловиями, чтобы их проверял язык — ну хотя бы динамически, если статически не может.
 
5:01 PM
@VladD потому что они .net core не поддерживают?
 
5:12 PM
@VladD "Это в некритических случаях, когда не страшно, если инвариант нарушен." - нет. Точка расширения должна делаться так, чтобы внутренние инварианты не были нарушены ни при каких условиях.
 
@VladD таки и @Grundy об этом же :)
@Suvitruf классы - не нужны
 
5:48 PM
@Grundy как и js.
 
@Suvitruf js меньше не нужен чем java :)
 
 
3 hours later…
8:43 PM
Я не понял. Сообщению об ошибке с предложением какого-никакого исправления висит уже неделю, и никакой обратной связи? Если сообщение попросту прошло мимо ответственных лиц, как можно обратить на него внимание?
10
Q: LTR and RTL nicknames mixture produces a messed up stream of characters (+ proposal of a hack to fix it)

ߊߚߤߘNote: I am aware that this issue was reported many times for at least 9 years. However, it is still not fixed, and I created a hack to fix it. Just for fun, I rendered my nickname in NKo script that happens to be RTL one. However, RTL nicknames make havoc being composed into a list along with L...

 
9:05 PM
@PavelMayorov Ну, это не всегда возможно. Вот пример с нетранзитивным сравнением: в этом случае удержать инварианты сортировки не получится.
@PavelMayorov Ну ССЗБ
Фреймворк может и не будут чинить
 

« first day (1546 days earlier)      last day (1767 days later) »