«Русская Windows» прошла первый контроль

Лезу в удаленный сервер программой ssh, а она мне и говорит человеческим голосом —ssh_exchange_identification: Connection closed by remote hostОхуеть, думаю, приехали. Лезу в тот же сервер по IP, работает. Пробую снова хостнейм, работает. И что это было?

Теги: #линукс #партия #комсомол

Вчера Минкомсвязи утвердило прототип национальной программной платформы — операционной системы, которой суждено заменить Windows на компьютерах чиновников и школьников. Вместо эталонного дистрибутива НПП разработчик — «Пингвин софтвер» — предлагает сделать четыре, по одному от каждого из основных российских Linux-разработчиков
 

Вчера вечером заместитель министра связи и массовых коммуникаций Илья Массух подписал акт приемки прототипа национальной программной платформы (НПП). С помощью этой платформы чиновники рассчитывают со временем добиться экономии бюджетных средств, идущих на оплату лицензий на компьютерные программы. Сэкономить можно будет до 80% всех расходов, или 1,72 трлн руб. за несколько лет, говорится в презентации проекта, с которой ознакомились «Ведомости».

Впервые о разработке «русского аналога Windows» заговорили летом 2010 г. Чиновники решили не изобретать операционную систему (ОС) с нуля, а взять за основу, как это обычно делают во всем мире, дистрибутив свободно распространяемой операционной системы Linux с открытыми исходными кодами. Согласно принятой в октябре 2010 г. госпрограмме «Информационное сообщество» на 2011-2020 гг. в первые два года действия этой программы на разработку НПП планируется потратить 490 млн руб. Программа предусматривает, что уже через год после начала ее действия на национальную операционную платформу должно приходиться 2% всех установок на российских компьютерах — без учета органов госвласти и органов местного самоуправления, только за счет бюджетных учреждений и организаций. А еще через год — 5%.

Конкурс на создание прототипа НПП в конце сентября 2011 г. выиграла компания «Пингвин софтвер», принадлежащая фонду NGI, крупным пайщиком которого является бывший министр связи Леонид Рейман. Еще летом «Пингвин» поддержал обращение Российского некоммерческого партнерства содействия развитию свободного программного обеспечения (РАСПО), выступившего против условий этого конкурса: РАСПО не понравились короткие сроки на разработку прототипа и сама идея создания единственной версии НПП. Но это не помешало «Пингвину» и еще одному участнику РАСПО — ВНИИНС подать заявку на участие в конкурсе и выиграть его с предложением разработать прототип за 5 млн руб. при стартовой цене конкурса в 27 млн руб. Гендиректор «Пингвина» Дмитрий Комиссаров обещал привлечь к разработке НПП программистов ВНИИНС и других компаний, входящих в РАСПО.

Как и требовали сроки конкурса, «Пингвин» сдал документацию по прототипу в конце октября. А потом еще почти два месяца эту документацию государство принимало — за это время по условиям программы «Информационное сообщество» должен был пройти еще один конкурс — на разработку до конца 2011 г. эталонного дистрибутива НПП.

Прототип — это «сложный предмет», объясняет эксперт приемной комиссии Виталий Липатов, гендиректор питерского Linux-разработчика «Этерсофт». Это большой проект, в программе испытаний — 73 пункта и каждый — «не нажать кнопочку», рассказал «Ведомостям» Комиссаров. По его словам, испытания длились пять дней, из них три дня — в самом министерстве и еще два — в удаленном доступе. Член комиссии Липатов — архитектор конкурирующей Linux-системы Alt Linux, так что комиссия«не дала “Пингвину” спуску ни в чем», заверяет он. Липатов объясняет, что у него были замечания к методике испытаний прототипа, которую предложил сам же «Пингвин». Проект несколько раз рассматривался и возвращался на доработку, сказал на днях и министр связи Игорь Щеголев. Но на вчерашнем заседании комиссия признала, что «Пингвин» внес исправления по ряду замечаний, а другие признала несущественными, рад Комиссаров.

Одним из результатов создания прототипа НПП стала разработка техзадания для следующего конкурса по созданию самой платформы и «Пингвин» предложил вместо одного эталона взять за основу четыре основных российских дистрибутива — Alt Linux, «МСВСфера», «Наулинукс» и «Роса», рассказывает Комиссаров. «Пингвин» продемонстрировал версии этих дистрибутивов, совместимых между собой: программа для одного из них работает и в других. В результате должен появиться фонд алгоритмов и программ, совместимых для всех дистрибутивов, и оператор, который будет поддерживать этот фонд.

Массух вчера заявил «Ведомостям», что программы для НПП можно будет писать не только под Linux: министерства, ведомства и бюджетные организации будут активно арендовать программы через интернет с помощью облачных сервисов.

Суперкомпьютер из видеокарты: задействуем возможности GPU для ускорения софта

Сегодня новости об использовании графических процессоров для общих вычислений можно услышать на каждом углу. Такие слова, как CUDA, Stream и OpenCL, за каких-то два года стали чуть ли не самыми цитируемыми в айтишном интернете. Однако, что значат эти слова, и что несут стоящие за ними технологии, известно далеко не каждому. А для линуксоидов, привыкших "быть в пролете", так и вообще все это видится темным лесом. Предисловие В этой статье мы попытаемся разобраться, зачем нужна технология GPGPU (General-purpose graphics processing units, Графический процессор общего назначения) и все связанные с ней реализации от конкретных производителей. Узнаем, почему эта технология имеет очень узкую сферу применения, в которую подавляющее большинство софта не попадает в принципе, и конечно же, попытаемся извлечь из всего этого выгоду в виде существенных приростов производительности в таких задачах, как шифрование, подбор паролей, работа с мультимедиа и архивирование. Рождение GPGPU Мы все привыкли думать, что единственным компонентом компа, способным выполнять любой код, который ему прикажут, является центральный процессор. Долгое время почти все массовые ПК оснащались единственным процессором, который занимался всеми мыслимыми расчетами, включая код операционной системы, всего нашего софта и вирусов. Позже появились многоядерные процессоры и многопроцессорные системы, в которых таких компонентов было несколько. Это позволило машинам выполнять несколько задач одновременно, а общая (теоретическая) производительность системы поднялась ровно во столько раз, сколько ядер было установлено в машине. Однако оказалось, что производить и конструировать многоядерные процессоры слишком сложно и дорого. В каждом ядре приходилось размещать полноценный процессор сложной и запутанной x86-архитектуры, со своим (довольно объемным) кэшем, конвейером инструкций, блоками SSE, множеством блоков, выполняющих оптимизации и т.д. и т.п. Поэтому процесс наращивания количества ядер существенно затормозился, и белые университетские халаты, которым два или четыре ядра было явно мало, нашли способ задействовать для своих научных расчетов другие вычислительные мощности, которых было в достатке на видеокарте (в результате даже появился инструмент BrookGPU, эмулирующий дополнительный процессор с помощью вызовов функций DirectX и OpenGL). Графические процессоры, лишенные многих недостатков центрального процессора, оказались отличной и очень быстрой счетной машинкой, и совсем скоро к наработкам ученых умов начали присматриваться сами производители GPU (а nVidia так и вообще наняла большинство исследователей на работу). В результате появилась технология nVidia CUDA, определяющая интерфейс, с помощью которого стало возможным перенести вычисление сложных алгоритмов на плечи GPU без каких-либо костылей. Позже за ней последовала ATi (AMD) с собственным вариантом технологии под названием Close to Metal (ныне Stream), а совсем скоро появилась ставшая стандартом версия от Apple, получившая имя OpenCL. GPU — наше все? Несмотря на все преимущества, техника GPGPU имеет несколько проблем. Первая из них заключается в очень узкой сфере применения. GPU шагнули далеко вперед центрального процессора в плане наращивания вычислительной мощности и общего количества ядер (видеокарты несут на себе вычислительный блок, состоящий из более чем сотни ядер), однако такая высокая плотность достигается за счет максимального упрощения дизайна самого чипа. В сущности основная задача GPU сводится к математическим расчетам с помощью простых алгоритмов, получающих на вход не очень большие объемы предсказуемых данных. По этой причине ядра GPU имеют очень простой дизайн, мизерные объемы кэша и скромный набор инструкций, что в конечном счете и выливается в дешевизну их производства и возможность очень плотного размещения на чипе. GPU похожи на китайскую фабрику с тысячами рабочих. Какие-то простые вещи они делают достаточно хорошо (а главное — быстро и дешево), но если доверить им сборку самолета, то в результате получится максимум дельтаплан. Поэтому первое ограничение GPU — это ориентированность на быстрые математические расчеты, что ограничивает сферу применения графических процессоров помощью в работе мультимедийных приложений, а также любых программ, занимающихся сложной обработкой данных (например, архиваторов или систем шифрования, а также софтин, занимающихся флуоресцентной микроскопией, молекулярной динамикой, электростатикой и другими, малоинтересными для линуксоидов вещами). Вторая проблема GPGPU в том, что адаптировать для выполнения на GPU можно далеко не каждый алгоритм. Отдельно взятые ядра графического процессора довольно медлительны, и их мощь проявляется только при работе сообща. А это значит, что алгоритм будет настолько эффективным, насколько эффективно его сможет распараллелить программист. В большинстве случаев с такой работой может справиться только хороший математик, которых среди разработчиков софта совсем немного. И третье: графические процессоры работают с памятью, установленной на самой видеокарте, так что при каждом задействовании GPU будет происходить две дополнительных операции копирования: входные данные из оперативной памяти самого приложения и выходные данные из GRAM обратно в память приложения. Нетрудно догадаться, что это может свести на нет весь выигрыш во времени работы приложения (как и происходит в случае с инструментом FlacCL, который мы рассмотрим позже). Но и это еще не все. Несмотря на существование общепризнанного стандарта в лице OpenCL, многие программисты до сих пор предпочитают использовать привязанные к производителю реализации техники GPGPU. Особенно популярной оказалась CUDA, которая хоть и дает более гибкий интерфейс программирования (кстати, OpenCL в драйверах nVidia реализован поверх CUDA), но намертво привязывает приложение к видеокартам одного производителя. KGPU или ядро Linux, ускоренное GPU Исследователи из университета Юты разработали систему KGPU, позволяющую выполнять некоторые функции ядра Linux на графическом процессоре с помощью фреймворка CUDA. Для выполнения этой задачи используется модифицированное ядро Linux и специальный демон, который работает в пространстве пользователя, слушает запросы ядра и передает их драйверу видеокарты с помощью библиотеки CUDA. Интересно, что несмотря на существенный оверхед, который создает такая архитектура, авторам KGPU удалось создать реализацию алгоритма AES, который поднимает скорость шифрования файловой системы eCryptfs в 6 раз. Что есть сейчас? В силу своей молодости, а также благодаря описанным выше проблемам, GPGPU так и не стала по-настоящему распространенной технологией, однако полезный софт, использующий ее возможности, существует (хоть и в мизерном количестве). Одними из первых появились крэкеры различных хэшей, алгоритмы работы которых очень легко распараллелить. Также родились мультимедийные приложения, например, кодировщик FlacCL, позволяющий перекодировать звуковую дорожку в формат FLAC. Поддержкой GPGPU обзавелись и некоторые уже существовавшие ранее приложения, самым заметным из которых стал ImageMagick, который теперь умеет перекладывать часть своей работы на графический процессор с помощью OpenCL. Также есть проекты по переводу на CUDA/OpenCL (не любят юниксоиды ATi) архиваторов данных и других систем сжатия информации. Наиболее интересные из этих проектов мы рассмотрим в следующих разделах статьи, а пока попробуем разобраться с тем, что нам нужно для того, чтобы все это завелось и стабильно работало. GPU уже давно обогнали x86-процессоры в производительности Во-первых, понадобится видеокарта, поддерживающая технологию CUDA или Stream. Необязательно, чтобы она была топовая, достаточно только, чтобы год ее выпуска был не менее 2009. Полный список поддерживаемых видюшек можно посмотреть в Википедии: en.wikipedia.org/wiki/CUDA и en.wikipedia.org/wiki/AMD_Stream_Processor. Также о поддержке той или иной технологии можно узнать, прочитав документацию, хотя в большинстве случаев будет достаточным взглянуть на коробку из под видеокарты или ноутбука, обычно на нее наклеены различные рекламные стикеры. Во-вторых, в систему должны быть установлены последние проприетарные драйвера для видеокарты, они обеспечат поддержку как родных для карточки технологий GPGPU, так и открытого OpenCL. И в-третьих, так как пока дистрибутивостроители еще не начали распространять пакеты приложений с поддержкой GPGPU, нам придется собирать приложения самостоятельно, а для этого нужны официальные SDK от производителей: CUDA Toolkit или ATI Stream SDK. Они содержат в себе необходимые для сборки приложений заголовочные файлы и библиотеки. Ставим CUDA Toolkit Идем по вышеприведенной ссылке и скачиваем CUDA Toolkit для Linux (выбрать можно из нескольких версий, для дистрибутивов Fedora, RHEL, Ubuntu и SUSE, есть версии как для архитектуры x86, так и для x86_64). Кроме того, там же надо скачать комплекты драйверов для разработчиков (Developer Drivers for Linux, они идут первыми в списке). Запускаем инсталлятор SDK: $ sudo sh cudatoolkit_4.0.17_linux_64_ubuntu10.10.run Когда установка будет завершена, приступаем к установке драйверов. Для этого завершаем работу X-сервера: # sudo /etc/init.d/gdm stop Открываем консоль <Ctrl+Alt+F5> и запускаем инсталлятор драйверов: $ sudo sh devdriver_4.0_linux_64_270.41.19.run После окончания установки стартуем иксы: $ startx Чтобы приложения смогли работать с CUDA/OpenCL, прописываем путь до каталога с CUDA-библиотеками в переменную LD_LIBRARY_PATH: $ export LD_LIBRARY_PATH=/usr/local/cuda/lib64 Или, если ты установил 32-битную версию: $ export LD_LIBRARY_PATH=/usr/local/cuda/lib32 Также необходимо прописать путь до заголовочных файлов CUDA, чтобы компилятор их нашел на этапе сборки приложения: $ export C_INCLUDE_PATH=/usr/local/cuda/include Все, теперь можно приступить к сборке CUDA/OpenCL-софта. Ставим ATI Stream SDK Stream SDK не требует установки, поэтому скачанный с сайта AMD-архив можно просто распаковать в любой каталог (лучшим выбором будет /opt) и прописать путь до него во всю ту же переменную LD_LIBRARY_PATH: $ wget http://goo.gl/CNCNo $ sudo tar -xzf ~/AMD-APP-SDK-v2.4-lnx64.tgz -C /opt $ export LD_LIBRARY_PATH=/opt/AMD-APP-SDK-v2.4-lnx64/lib/x86_64/ $ export C_INCLUDE_PATH=/opt/AMD-APP-SDK-v2.4-lnx64/include/ Как и в случае с CUDA Toolkit, x86_64 необходимо заменить на x86 в 32-битных системах. Теперь переходим в корневой каталог и распаковываем архив icd-registration.tgz (это своего рода бесплатный лицензионный ключ): $ sudo tar -xzf /opt/AMD-APP-SDK-v2.4-lnx64/icd-registration.tgz -С / Проверяем правильность установки/работы пакета с помощью инструмента clinfo: $ /opt/AMD-APP-SDK-v2.4-lnx64/bin/x86_64/clinfo ImageMagick и OpenCL Поддержка OpenCL появилась в ImageMagick уже достаточно давно, однако по умолчанию она не активирована ни в одном дистрибутиве. Поэтому нам придется собрать IM самостоятельно из исходников. Ничего сложного в этом нет, все необходимое уже есть в SDK, поэтому сборка не потребует установки каких-то дополнительных библиотек от nVidia или AMD. Итак, скачиваем/распаковываем архив с исходниками: $ wget http://goo.gl/F6VYV $ tar -xjf ImageMagick-6.7.0-0.tar.bz2 $ cd ImageMagick-6.7.0-0 Далее устанавливаем инструменты сборки: $ sudo apt-get install build-essential Запускаем конфигуратор и грепаем его вывод на предмет поддержки OpenCL: $ LDFLAGS=-L$LD_LIBRARY_PATH ./confi gure | grep -e cl.h -e OpenCL Правильный результат работы команды должен выглядеть примерно так: checking CL/cl.h usability... yes checking CL/cl.h presence... yes checking for CL/cl.h... yes checking OpenCL/cl.h usability... no checking OpenCL/cl.h presence... no checking for OpenCL/cl.h... no checking for OpenCL library... -lOpenCL Словом "yes" должны быть отмечены либо первые три строки, либо вторые (или оба варианта сразу). Если это не так, значит, скорее всего, была неправильно инициализирована переменная C_INCLUDE_PATH. Если же словом "no" отмечена последняя строка, значит, дело в переменной LD_LIBRARY_PATH. Если все окей, запускаем процесс сборки/установки: $ sudo make install clean Проверяем, что ImageMagick действительно был скомпилирован с поддержкой OpenCL: $ /usr/local/bin/convert -version | grep Features Features: OpenMP OpenCL Теперь измерим полученный выигрыш в скорости. Разработчики ImageMagick рекомендуют использовать для этого фильтр convolve: $ time /usr/bin/convert image.jpg -convolve '-1, -1, -1, -1, 9, -1, -1, -1, -1' image2.jpg $ time /usr/local/bin/convert image.jpg -convolve '-1, -1, -1, -1, 9, -1, -1, -1, -1' image2.jpg Некоторые другие операции, такие как ресайз, теперь тоже должны работать значительно быстрее, однако надеяться на то, что ImageMagick начнет обрабатывать графику с бешеной скоростью, не стоит. Пока еще очень малая часть пакета оптимизирована с помощью OpenCL. FlacCL (Flacuda) FlacCL — это кодировщик звуковых файлов в формат FLAC, задействующий в своей работе возможности OpenCL. Он входит в состав пакета CUETools для Windows, но благодаря mono может быть использован и в Linux. Для получения архива с кодировщиком выполняем следующую команду: $ mkdir flaccl && cd flaccl $ wget www.cuetools.net/install/flaccl03.rar Далее устанавливаем unrar, mono и распаковываем архив: $ sudo apt-get install unrar mono $ unrar x fl accl03.rar Чтобы программа смогла найти библиотеку OpenCL, делаем символическую ссылку: $ ln -s $LD_LIBRARY_PATH/libOpenCL.so libopencl.so Теперь запускаем кодировщик: $ mono CUETools.FLACCL.cmd.exe music.wav Если на экран будет выведено сообщение об ошибке "Error: Requested compile size is bigger than the required workgroup size of 32", значит, у нас в системе слишком слабенькая видеокарта, и количество задействованных ядер следует сократить до указанного числа с помощью флага ‘--group-size XX’, где XX — нужное количество ядер. Сразу скажу, из-за долгого времени инициализации OpenCL заметный выигрыш можно получить только на достаточно длинных дорожках. Короткие звуковые файлы FlacCL обрабатывает почти с той же скоростью, что и его традиционная версия. oclHashcat или брутфорс по-быстрому Как я уже говорил, одними из первых поддержку GPGPU в свои продукты добавили разработчики различных крэкеров и систем брутфорса паролей. Для них новая технология стала настоящим святым граалем, который позволил с легкостью перенести от природы легко распараллеливаемый код на плечи быстрых GPU-процессоров. Поэтому неудивительно, что сейчас существуют десятки самых разных реализаций подобных программ. Но в этой статье я расскажу только об одной из них — oclHashcat. oclHashcat — это ломалка, которая умеет подбирать пароли по их хэшу с экстремально высокой скоростью, задействуя при этом мощности GPU с помощью OpenCL. Если верить замерам, опубликованным на сайте проекта, скорость подбора MD5-паролей на nVidia GTX580 составляет до 15800 млн комбинаций в секунду, благодаря чему oclHashcat способен найти средний по сложности восьмисимвольный пароль за какие-то 9 минут. Программа поддерживает OpenCL и CUDA, алгоритмы MD5, md5($pass.$salt), md5(md5($pass)), vBulletin < v3.8.5, SHA1, sha1($pass.$salt), хэши MySQL, MD4, NTLM, Domain Cached Credentials, SHA256, поддерживает распределенный подбор паролей с задействованием мощности нескольких машин. Автор не раскрывает исходники (что, в общем-то, логично), но у программы есть нормально работающая Linux-версия, которую можно получить на официальной страничке. Далее следует распаковать архив: $ 7z x oclHashcat-0.25.7z $ cd oclHashcat-0.25 И запустить программу (воспользуемся пробным списком хэшей и пробным словарем): $ ./oclHashcat64.bin example.hash ?l?l?l?l example.dict oclHashcat откроет текст пользовательского соглашения, с которым следует согласиться, набрав "YES". После этого начнется процесс перебора, прогресс которого можно узнать по нажатию <s>. Чтобы приостановить процесс, кнопаем <p>, для возобновления — <r>. Также можно использовать прямой перебор (например, от aaaaaaaa до zzzzzzzz): $ ./oclHashcat64.bin hash.txt ?l?l?l?l ?l?l?l?l И различные модификации словаря и метода прямого перебора, а также их комбинации (об этом можно прочитать в файле docs/examples.txt). В моем случае скорость перебора всего словаря составила 11 минут, тогда как прямой перебор (от aaaaaaaa до zzzzzzzz) длился около 40 минут. В среднем скорость работы GPU (чип RV710) составила 88,3 млн/с. Выводы Несмотря на множество самых разных ограничений и сложность разработки софта, GPGPU — будущее высокопроизводительных настольных компов. Но самое главное — использовать возможности этой технологии можно прямо сейчас, и это касается не только Windows-машин, но и Linux. Info Суть технологии GPGPU — произвольные вычисления на видеокартах. Существует OpenCL SDK, разрабатываемый компанией Intel, но пока с его помощью можно запускать приложения только на классическом CPU. FASTRA II — суперкомпьютер, построенный с использованием 13 видеокарт, мощностью 12TFLOPS. Links bzip2-cuda.github.com — реализация архиватора bzip2с использованием CUDA. www.hoopoe-cloud.com — облачный сервис, позволяющий загружать и запускать софт с поддержкой CUDA и OpenCL.

Взломаны Linux Foundation и Linux.com

Вслед за взломом kernel.org, обнаружен факт взлома инфраструктуры сайтов linuxfoundation.org и социальной сети Linux.com. Подробности взлома пока выясняются. В доступном в настоящее время тексте уведомления указано на то, что предположительно, происшествие связано с атакой на kernel.org.

Все серверы организации Linux Foundation отсоединены от всемирной сети до завершения полной переустановки систем. Инфраструктура Linux Foundation включает в себя большое количество сервисов, таких как Linux.com, Open Printing, Linux Mark, сайты мероприятий и конференций Linux Foundation.

С большой долей вероятности взлом мог привести к утечке базы данных пользователей, включая SSH-ключи, email-адреса и пароли. Всем пользователям Linux.com и других сервисов Linux Foundation, использующим один и тот же пароль на нескольких сайтах, рекомендуется срочно поменять пароли на других ресурсах.

Источник

Безопасное хранение паролей из песочницы

Интернет прочно вошёл в нашу жизнь. Все мы, даже совсем неблизкие к IT люди, пользуемся большим количеством самых разнообразных сервисов, начиная от почты и заканчивая социальными сетями. Практически все сервисы требуют регистрации. Но для обеспечения безопасности использовать нужно разные пароли, состоящие из многих символов. Ну большинство людей, пользующихся интернетом, знают о требованиях к безопасным паролям. Но тут возникает одна небольшая проблема: как запомнить все эти множества паролей?

Недавно я и задался таким вопросом. Потерять, например, аккаунт от почты для меня было бы очень трагично. Записывать пароли в файл? Появляется риск подарить все свои аккаунты разом. Записывать на бумажку? Риск потерять бумажку и как следствие все пароли сразу. Плюс я задумался о доступности своих паролей в любом месте земного шара. И тут я вспомнил о своём любимом редакторе emacs. А в частности об Org-mode и EasyPG в emacs. Описывать как работать в org-mode я не буду, это сделали до меня (ссылки: Введение в Org-mode; Руководство по Org-mode).

Так в чём же заключается хитрость? А всё элементарно. Вместо файла filename.org, необходимо создать файл filename.org.gpg. Emacs автоматически откроет файл в Org-mode. Затем записать в этот файл пароль, лучше воспользоваться генератором паролей (я, например, использую однострочник на bash:

$cat /dev/urandom | head -1 | tr -d -c 'a-zA-Z0-9[]!@#$%^&*()'|fold -w 25| head -1

), и, конечно, не забыть написать от чего пароль и логин. А потом просто сохранить файл. Emacs сам предложит варианты действий: использовать ключ для ассиметричного шифрования или нажать OK для симметричного шифрования с вводом пароля. Здесь уже на выбор пользователя, но я предпочитаю использовать симметричное, потому что одним из требований являлся доступ к файлу не только с домашнего компьютера, а таскать с собой приватный ключ мне не очень нравится.

Но тут появляется новая проблема: нужно помнить пароль от зашифрованного файла. И опять же использовать простой пароль для данного файла мы просто не имеем права. Слишком большая вероятность его потерять, особенно если постоянно носить с собой на флешке копию этого файла. И опять мы сталкиваемся с проблемой запоминания данного пароля. Но есть выход. Если мы не можем запомнить пароль, то нужно сделать так, чтобы мы могли этот пароль восстановить. А делается это просто: мы берём отрывок из любой книги, например, один абзац. Помещаем этот отрывок в текстовый файл. file.txt. И считаем MD5 или SHA1 данного файла.

$ echo "любой отрывок текста из любой книги" > file.txt
$ md5sum file.txt | fold -10 | head -1
95584f1920
$ rm file.txt

В результате мы получаем надёжно зашифрованный текстовый файл с надёжными паролями. Можно скопировать данный файл на флешку и носить с собой или скопировать на удалённую машину к которой есть доступ из сети, что обеспечит доступность паролей в любой точке мира. А при забывчивости мы всегда сможем восстановить пароль от этого файла затратив небольшие усилия. Плюс ещё в том, что емакс кроссплатформенный. А даже при отсутствии оного, файлы .org представляют из себя plaintext, благодаря чему мы можем расшифровать файл утилитами gpg и открыть файл любым текстовым редактором. И напоследок, данным способом можно хранить любую приватную информацию.

Конечно, я не говорю, что этот способ единственен и правилен. Но для меня этот способ оказался очень удобен. Надеюсь он пригодится не только мне. Берегите свои пароли. ;^)