python защита исходного кода
Как защитить исходный код Python?
Помощь в написании контрольных, курсовых и дипломных работ здесь.
Защитить исходный код странички ASP
Технология ASP.NET позволяет компиллировать странички *.ASP (Слышал, что получается *.ASPX) Можно.
Перевести исходный код на Python
#include #include #include int i0, i1; double x0, sigma, h, tay.
Как узнать исходный код метода из dll через код C#?
Как узнать исходный код метода из dll через код C#? помогите, пожалуйста!! :sorry:
Как получить исходный код *.exe или отредактировать его исполняемый код?
Собственно возможно ли декомпилить его так, чтобы можно было потом обратно скомпилировать? Или.
snow78, защитить никак, можно обфусцировать код.
а какие популярные компании распространяют питоновский код, скомпилированный в exe?
Добавлено через 2 минуты
Да вот и подтверждение по ссылке выше(с хабра).»Бинарные файлы модулей *.pyc и *.pyo (байт-код) легко декомпилируются, поэтому распространять их в чистом виде нельзя (если уж мы решили не показывать исходники по-настоящему).»
Если бы они могли на 100% защитить свои программы, то не появлялись бы их пиратские копии.Есть разные пути защиты своих программ, один из них, это тот, о котором сказал Garry Galler, это держать исходник на сервере. Так чаще всего поступают с играми, которые работают в режиме онлайн. Для локальных игр используют игровые приставки, но и они по моему часто требуют подключения к интернет серверу. Есть еще один путь, это богатый сервис сопровождения через интернет, чего лишаются те, кто использует пиратские программы, что склоняет пользователей использовать лицензионные продукты. Но на все эти варианты защиты, требуется наличие большого штата разработчиков, которые работают именно на обеспечение защиты. Если Вы не работаете в большой мощной фирме, то сомневаюсь, что Вы сможете заработать на продукте, который разработали в одиночку (если он даже будет пользоваться спросом), пытаясь организовать массовую продажу. Просто продукт, если он будет пользоваться спросом, разойдется без Вашего участия. Заработать программированием Вы можете только выполняя уникальные заказы, как на свою компанию, так и на стороне.
Ну или если Вы собрав талантливых единомышленников создадите революционный продукт, который постоянно будет совершенствоваться, так что пираты просто не будут успевать за Вами взламывать программы, что бы пиратские программы безнадежно устаревали. Или Ваша программа, что бы быть актуальной, должна постоянно обновлять информацию. Как например библиотеки у Касперского, или программы 1С, которые постоянно отслеживают все законодательные изменения и так далее.
Добавлено через 18 минут
snow78, Кстати, я читал про проект, разрабатываемый компанией Касперского. Если они от него не отказались, то это пожалуй самый перспективный способ защиты. Они планировали создать макеты, включая операционные системы, что бы потом для каждого заказчика из макета быстро создавать уникальный код, с которым не смогут разобраться хакеры, так как на этот код не будет универсального исходника. Для разных заказчиков будут, даже одни и те же задачи, реализованы с помощью разных кодов, включая индивидуальные ОС. Не знаю, получается у них реализовать эту задумку или нет, но идея очень мощная. Правда и реализовать такую идею может только большой мощный коллектив талантливых разработчиков.
Как не продолбать пароли в Python скриптах
Все меняется, когда мы убираем из схемы человека, который старательно вводит ключ с бумажки. При взаимодействии двух информационных систем, на клиентской стороне в любом случае должен храниться пароль в открытом для системы виде, чтобы его можно было передать и сравнить с эталонным хешем. И вот на этом этапе админы обычно открывают местный филиал велосипедостроительного завода и начинают старательно прятать, обфусцировать и закапывать секретный ключ в коде скриптов. Многие из этих вариантов не просто бесполезны, но и опасны. Я попробую предложить удобное и безопасное решение этой проблемы для python. И чуть затронем powershell.
Как делать не надо
Всем знакома концепция «временного скриптика». Вот буквально только данные по-быстрому распарсить из базы и удалить. А потом внезапно выясняется, что скрипт уже из dev-зоны мигрировал куда-то в продакшен. И тут начинают всплывать неприятные сюрпризы от изначальной «одноразовости».
Чаще всего встречается вариант в стиле:
Проблема в том, что здесь пароль светится в открытом виде и достаточно просто обнаруживается среди залежей старых скриптов автоматическим поиском. Чуть более сложный вариант идет по пути security through obscurity, с хранением пароля в зашифрованном виде прямо в коде. При этом расшифровка обратно должна выполняться тут же, иначе клиент не сможет предъявить этот пароль серверной стороне. Такой способ спасет максимум от случайного взгляда, но любой серьезный разбор кода вручную позволит без проблем вытащить секретный ключ. Код ниже спасет только от таких «shoulder surfers»:
Самый неприятный сценарий — использования систем контроля версии, например git, для таких файлов с чувствительной информацией. Даже, если автор решит вычистить все пароли — они останутся в истории репозитория. Фактически, если вы запушили в git файл с секретными данными — можете автоматически считать их скомпрометированными и немедленно начинать процедуру замены всех затронутых credentials.
Использование системного хранилища
Есть крутейшая библиотека keyring. Основной принцип работы строится на том, что у каждого пользователя ОС есть свое зашифрованное хранилище, доступ к которому возможен только после входа пользователя в систему. Она кроссплатформенная и будет использовать тот бэкенд для хранения паролей, который предоставлен операционной системой:
Сравним сложность атаки
При хранении пароля непосредственно в скрипте нужно:
Пример использования
Безопасный ввод пароля
Еще один частый вариант утечки секретных паролей — история командной строки. Использование стандартного input здесь недопустимо:
В примере выше я уже упоминал библиотеку getpass:
Ввод данных при ее использовании аналогичен классическому *nix подходу при входе в систему. Ни в какие системные логи данные не пишутся и не отображаются на экране.
Немного о Powershell
Для Powershell правильным вариантом является использование штатного Windows Credential Locker.
Реализуется это модулем CredentialManager.
Защита Python приложений
Метод #1: защита через шифрование данных (Sentinel Data File Protection)
Защита приложения Python с помощью Sentinel Data File Protection состоит из трех этапов:
Защищенное приложение может распространяться путем упаковки защищенного с помощью Envelope интерпретатора вместе с зашифрованными *. pyc файлами (например, с использованием pyinstaller ).
Примеры защиты
Для Windows
После установки Sentinel LDK пример, демонстрирующий защиту Python приложения для Windows с помощью Sentinel Data File Protection, можно найти в директории:
C:\Users\ \Documents\Gemalto\Sentinel LDK version\Samples\Envelope\Python \data_file_protection
Прилагаемые скрипты демонстрируют защиту простого Python приложения, которое можно найти в директории:
C:\Users\ \Documents\Gemalto\Sentinel LDK version\Samples\Envelope\Python \sample_app
Директория data_file_protection содержит:
● build_dfp_protected_python2_app.bat
Этот сценарий защищает и упаковывает пример приложения для Python2 для Windows, с использованием: кода разработчика DEMOMA, Sentinel Envelope, утилит ы шифрования файлов данных для Sentinel LDK (dfcrypt) и pyinstaller.
● envelope_python2.prjx
Файл проекта Sentinel Envelope, в котором указаны параметры Envelope для защиты интерпретатора Python2 (python27.dll) для приведенного выше сценария.
● build_dfp_protected_python3_app.bat
Этот сценарий защищает и упаковывает пример приложения для Python3 для Windows, с использованием: кода разработчика DEMOMA, Sentinel Envelope, утилит ы шифрования файлов данных для Sentinel LDK (dfcrypt) и pyinstaller.
● envelope_python3.prjx
Файл проекта Sentinel Envelope, в котором указаны параметры Envelope для защиты интерпретатора Python3 (python37.dll) для приведенного выше сценария.
Для Linux
Прилагаемые скрипты демонстрируют защиту простого Python приложения, которое можно найти в директории:
Директория data_file_protection содержит:
● build_dfp_protected_python2_app.sh
Этот сценарий защищает и упаковывает пример приложения для Python2 для Linux с использованием: кода разработчика DEMOMA, Sentinel Linux Envelope, утилиты шифрования файлов данных для Sentinel LDK (dfcrypt) и pyinstaller.
● build_dfp_protected_python3_app.sh
Этот сценарий защищает и упаковывает пример приложения для Python3 для Linux с использованием: кода разработчика DEMOMA, Sentinel Linux Envelope, утилиты шифрования файлов данных для Sentinel LDK (dfcrypt) и pyinstaller.
Процесс защиты
Шаги для создания защищенного приложения с использованием Sentinel Data File Protection и Sentinel Envelope :
Сборка приложения и зависимостей в *. py модуль
Запустите pyinstaller с параметрами: «- d noarchive » для требующего защиты*. py модуля, например:
Результатом этого шага является автономная папка ( dist / application _ name >), содержащая ваше приложение и все его зависимости.
Примечание: Если установленный pyinstaller не поддерживает ключ «- d noarchive «, он слишком стар и его необходимо обновить с помощью команды pip :
Шифрование *.py модулей
Используйте dfcrypt для шифрования чувствительных модулей байт-кода вашего приложения, например:
Хотя это и не является строго обязательным, рекомендуется использовать ключ «— key :» для указания общего ключа шифрования для всех модулей приложения. Это позволяет использовать логику кэширования, которая может существенно улучшить время запуска приложения, использующего большое количество защищенных модулей. Не указывая «— key :», команда dfcrypt выбирает случайный ключ для каждого файла.
Когда закончите с шифрованием, замените исходные файлы их зашифрованным аналогом, например:
copy encrypted/moduleA.pyc dist//
copy encrypted/moduleB.pyc dist//
Защита интерпретатора Python
Защитите с помощью Envelope библиотеку интерпретатора Python (*. dll / *. so ) с поддержкой возможности чтения зашифрованных файлов данных:
Например в Linux и Python 2:
Ключ «—dfp» активирует Data File Protection, что позволяет защищенному интерпретатору Python выполнять зашифрованные модули Python.
В Windows используйте Sentinel Envelope и активируйте Data File Protection Version 2.
Скопируйте выходные файлы Envelope в дтректорию: dist/.
Чтобы развернуть защищенное приложение, просто скопируйте папку dist / application _ name > на целевой компьютер.
Метод #2: экспорт модулей через Cython и защита с помощью Sentinel Envelope
Защита приложения Python с помощью Cython и Sentinel Envelope состоит из трех этапов:
Защищенное приложение можно распространять, предоставляя защищенные модули расширения Python вместе со стартовым скриптом вашего приложения (например: pyinstaller ).
Примеры защиты
Для Windows
C:\Users\ \Documents\Gemalto\Sentinel LDK version\Samples\Envelope\Python \cythonize_and_envelope
C:\Users\ \Documents\Gemalto\Sentinel LDK version\Samples\Envelope\Python \sample_app
Директория cythonize_and_envelope содержит:
● build_python2.bat Этот сценарий защищает и упаковывает пример приложения для Python2 под Windows, с использованием: кода разработчика DEMOMA, Cython, компилятора Microsoft Visual C ++ для Python 2.7, Sentinel Envelope и pyinstaller.
● envelope_cythonized_py2modules.prjx
Файл проекта Sentinel Envelope, который задает параметры Envelope для защиты расширений Python (moduleA.pyd, moduleB.pyd), которые были созданы с помощью приведенного выше сценария.
● build_python3.bat Этот сценарий защищает и упаковывает пример приложения для Python3 под Windows, с использованием: кода разработчика DEMOMA, Cython, Microsoft Build Tools для Visual Studio 2019, Sentinel Envelope и pyinstaller.
● envelope_cythonized_py3modules.prjx
Файл проекта Sentinel Envelope, который задает параметры Envelope для защиты расширений Python (moduleA.pyd, moduleB.pyd), которые были созданы с помощью приведенного выше сценария.
Для Linux
Пример защиты приложения Python для Linux с использованием Cython и Sentinel Envelope можно найти в директории:
Директория cythonize_and_envelope содержит:
● build_python2.sh
Этот сценарий защищает и упаковывает приложение для Python2 под Linux с использованием: кода разработчика DEMOMA, Cython, GCC, Sentinel Envelope и pyinstaller.
● build_python3.sh
Этот сценарий защищает и упаковывает приложение для Python3 под Linux с использованием: кода разработчика DEMOMA, Cython, GCC, Sentinel Envelope и pyinstaller.
Процесс защиты
Шаги для создания защищенного приложения с использованием Cython и Sentinel Envelope :
Cython может быть установлен с использованием команды pip :
Запустите cython и укажите, должен ли он обрабатывать код как Python 2 или Python 3:
Установите требуемый компилятор:
● Python2: C:\Users\ \AppData\Local\Programs\Common\Microsoft\Visual C++ for Python\9.0\vcvarsall.bat» amd64
● Python3: C:\ \VC\Auxiliary\Build\vcvarsall.bat» amd64
apt install python2-dev
apt install python3-dev
Защита нативного Python приложения (исполняемого файла) с помощью утилиты Envelope
Пример команды для защиты для Linux :
Для Windows используйте Sentinel Envelope точно так же, как при защитите обычного dll / exe файла.
Об одном способе защиты исходников Python-программы
Как всё начиналось
Однажды мне пришлось участвовать в разработке одного небольшого проекта для научных расчётов, который разрабатывался на языке программирования Python. Изначально Python был выбран как удобный и гибкий язык для экспериментов, визуализации, быстрого прототипирования и разработки алгоритмов, но в дальнейшем стал основным языком разработки проекта. Надо заметить, что проект был хоть и не большим, но довольно насыщенным технически. Для обеспечения требуемой функциональности, в проекте широко применялись алгоритмы теории графов, математическая оптимизация, линейная алгебра и статистика. Также использовались декораторы, метаклассы и инструменты интроспекции. В процессе разработки пришлось использовать сторонние математические пакеты и библиотеки, например, такие как numpy и scipy, а также многие другие.
Со временем стало ясно, что переписывать проект на компилируемом языке слишком затратно по времени и ресурсам. Скорость работы и потребление памяти не являлись критичными показателями в данном случае и были вполне приемлемыми и достаточными. Поэтому было принято решение оставить всё как есть, и продолжить разработку и поддержку проекта на языке Python. К тому же, документация по большей части уже была написана с использованием Sphinx.
Проект являлся библиотекой, функции которой использовались в одном из модулей расширения в крупном программном комплексе. Программный комплекс был написан на C++, являлся коммерческим продуктом, имел защиту с аппаратным ключом и поставлялся клиентам без предоставления исходных кодов.
Здесь сразу обозначилась новая проблема: как защитить исходные коды нашей Python-библиотеки? Может быть, в ином случае никто бы не стал этим заниматься, я бы уж точно, но в библиотеке были реализованы некоторые ноу-хау, и руководители проекта не хотели, чтобы данные наработки попали к конкурентам. Так как я был одним из исполнителей, мне пришлось озаботиться данной проблемой. Далее я постараюсь рассказать об основной идее, что из этого вышло, и как нам удалось скрыть Python-исходники от лишних глаз.
Что предлагают люди
Как известно, наверное, большинству разработчиков, Python — язык интерпретируемый, динамический с богатыми возможностями интроспекции. Бинарные файлы модулей *.pyc и *.pyo (байт-код) легко декомпилируются, поэтому распространять их в чистом виде нельзя (если уж мы решили не показывать исходники по-настоящему).
Как, я думаю, любой на моём месте, сначала я решил поискать, а что вообще делают люди в таких случаях? Первые же поисковые запросы показали, что люди не знают, что делать и спрашивают об этом на stackoverflow и в других местах, например, вот вопрос на stackoverflow. Поискав, я пришёл к выводу, что везде предлагают несколько спорных способов:
По многим причинам я отбросил все эти способы как неподходящие. Например, обфускация Python-кода. Ну какая может быть обфускация, когда синтаксис языка построен на отступах, а сам язык пронизан «хитрой интроспекцией»? Транслировать все Python-модули в бинарные модули расширения тоже не представлялось возможным, т. к. проект, напомню, был достаточно сложным технически с использованием множества сторонних пакетов, да и сам состоял из большого числа модулей в многоуровневой иерархии пакетов, которые было утомительно перегонять в *.pyd, а потом ловить баги, вылезающие на ровном месте. Возиться с заменой опкодов не хотелось, так как пришлось бы распространять и поддерживать собственную сборку интерпретатора Python, да ещё и компилировать им Python-модули всех используемых сторонних библиотек.
В какой-то момент мне показалось, что эта идея с защитой Python-исходников бесполезная, надо всё это бросить и убедить руководство, что ничего не выйдет и заняться чем-нибудь полезным. Отдаём *.pyc файлы и ладно, кто там будет разбираться? Убедить не получилось, переписывать библиотеку на C++ никому не хотелось, а проект нужно было сдавать. В итоге всё же кое-что получилось сделать. Об этом, если всё ещё интересно, можно прочитать далее.
Что сделали мы
Что может лучше всего защитить какую-либо информацию на цифровом носителе от посторонних? Я думаю, что это шифрование. Вооружившись этой фундаментальной идеей, я решил, что исходники надо шифровать, а иначе и быть не должно. Для стороннего наблюдателя, который начал проявлять излишний интерес, всё это должно выглядеть как куча непонятных файлов с непонятным содержимым. Вполне себе обфускация, но более продвинутая чем заменять имена переменных и вставлять пустые строчки.
Ход моих мыслей был следующим:
Основная идея, думаю, ясна — это более продвинутая обфускация. Как это сделать? Погуглив, я пришёл к выводу, что сделать это вполне реально и даже достаточно просто. С шифрованием исходников всё понятно, зашифровать и/или обфусцировать файлы можно множеством способов, главное, чтобы там была «каша» и «ничего не понятно», а также всё это должно возвращаться к первоначальному виду неизвестным способом (в случае обфускации). Для приведённого здесь примера я буду использовать Python-модуль base64 для «шифрования». В некритичных случаях можно применять замечательный пакет obfuscate.
Python the Importer Protocol
Итак, вроде бы добрались до сути. Можно привести простой пример. Минимальный пример класса, реализующего Importer Protocol, подходящего для наших целей. Он будет заниматься импортом модулей «зашифрованных» base64 из обычной структуры пакетов (в данном случае для простоты мы просто «зашифровали содержимое» файлов, но никак не меняли их имена и структуру пакетов). Считаем, что расширения файлов для наших модулей будут гордо называться «.b64».
Как это работает? Первым делом при создании экземпляра класса собирается информация о модулях нашей библиотеки, которую мы «шифруем». Затем при загрузке конкретного модуля, читается нужный «зашифрованный» файл, «расшифровывается» и импортируется с помощью средств модуля imp уже из «расшифрованной» текстовой строки. Как использовать данный класс? Очень легко. Буквально, одной строчкой включается возможность импортировать «зашифрованные» исходники нашей библиотеки, а по сути ставится хук на импорт:
где root_pkg_path абсолютный или относительный путь к корневому пакету нашей библиотеки. При этом, убирая данную строчку, мы можем использовать обычные исходники, если они доступны. Всё происходит абсолютно прозрачно, а все изменения происходят в одном месте.
Вот и всё, с этого момента импорт модулей из нашей библиотеки осуществляется с перехватом и «расшифровкой». Наш хук будет дёргаться при любом вызове инструкции import, и если импортируется модули нашей библиотеки, хук будет их обрабатывать и загружать, остальные импорты будут обрабатываться стандартно. Что нам и требовалось для более продвинутой обфускации. Представленный код импортёра и установки хука можно положить уже в *.pyd файл и надеяться на то, что никто не будет его дизассемблировать в надежде понять, что мы тут наворотили. В реальном проекте можно использовать настоящее шифрование, в том числе с использованием аппаратного ключа, что должно повысить надёжность данного метода. Также изменение имён файлов и структуры пакетов может быть полезным для большего запутывания.
Заключение
Возможно, что всё, что тут написано и яйца выеденного не стоит — давно известные истины, либо бред сумасшедшего. Но если вышеописанное кому-то может оказаться полезным, я буду рад. Лично для меня данный опыт был полезен, хотя бы потому, что позволил лучше разобраться в мощной и гибкой системе загрузки и импортирования модулей и Importer Protocol. О тех самых штуках, которые чаще всего не требуются разработчикам для написания программ на Python. Всегда интересно узнать что-то новое.
Спасибо за внимание.
UPD 14.08.2013:
По просьбе tangro сделал минимальный проект, в котором демонстрируется описанный способ, но без настоящего шифрования (применены только некие алгоритмы обратимого преобразования).
Скачать zip-архив можно по ссылке. Нужен Python 2.7 x86 под Windows. Запускать нужно скрипт «test_main.py».
UPD 2:
И более интересный пример, в котором производятся некоторые вычисления. Здесь все импорты и вызовы функций из зашифрованных модулей скрыты в бинарном модуле. Скачать архив можно по ссылке.
Безопасный ввод и сохранение зашифрованных паролей в конфигах Linux: пишем скрипт на Python
Как вывести свою систему на новый уровень безопасности с модулями python-gnupg и getpass4.
Изображение : freeGraphicToday, via Pixabay. CC0.
В условиях растущих требований к безопасности создание и хранение паролей может вызвать вопросы не только для пользователей, но и у разработчиков и системных администраторов. Специалисты и другие осведомлённые люди знают, что пароли нужно хранить в зашифрованном виде. Уже на этапе ввода символы пароля нужно скрывать от любых глаз (даже от того человека, который его вводит). Всегда ли мы можем выполнить хотя бы эти требования?
Я единственный пользователь своего ноутбука, а на его борту крутится ОС семейства Linux. Поэтому меня не беспокоят пользователи, которые могут случайно или неслучайно посмотреть мои конфигурационные файлы, работая на этом же компьютере. Я решил заморочиться и повысить безопасность своего личного ноутбука, и на то есть свои причины. Да, я шифрую свой домашний каталог, но как только вхожу в систему, любой пароль, хранящийся в виде простого текста в файле конфигурации, потенциально может быть уязвим для чересчур любопытных глаз.
К тому же, я использую почтовый клиент Mutt. Он позволяет мне читать и составлять электронные письма прямо в Linux-терминале. Мне удобно, мне нравится. Правда, ему нужно, чтобы я хранил пароль в файле конфигурации (.mutt), либо всё время вводил пароль в интерактивном режиме. Поэтому я ограничил права доступа к моему конфигурационному файлу Mutt, чтобы его мог видеть только я.
Но есть ещё один важный момент: я периодически пишу технические статьи, составляю туториалы, помогаю людям в сообществе и публикую много своего кода в общедоступных репозиториях, публикую скриншоты своего экрана, часто показываю что-то на примере своей рабочей системы. Если по недосмотру меня угораздит засветить в Интернете (или где-то ещё) данные (и в том числе пароли) из моих конфигурационных файлов, это бросит неприятную тень на мою репутацию и безопасность. Так что надо подстраховаться.
Ну и, если вдруг злоумышленник завладеет моим ноутбуком или каким-то другим образом получит доступ в систему, он не сможет получить мой пароль без боя, просто запустив cat для просмотра логов и конфигов.
Поиск решения задачи
Я решил, что лучший способ защитить мой пароль в Mutt — ввести пароль с клавиатуры, сохранить его в зашифрованном файле GPG, написать на Python скрипт расшифровки для моего GPG-пароля, ну и заодно обеспечить передачу пароля Mutt в скрипт offlineimap, который я использую для локальной синхронизации моего ноутбука с почтовым сервером.
Из подзаголовка статьи ясно, что я буду использовать модули python-gnupg и getpass. Модуль Python python-gnupg — это обёртка для инструмента шифрования gpg. Учтите, python-gnupg не следует путать с модулем под названием gnupg. GnuPG (GPG) — это утилита шифрования для Linux, и я использую её с 2009 года или около того. С ней я чувствую себя комфортно и верю в её безопасность.
Получить пользовательский ввод с помощью Python довольно просто. Вы вызываете input, и всё, что введёт пользователь сохраняется в переменной:
И в этом случае есть одна громадная проблема: когда я ввожу пароль в терминале, всё, что я набираю, видно всем, кто смотрит через моё плечо или просматривает историю моего терминала:
Написание скрипта с python-gnupg и getpass
Как это часто бывает, ничего самому писать не надо, потому что уже существует модуль Python, который позволяет решить проблему. Это модуль getpass4. С точки зрения пользователя он ведёт себя точно так же, как любое стандартное приглашение к вводу, за исключением того, что не отображает введённые символы.
Установим оба модуля с помощью pip:
У меня получился вот такой скрипт для создания пароля с невидимым вводом и расшифровкой:
Сохраните файл как password_prompt.py, если хотите попробовать скрипт у себя. Если вместе с ним вы хотите использовать offlineimap, укажите в конфигурационном файле .offlineimaprc имя и путь к скрипту с паролем (у меня это
/.mutt/password_prompt.py). Правда, там нужно сделать ещё кое-что, но об этом позже.
Тестирование скрипта с gpg
Надеюсь, у вас уже установлен gpg, так как сейчас мы будем создавать зашифрованный файл пароля и тестировать скрипт.
Запускаем созданный ранее скрипт:
Ура! При вводе ничего не отображается, но если вы правильно введёте пароль (нужно ввести hello world), на следующей строке вы увидите тестовое сообщение «hello world». Оно же и является паролем, полученным в результате расшифровки файла
/.mutt/pass.gpg. Значит, скрипт работает правильно.
Интеграция с offlineimap
Сначала добавьте строку, ссылающуюся на файл нашего скрипта:
Теперь вместо пароля в строке с remotepasseval после знака «=» вызовите функцию get_api_pass(), которая живёт в скрипте password_prompt.py:
Всё! Теперь никто не сможет прочитать пароль из вашего конфигурационного файла!
Безопасность даёт свободу
Иногда кажется, что у меня паранойя: я много думаю о тонкостях обеспечения безопасности на моём личном компьютере. Действительно ли SSH конфиг должен иметь разрешения chmod 600? Действительно ли имеет значение, что пароль электронной почты находится в конфигурационном файле, спрятанном в скрытой папке, которая называется, как ни странно, .mutt? Хотя написать подобный скрипт на Python можно и для других конфигурационных файлов.
Зная, что в моих файлах конфигурации отсутствуют незашифрованные конфиденциальные данные, мне намного проще публиковать файлы в общедоступных репозиториях Git, копировать и вставлять сниппеты на форумах и делиться своими знаниями в форме актуальных, рабочих файлов конфигурации. С этой точки зрения, повышение уровня безопасности облегчило мне жизнь. А с таким количеством Python-модулей на все случаи жизни, сделать это было достаточно легко.
Аренда облачного сервера с быстрыми NVMе-дисками и посуточной оплатой у хостинга Маклауд.