Сергей П

Давайте различать. Шифрование пароля - это не то же самое, что шифрование других данных. Пароль следует не шифровать, а хешировать. Это такое шифрование, которое нельзя расшифровать обратно. То есть имея хеш нельзя получить пароль, а имея пароль можно получить точно такой же хеш. Существуют для этого специальные хеш функции. Но хешировать пароли мало, их нужно сперва солить. Соль - это произвольный текст, присоединённый к паролю перед хешированием и размещаемый рядом с хешем в открытом виде. Нужна соль для того, чтобы нельзя было подбирать простые пароли по значению их хешей.
Проверка пароля будет такой:
1. Запрашиваем у пользователя логин и пароль.
2. Достаём из БД по логину хеш солёного пароля.
3. С этой солью хешируем введённый пользователем при авторизации пароль и сличаем хеши. Совпали -- значит пускаем.

Шифрование других данных, очевидно, нужно уже обратимое, чтобы можно было расшифровать. И теперь есть два варианта: серверное и клиентское шифрование.

Серверное не имеет смысла, поскольку скомпрометированный сервер означает утечку всего необходимого для расшифровки данных. Не скомпрометированный сервер означает, что данные и так вроде бы в безопасности. Значит шифровать не нужно (ну кроме некоторых специальных случаев).

Клиентское шифрование - это когда сервер не имеет возможности расшифровать данные. Они шифруются на клиенте перед отправкой ключом, который не покидает пользовательского компьютера. Потом клиент снова запросит шифрованные данные с сервера и расшифрует его тоже сам. Это иногда имеет смысл. Например если вы храните keychain с паролями на сервере, но не хотите их утечки в случае взлома сервера.

Есть ещё p2p шифрование, где с помощью специального алгоритма пользователи обмениваются ключами через сервер так, чтобы эти ключи не мог узнать ни сервер, ни кто иной. Далее от пользователя к пользователю ходит через сервер шифрованная информация, которую кроме оконечных пользователей никто не может расшифровать. Это так называемое оконечное шифрование.

В итоге хранить шифрованные данные на сервере не нужно, поскольку всё что нужно для расшифровки тоже на этом сервере. Если кто-то туда влез, то он и ключи шифрования свистнет и данные перехватит после расшифровки или перед расшифровкой. Нет смысла прятать сиськи. если жопа голая.

О, чуть не забыл. Есть опасность утечки незашифрованных данных из датацентров при наличии физического доступа к жестким дискам. Чтобы обезопасить себя в этом смысле, можно применить прозрачное шифрование файловой системы. Работающая операционная система будет знать ключ для расшифровки данных, но отсоединённый диск становится без ключа бесполезным. Однако это малоэффективно, если украдут весь сервер вместе с дисками. Зато эффективно против восстановления жуликами данных, если диск сгорел, а его сисадмин выбросил не просверлив.

Ещё один аспект - это канал передачи. Нет смысла опасаться перехвата незашифрованных данных в канале передачи даже на последней миле провайдера клиента. Об этом заботится SSL когда правильно настроен HTTPS и сертификаты не скомпрометированы, а пользователь не подмахнул левый сертификат.

Если вы задаёте вопрос о необходимости шифрования, значит вам ничего сверх вышесказанного шифровать не нужно. Это усложнит систему, сделает её менее надёжной, более (как ни парадоксально) уязвимой и отнимет ресурсы процессора, памяти, не даст использовать или усложнит кэширование и прочие оптимизации.

Тоже попробую пояснить.
При разработке защиты ПО всегда нужно сопоставлять цену взлома и профит от взлома.
Арифметика примерно такая.
Если цена взлома в k раз меньше суммарного профита от взлома (с учетом масштабирования) и сильно не превышает цену повторного написания приложения, то продукт будет взломан и это вопрос времени.
Это пуассоновский процесс и чем больше k тем быстрее произойдёт вероятный взлом.

Разработчик защищая продукт огребает существенный геморрой с поддержкой, отладкой, диагностикой, обновлением и расширением ПО.
Цена этого геморроя может оказаться не сильно ниже ущерба от взлома. Тогда такую защиту применять не стоит. Особенно если ваш продукт развивается и растёт, в нём регулярно появляются новые фичи и каждый раз ломать дорого (даже с учетом, что повторный взлом дешевле первого).

Если есть возможность разместить код на сервере и заменить проблему защиты алгоритма проблемой верификации авторизации, то весь геморрой можно вынести в отдельный слой продукта, который достаточно абстрагирован от обновляемого и поддерживаемого кода.

Подгрузка зашифрованных исходников и байткода с сервера нецелесообразна из-за геморроя и фактического отказа от кроссплатформенности, услоднения поддержки и диагностики проблем.

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

В итоге. У вас с вашим списком мер есть шанс построить бастион вокруг сортира. Если сортир с золотыми унитазами, то их всё равно сопрут, а если нет, то нафиг столько геморроя?

Если у вас в коде есть алгоритмические участки, которые можно изолировать и трудено повторить или эмулировать (это должны быть нужные функциональные участки реально постоянно работающего кода), то их можно вынести в крипто-ключ в виде USB-донгла. Это тоже немалый гемор, но порой вполне применимый.

Я не знаю что у вас за продукт, стало бы понятнее при наличии подробностей, но в общем случае хорошо работают и достаточно эффективны (если речь не идёт о "ломе") следующие меры в порядке убывания удобства:
1. вынос функциональности на сервер в виде API
2. байткод без исходников
3. обфускация (лёгкая)
4. обфускация (тяжелая, с поддержкой полиморфности кода)

Всякие упаковки в экзешники и шифрование - это уже так... от лукавого.
Просто вынесите ключевой ресурс на сервер и всё.

Я использовал для этой цели virtualbox.
Он имеет интерфейс командной строки и позволяет запускать машину через неё.
С запуском же приложения в андроиде так просто вопрос не решить.
Нужно ставить какую-то тулзу для удалённого управления андроидом, я думаю.
Встречал такие, но не искал из с CLI. Наверно есть. Но если нет, то на андроиде вполне можно поднять sshd, и я не вижу причин почему бы не делать через него всё что угодно.

Мы решили вопрос доступа к API телеграма так.
Стандартный домен API телеги для ботов заблочен роскопозором, поэтому в конфиге нашего бота подменён домен для доступа к АПИ.
Наш же VDS за пределами юрисдикции роскомпозора в конфиге nginx имел такую вот запись:

server {
    listen tg.my_own_domain.ru:8079;
    server_name tg.my_own_domain.ru;
    access_log /var/log/nginx/tg.my_own_domain.ru-access.log;
    error_log /var/log/nginx/tg.my_own_domain.ru-error.log;
    location / {
        proxy_set_header X-Forwarded-Host $host;
        proxy_set_header X-Forwarded-Server $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_pass https://api.telegram.org/;
        client_max_body_size 100M;
    }
}

Не знаю какие актуальны, но могу накидать более-менее оригинальных идей.
Это только часть, есть ещё=).

Попробуйте вытаскивать из видео не кадр, а фрагмент. Эмпирически можно подобрать его длину, чтобы гарантированно попался ключевой кадр.
Из вырезанного фрагмента, сохранённого уже без сжатия можно отдельным вызовом ffmpeg получить последний кадр.

Для 37.677751,55.757718:

https://static-maps.yandex.ru/1.x/?ll=37.677751,55.757718&size=200,200&spn=0.016457,0.00619&l=map

https://static-maps.yandex.ru/1.x/?ll=37.677751,55...

Я бы одним SQL-запросом это сделал.

DELETE FROM my_history_table t 
WHERE t.id <= (
    SELECT t2.id
    FROM my_history_table t2 
    ORDER BY datetime_open DESC
    SKIP 20
    LIMIT 1
)

Диалект SQL подправить по вкусу.

Вот такая штука будет работать примерно со скоростью мегабайт в секунду.

cat oldlogfile.log | py -x "', '.join(['='.join((k, datetime.datetime.strptime(v, '%Y-%m-%d %H:%M:%S').strftime('%H:%M:%S.000 +0700 %a %b %d %Y')) if k == 'TIME' else (k, v)) for k, v in ((kv.split('=') for kv in x.split(', ')))])" > newlogfile.log

Измерял так:

yes "RESULT=xxxxx, TIME=2020-01-20 18:43:12, HOST=xxxxxxxxxxx, NAME=xxxxxxxx" \
  | pv \
  | py -x "', '.join(['='.join((k, datetime.datetime.strptime(v, '%Y-%m-%d %H:%M:%S').strftime('%H:%M:%S.000 +0700 %a %b %d %Y')) if k == 'TIME' else (k, v)) for k, v in ((kv.split('=') for kv in x.split(', ')))])" \
  > /dev/null

Зато на порядок понятнее и можно по человечески формат подправить.

json.dumps(my_data, ensure_ascii=False)
Там выше правильно ответили ссылкой на документацию.
Аргумент ensure_ascii требует экранировать не ASCII символы при сериализации. Если его поставить в False, то будет то, что вам нужно.

Есть ещё удобный контекстный менеджер для подавления исключений в случаях, когда не требуется какой бы то ни было обработки.

from requests.exceptions import ConnectTimeout
from contextlib import suppress

with suppress(ConnectTimeout):
    # code