>Поэтому, если у нас есть более уязвимое звено, то смысла ноль целых ноль десятых шифровать что-то где-то в другом месте.
Вы предлагаете ничего не делать? Расставим слабых звеньев побольше, чтобы негодяй мог выбирать из них.
>Шифровать же пароль совершенно бессмысленно.
зная соль+алгоритм хеширования, слабым звеном будет скорее всего сам пароль, который злоумышленик будет подбирать простым брутфорсом по словарикам.
>но если злойумышленник имеет доступ на комп жертвы, то что тогда?
безопасность всегда была процессом уменьшающим риски, а не магическим инструментом который спасёт нас от всего.
эх :) «You like C++ because you’re only using 20% of it. And that’s fine, everyone only uses 20% of C++, the problem is that everyone uses a different 20%»
Так нужно чтобы задача выполнялась быстрее в CPython'е или наследство родителя? На Си вообще большинство вещей делалось бы иначе. В питоне свои особенности, зачем пытаться делать так же как в си…
Можно попробовать через пайп прокидывать всё нужное наследство, так получим параллелизм(если конечно кол-во логических процессоров больше одного)
ещё можно приклеить clone или posix_spawn к питону и делать clone/exec без оверхеда на копирование таблиц для работы cow.
1 и 2) легко расширяются с помощью модулей, можно делать блокирующие вызовы, какую-нибудь тяжёлую работу, зависимость в модулях от проприетарщины, которая делает блокирующие вызовы.
3) нужно подстраиваться под стэйт машину, которая была реализована в этом приложении. Не знаю как сейчас, но раньше с nginx'ом небыло возможности даже сделать простое синхронное логирование без блокирующего вызова в своём модуле. Но это не проблема данного подхода, просто так уж сделали.
Неблокирующую работу с сетью можно использовать вместе с многопоточностью, где кол-во потоков сделать равным кол-ву логических процессоров и все будут довольны :)
третий вариант хоть и самый производительный, но на нём одном к сожалению не реализовать ничего сложного, видимо поэтому он у вас и получается самым производительным :)
а нам приходиться дополнительно городить свои планировщики и выбирать использование безстэковых/стэковых coroutine для простоты программирования. либо вырисовывая различные конечные автоматы, восстановление стэка в которых тоже бывает не такой уж скоростной операцией с кучей кэш миссов.
man execve
execve() does not return on success, and the text, data, bss, and stack
of the calling process are overwritten by that of the program loaded.
Никакого увеличения куска памяти. Используйте инструменты с умом.
Вы предлагаете ничего не делать? Расставим слабых звеньев побольше, чтобы негодяй мог выбирать из них.
2. генерация симметричного ключа
3. передача симметричного ключа, зашифрованого пабликом
4. шифруем логин/пароль симметричным и передаём на сервер
Это так же не спасёт от man in the middle, но как показывает практика, сертификаты с этим тоже не справляются.
зная соль+алгоритм хеширования, слабым звеном будет скорее всего сам пароль, который злоумышленик будет подбирать простым брутфорсом по словарикам.
безопасность всегда была процессом уменьшающим риски, а не магическим инструментом который спасёт нас от всего.
сколько общих паттернов будет, ну скажем в Erlang и Java?
Можно попробовать через пайп прокидывать всё нужное наследство, так получим параллелизм(если конечно кол-во логических процессоров больше одного)
ещё можно приклеить clone или posix_spawn к питону и делать clone/exec без оверхеда на копирование таблиц для работы cow.
Хочется тоже попасть в эту сказку :)
>надо просто уметь их готовить.
И вы конечно же работали с libnuma
3) нужно подстраиваться под стэйт машину, которая была реализована в этом приложении. Не знаю как сейчас, но раньше с nginx'ом небыло возможности даже сделать простое синхронное логирование без блокирующего вызова в своём модуле. Но это не проблема данного подхода, просто так уж сделали.
стэйт хранится в стэке
2) Мультитредовый
стэйт хранится в стэке
3) Асинхронный
>а нам приходиться дополнительно городить…
а нам приходиться дополнительно городить свои планировщики и выбирать использование безстэковых/стэковых coroutine для простоты программирования. либо вырисовывая различные конечные автоматы, восстановление стэка в которых тоже бывает не такой уж скоростной операцией с кучей кэш миссов.
execve() does not return on success, and the text, data, bss, and stack
of the calling process are overwritten by that of the program loaded.
Никакого увеличения куска памяти. Используйте инструменты с умом.
Parallel != Concurrent
en.wikipedia.org/wiki/Parallel_computing
en.wikipedia.org/wiki/Concurrent_computing