Это вряд ли, в случае с IOS, троян не имеет никакой ценности в сравнении с RCE уязвимостью. Такая уязвимость стоит миллионы долларов. Сам payload при этом может быть какой угодно, для его создания много ума не надо. Какой смысл использовать чей-то древний payload?
А почему вы думаете, что это была таже самая уязвимость, что и в 2019 году?
Если верить википедии, то уязвимость, которую эксплуатироал Pegasus закрыли в IOS 14.7, а в данном случае речь про уязвимость актуальную минимум до версии до 15.7 включительно. То есть это разные уязвимости.
В Go ценят простоту и прозрачность, которые первыми проносятся в жертву при использовании фреймворков. Для того, чтобы понять, как работает приложение, написанное с использованием фреймворка, нужно сначала понять, как устроен фреймворк, и какие неявные конвенции он использует. Код приложения становится несамодостаточным, его нельзя понять, не изучив предварительно фреймворк. В Go так стараются не делать. С библиотеками проблем в этом смысле меньше, так как они более узкосфокусированы, и не диктуют пользователям, как они должны разрабатывать приложение
То, что представленный подход - это анти-go согласен, но не из-за DDD. DDD не используют для разработки компиляторов, или библиотек, оно нужно для микросервисов и с go прекрасно сочетается. DDD не имеет никакого отношения ни к DI, ни к событиям ни к ORM, ни к какой-то структуре папок. DDD - это про то, как разделять ответственность между (микро)сервисами, модулями и пр. Без DDD микросервисы практически всегда вырождаются в распределенный монолит и если мы пишем микросервисы на go, то без DDD не обойтись. Но это не значит, что надо тащить DI, ORM и прочее из Java мира. В Go лучше без этого
Всё так, с точки зрения фаззера программа не черный ящик, про черный ящик я писал с точки зрения кода самого фаззинг-теста. Конечно, часто и код фаззинг тестов многое знает о тестируемой программе и совсем черных ящиков не бывает, тут речь скорее о шкале "черноящечности".
По воводу asan - это один из способов контролировать инварианты программы, и он подтверждает основную мысль: чем больше инвариантов автоматически контролируется, тем больше фаззер найдет в итоге багов
И в результате у каждого из 100500 репозиториев получается своя собственная структура, свои соглашения, различные настройки, хуки, настройки доступа, что приносит свои собственные трудности
По поводу семафора и LIFO, вам же не нужен был математически строгий LIFO, достаточно было сделать так, чтобы семафор не захватывал тот, кому уже не актуально. А значит можно было просто передавать разумный тайм-аут в SemaforeSlim.WaitAsync
Согласен, но общепринятых терминов для классификации функциональных тестов я не встречал, поэтому приходится выкручиваться. Если подскажете, буду благодарен.
Хороший вопрос, это тоже будет описано в другой статье. Если коротко, то тесты делятся на два класса:
1) Интеграционные. Это трудоёмкие медленные тесты, но их очень мало. Они проверяют, что продукт может корректно общаться с внешним миром. Эти тесты не проверяют, что продукт реализует конкретный пункт ТЗ, они проверяют, например, что если продукт зачем-то захочет отправить email, то он сможет в принципе это сделать и письмо действительно будет отослано куда надо с корректной темой, телом и т.д.
2) Функциональные. Это уже тесты по ТЗ, их много, они дешевы, работают быстро, но они не совсем «честные». Тест с помощью специального тестового фасада инициирует некоторую операцию и, например, проверяет, что от продукта пришло событие, что он захотел отправить email с правильной темой, телом и получателем согласно ТЗ. При этом то, что письмо реально отправилось уже не проверяется. При этом тестовый фасад может опубликовать любой участок кода продукта, находящийся на любом уровне абстракции.
У нас сейчас автотесты выглядят следующим образом: по коду продукта расставлены метки, которые генерируют специальные события для тестов. Тесты в этом случае представляют собой довольно простой скрипт, который анализирует корректность произошедших событий. В тесте формализуется ожидаемый «шаблон» событий (в простейшем случае — это просто линейная последовательность), и в случае расхождения с этим шаблоном, тест краснеет. Благодаря этому тесты дешевы в разработке и пригодны для legacy кода. Но это стало возможным только благодаря тому, что программисты могут модифицировать код и добавлять в него генерацию событий. Но это тема для отдельной статьи.
Спасибо, добавил примечание в начале статьи. Идея применить TDD к автотестам давно витает в воздухе, но пока не очень понятно, как её реализовать на практике..
Ок, виноват, забыл, что под lock-free обычно имеют ввиду thread-safe.
Глянул одним глазом код аллокаторов. Используются те же спин-блокировки, что и в EnterCriticalSection, так что один фиг.
Но тем не менее, не вижу необходимости в многопоточнй куче для данной задачи, если обработку каждой страницы делать в отдельном потоке, тогда алгоритм парсинга страницы будет отднопоточным и синхронизация внутри алгоритма не потребуется.
> — Если инспекторов несколько, то очень полезно, чтобы они не видели дефекты, найденные другими инспекторами. Это позволит потом посчитать количество дубликатов (одинаковых дефектов от разных инспекторов). Обычно чем их больше, тем выше качество инспекции.
Интересная мысль, спасибо!
> — Все изменения, сделанные автором в ходе исправлений нужно снова послать на инспекцию. А то иногда бывает, что исправлений больше, чем исходного кода и это все коммитится в репозиторий без инспекции.
Согласен, скажу даже больше: исправления должны валидироваться авторами дефектов.
Не обязательно. Стоимость пропущенного в production дефекта равняется стоимости выпуска критического исправления, которая более менее известна заранее и зачастую очень высокая.
Все зависит от стоимости пропущенного в production дефекта, то есть от конкретного программного продукта. Иногда такие дефекты стоят очень дорого, и тут даже время генерального директора можно потратить на поиск такого дефекта, если оно принесет пользу :)
Множества дефектов, обнаруживаемых при инспектировании и при тестировании, конечно, не совпадают, но они во многом пересекаются. Чем раньше дефект будет пойман, тем дешевле его исправление, соответственно, дефект, пойманный на инспектировании в исправлении обходится дешевле, чем тот же дефект, пойманный во время тестирования. Так что нет никаких причин во время инспектирования не искать дефекты, которые теоретически могут быть пойманы тестировщиками (если они его не прошляпят).
Это вряд ли, в случае с IOS, троян не имеет никакой ценности в сравнении с RCE уязвимостью. Такая уязвимость стоит миллионы долларов. Сам payload при этом может быть какой угодно, для его создания много ума не надо. Какой смысл использовать чей-то древний payload?
А почему вы думаете, что это была таже самая уязвимость, что и в 2019 году?
Если верить википедии, то уязвимость, которую эксплуатироал Pegasus закрыли в IOS 14.7, а в данном случае речь про уязвимость актуальную минимум до версии до 15.7 включительно. То есть это разные уязвимости.
Да, вы правы, я неточно выразился
В Go ценят простоту и прозрачность, которые первыми проносятся в жертву при использовании фреймворков. Для того, чтобы понять, как работает приложение, написанное с использованием фреймворка, нужно сначала понять, как устроен фреймворк, и какие неявные конвенции он использует. Код приложения становится несамодостаточным, его нельзя понять, не изучив предварительно фреймворк. В Go так стараются не делать. С библиотеками проблем в этом смысле меньше, так как они более узкосфокусированы, и не диктуют пользователям, как они должны разрабатывать приложение
То, что представленный подход - это анти-go согласен, но не из-за DDD. DDD не используют для разработки компиляторов, или библиотек, оно нужно для микросервисов и с go прекрасно сочетается. DDD не имеет никакого отношения ни к DI, ни к событиям ни к ORM, ни к какой-то структуре папок. DDD - это про то, как разделять ответственность между (микро)сервисами, модулями и пр. Без DDD микросервисы практически всегда вырождаются в распределенный монолит и если мы пишем микросервисы на go, то без DDD не обойтись. Но это не значит, что надо тащить DI, ORM и прочее из Java мира. В Go лучше без этого
Всё так, с точки зрения фаззера программа не черный ящик, про черный ящик я писал с точки зрения кода самого фаззинг-теста. Конечно, часто и код фаззинг тестов многое знает о тестируемой программе и совсем черных ящиков не бывает, тут речь скорее о шкале "черноящечности".
По воводу asan - это один из способов контролировать инварианты программы, и он подтверждает основную мысль: чем больше инвариантов автоматически контролируется, тем больше фаззер найдет в итоге багов
И в результате у каждого из 100500 репозиториев получается своя собственная структура, свои соглашения, различные настройки, хуки, настройки доступа, что приносит свои собственные трудности
По поводу семафора и LIFO, вам же не нужен был математически строгий LIFO, достаточно было сделать так, чтобы семафор не захватывал тот, кому уже не актуально. А значит можно было просто передавать разумный тайм-аут в SemaforeSlim.WaitAsync
1) Интеграционные. Это трудоёмкие медленные тесты, но их очень мало. Они проверяют, что продукт может корректно общаться с внешним миром. Эти тесты не проверяют, что продукт реализует конкретный пункт ТЗ, они проверяют, например, что если продукт зачем-то захочет отправить email, то он сможет в принципе это сделать и письмо действительно будет отослано куда надо с корректной темой, телом и т.д.
2) Функциональные. Это уже тесты по ТЗ, их много, они дешевы, работают быстро, но они не совсем «честные». Тест с помощью специального тестового фасада инициирует некоторую операцию и, например, проверяет, что от продукта пришло событие, что он захотел отправить email с правильной темой, телом и получателем согласно ТЗ. При этом то, что письмо реально отправилось уже не проверяется. При этом тестовый фасад может опубликовать любой участок кода продукта, находящийся на любом уровне абстракции.
Вообще-то, распределение звезд — это далеко не случайный процесс, так как вмешивается гравитация.
Глянул одним глазом код аллокаторов. Используются те же спин-блокировки, что и в EnterCriticalSection, так что один фиг.
Но тем не менее, не вижу необходимости в многопоточнй куче для данной задачи, если обработку каждой страницы делать в отдельном потоке, тогда алгоритм парсинга страницы будет отднопоточным и синхронизация внутри алгоритма не потребуется.
Всем все лишь бы стащить.
HeapCreate (флаг HEAP_NO_SERIALIZE)
Интересная мысль, спасибо!
> — Все изменения, сделанные автором в ходе исправлений нужно снова послать на инспекцию. А то иногда бывает, что исправлений больше, чем исходного кода и это все коммитится в репозиторий без инспекции.
Согласен, скажу даже больше: исправления должны валидироваться авторами дефектов.