ОМСКАЯ ГРУППА ПОЛЬЗОВАТЕЛЕЙ LINUX http://omsklug.com Свобода - это ответственность. Вот почему все её так боятся. Бернард Шоу Sun, 14 Aug 2016 06:01:51 +0000 en hourly 1 http://wordpress.org/?v=3.2.1 Crypto Install Fest 3 в Омске http://omsklug.com/2016/08/crypto-install-fest-3/ http://omsklug.com/2016/08/crypto-install-fest-3/#comments Wed, 10 Aug 2016 17:46:25 +0000 linuxmasterz http://omsklug.com/?p=2016 Когда и где?

2016-08-20T14:00+0600 OMST (двадцатого августа 2016 года в 14 часов дня по омскому времени) Омская группа пользователей Linux (#OmskLUG) проводит Crypto Install Fest (#CIF2016) в Омском ITLoft (г. Омск, ул. Учебная, 83, второй этаж, каб. 212).

Что будем делать и обсуждать в ходе мероприятия?

А будет несколько докладов и мастерклассов по защите вашей, никому не нужной, личной и иной информации:

  1. Личная кибербезопасность для самых маленьких (Станислав Емец)
  2. Безопасность в интернете
  3. Шифрование дома и на работе: LUKS, TrueCrypt (VeraCrypt и др.) (Алексей Тараканов)
  4. Проблемы хранения паролей (Антон Пацев)

После чего, с 16.00 часов будет трансляция с московского Crypto Install Fest (http://cif.pirate-party.ru/) с возможностью задать вопросы докладчикам.

Также будет криптовечеринка (#KSP, Key Signing Party). Что такое KSP? Вот: https://db.tt/86bW7biW

Для мастер-классов и других жестоких беспощадных экспериментов по созданию загрузочных и шифрованных разделов/флешек нужны от вас:

(a) ноутбук и/или (b) флешка.

Для участия в частной криптовечеринке для избранных:

(a) неплохо бы направить ваш публичный ключ PGP заранее на post@omsklug.com;
(b) не забыть документ, удостоверяющий личность;
(c) прийти самому лично.

Если желаете поучаствовать в качестве организаторов, то оставляйте комментарии на сайте http://www.omsklug.com , пишите на почту post@omsklug.com, забегайте в нашу jabber-конференцию: omsklug@conference.jabber.ru

Как безвозмедно и добровольно зарегистрироваться для участия?

Вот ссылка на форму регистрации:http://bit.ly/cif2016omsk

Если же проникнуть лично вам не удастся, то есть вариант посмотреть трансляцию мероприятия тут: http://www.omsklug.com/tv

]]>
http://omsklug.com/2016/08/crypto-install-fest-3/feed/ 1
Document Freedom Day 2016 в Омске http://omsklug.com/2016/03/document-freedom-day-2016/ http://omsklug.com/2016/03/document-freedom-day-2016/#comments Mon, 28 Mar 2016 18:07:32 +0000 linuxmasterz http://omsklug.com/?p=2011 Free Software Foundation Europe e.V.

Free Software Foundation Europe e.V.

Когда и где?

2016-04-02T11:00+0600 OMST (второго апреля 2016 года в 11 часов утра по омскому времени) Омская группа пользователей Linux (#OmskLUG) проводит День свободы форматов данных (Document Freedom Day, #DFD2016) в молодёжном пространстве #ДачаОнегина (г. Омск, ул. Красный Путь д.11, Омская государственная областная научная библиотека им. А.С.Пушкина).

Зачем всё это?

С 2008 года ежегодно во всем мире в последнюю среду марта проводится День свободы форматов данных (http://documentfreedom.org/). В 2016 году – это 28 марта (мы же перенесли на субботу, 2 апреля). Это мероприятие направлено на повышение информированности общества об открытых стандартах и форматах и какой вред несёт закрытость форматов, спецификаций, протоколов. В Омске это мероприятие проводится уже несколько лет подряд. Вот ссылка на Википедию для очень любопытных: https://ru.wikipedia.org/wiki/День_свободы_форматов_данных

Что будем делать и обсуждать в ходе мероприятия?

Несколько докладов о свободных форматах данных в кругу единомышленников…

… и возможно что-то ещё, следите за нашими новостями.

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

В ходе мероприятия, так и после него, будет “криптовечеринка” (KSP, Key Signing Party): приносите свои отпечатки публичных ключей  (а лучше отправьте их координатору на post@omsklug.com) и какой-нибудь документ, который удостоверяет, что вы есть вы. Что такое KSP? Вот: https://db.tt/86bW7biW

Если желаете поучаствовать в качестве организаторов, то оставляйте комментарии на сайте http://www.omsklug.com , пишите на почту post@omsklug.com, забегайте в нашу jabber-конференцию: omsklug@conference.jabber.ru

Как безвозмедно и добровольно зарегистрироваться для участия?

Вот ссылка на форму регистрации:

https://bit.ly/dfd2016omsk

Если же проникнуть лично вам не удастся, то есть вариант посмотреть трансляцию мероприятия тут: http://www.omsklug.com/tv

]]>
http://omsklug.com/2016/03/document-freedom-day-2016/feed/ 1
Нам нравится Profanity! http://omsklug.com/2016/03/we-like-profanity/ http://omsklug.com/2016/03/we-like-profanity/#comments Wed, 02 Mar 2016 19:20:35 +0000 Shroom http://omsklug.com/?p=1988 .local p {text-align: justify!important; text-justify: inter-word!important;} .local a {color: rgb(16, 8, 96)!important;} .local a:visited {color: Gray!important;} .local a:hover {text-decoration: underline; color: Blue!important;} .local pre {overflow-x:auto;} .local code {font-family: Monospace,Courier!important;} .local code > span.kw { color: #268BD2; font-weight: bold; } .local code > span.dt { color: #268BD2; } .local code > span.dv { color: #D33682; } .local code > span.bn { color: #D33682; } .local code > span.fl { color: #D33682; } .local code > span.ch { color: #4070a0; } .local code > span.st { color: #2AA198; } .local code > span.co { color: #93A1A1; font-style: italic; } .local code > span.ot { color: #A57800; } .local code > span.al { color: #CB4B16; font-weight: bold; } .local code > span.fu { color: #268BD2; } .local code > span.er { color: #D30102; font-weight: bold; }
profanity project logo

Правда. :) Даже несмотря на наличие под катом ненормативной лексики. Так что, если вам нет 18 лет или если инвективная лексика является основной причиной ваших нравственных страданий, добро пожаловать в основной раздел нашего сайта. Если же вам интересны некоторые пикантные подробности наших счастлвых отношений с программкой из сабжа, тогда идёмте дальше…

По OmskLUG прокатилось поветрие сборки и/или установки консольного xmpp-клиента profanity. Может быть, это следствие его специфической суровой консольной кавайности, может быть, омсклуговцы просто устали от навороченного минимализма mcabber’а… А может быть, он на самом деле лучший из всех консольных джаббер-клиентов на сегодняшний день. И сегодня я не буду, как обычно это делал, скучно и долго рассказывать, как протанцевать по граблям сборки, установки и настройки очередного несговорчивого софта. Лучше я, как говорят в этих ваших интернетах, «просто оставлю это здесь»…

Собери Profanity!

(По щелчку на миниатюре загрузится оригинал)

“build profanity” banner in russian

И то же самое по-английски:

“build profanity” banner in english

На сегодня всё.


Спасибо за внимание!


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

]]>
http://omsklug.com/2016/03/we-like-profanity/feed/ 0
Омские линуксоиды участвуют в Городском IT-турнире по игре “Что?Где?Когда?” http://omsklug.com/2015/11/omsk-it-quiz/ http://omsklug.com/2015/11/omsk-it-quiz/#comments Fri, 13 Nov 2015 10:28:23 +0000 linuxmasterz http://omsklug.com/?p=1977 Городской IT-турнир по игре "Что?Где?Когда?"Омские линуксоиды участвуют в Городском IT-турнире по игре “Что?Где?Когда?” 11 декабря в 18.30 в офисе компании “Тамтэк” (Жукова, 21, 8 этаж).
“Что? Где? Когда?” – популярная интеллектуальная игра, в которой команда из 6 знатоков ищут правильный ответ на вопрос в течение одной минуты. Эта игра, в которую в нашем городе играют школьники и студенты, профессионалы и любители.

Приходите поболеть! Между прочим хороший повод увидится. Участвуют шесть наших участников, но мы всегда ждём людей для скамейки запасных, конец года же. Хех… Вот только хрустальную сову нам поставить некуда ^__^

Анонс турнира: https://vk.com/it_turnir

]]>
http://omsklug.com/2015/11/omsk-it-quiz/feed/ 0
Быстрый способ поворота видео с помощью avconv http://omsklug.com/2015/11/video-rotation-avconv/ http://omsklug.com/2015/11/video-rotation-avconv/#comments Sat, 07 Nov 2015 16:54:58 +0000 linuxmasterz http://omsklug.com/?p=1971 Intro

Всем известно, что частенько кое-кто снимает видео странно: повернув смартфон или планшет вертикально. Или ещё как нетрадиционно. Вот с этим мы и будем бороться.

Prerequisitives

Устанавливаем форк ffmpeg (Почему? Да потому, что у меня Ubuntu 14.04):

sudo apt-get install libav-tools

Script

Можно сделать полноценный скрипт или пользоваться однострочником BASH:

for i in *.3gp; do avconv -i "$i" -c:v h264 -c:a aac \
-strict experimental -vf "transpose=1" "encoded/$i"; done

Параметр vf – применимые фильтры к видео.

Фильтр transpose может иметь вот такие значения:

  • 0 – 90° CCW и Vertical Flip (по умолчанию)
  • 1 – 90° CW
  • 2 – 90° CCW
  • 3 – 90° CW и Vertical Flip

Параметр c:v – кодек видео.

Параметр c:a – кодек аудио.

Посмотреть какие кодеки доступны для использования:

avconv -codecs

Посмотреть  какие кодеки используются в обрабатываемых файлах:

avconv -i <имяфайла>

Epilogue

Вот таким нехитрым способом можно занять компьютер полезной деятельностью по перевороту видео. Ваши предложения, улучшения – в комменты.

]]>
http://omsklug.com/2015/11/video-rotation-avconv/feed/ 0
Косяки с установкой redmine_git_hosting в Debian 8 Jessie http://omsklug.com/2015/09/smashing-redmine-git-hosting-in-deian-jessie/ http://omsklug.com/2015/09/smashing-redmine-git-hosting-in-deian-jessie/#comments Tue, 29 Sep 2015 18:19:26 +0000 Shroom http://omsklug.com/?p=1954 .local p {text-align: justify!important; text-justify: inter-word!important;} .local a {color: rgb(16, 8, 96)!important;} .local a:visited {color: Gray!important;} .local a:hover {text-decoration: underline; color: Blue!important;} .local pre {overflow-x:auto;} .local code {font-family: Monospace,Courier!important;} .local code > span.kw { color: #268BD2; font-weight: bold; } .local code > span.dt { color: #268BD2; } .local code > span.dv { color: #D33682; } .local code > span.bn { color: #D33682; } .local code > span.fl { color: #D33682; } .local code > span.ch { color: #4070a0; } .local code > span.st { color: #2AA198; } .local code > span.co { color: #93A1A1; font-style: italic; } .local code > span.ot { color: #A57800; } .local code > span.al { color: #CB4B16; font-weight: bold; } .local code > span.fu { color: #268BD2; } .local code > span.er { color: #D30102; font-weight: bold; }
Icon for application-x-ruby MIME type

До меня время от времени доходили слухи, что установка и сопровождение Redmine — это не то, чтобы адЪ, но как минимум геморрой неслабые головняки. Вероятно, я подогнался под эту тему и в первый раз установка заняла у меня дня три. Во второй раз я уложился в пару дней. В последнее время я делаю успехи, поскольку установка плагина redmine_git_hosting прошла не более, чем за сутки. И это не может не радовать. Последовательность шагов по установке очень подробно описана в руководстве от разрабов, которое можно найти здесь: Get started. Собственно, именно такого порядка действий я и буду придерживаться в статье. Вследствие этого изложенный здесь материал может показаться фрагментарным и несколько несвязным. И если вам так и кажется, вы, пожалуй, правы…

Да, кстати. По этому тексту раскидана туева хуча полезных ссылок. Посему настоятельно рекомендую хотя бы мельком заглядывать в каждую из них по мере прочтения, иначе удовольствие будет казаться неполным.

Начало: клонирование и сборка

На всякий пожарный инструкция предупреждает нас о необходимости сбэкапить базу и остановить Redmine. Благоразумно воспользуемся этим советом и приступим…

Как ни странно, в самом начале процесс идёт на удивление гладко. Шаги по установке зависимостей и клонированию реп проходят без проблем. :)

Однако, как только дело доходит до bundle install, он тут же начинает орать. Во-первых, выдаёт предупреждение о дубликате зависимости «gem 'redcarpet', '~> 3.1.2'». Это не страшно, убирается комментированием соответствующей строчки в Gemfile внутри каталога плагина. Во-вторых, ошибка, связанная с несоответствием версий rake. Дескать, установлена 1.5.2, а плагин через зависимость от gitlab-grack требует аж 1.6.0. Это вызвано тем, что в репе jbox-web не указана версия rake; соотвественно, bundler вытягивает и собирает самую последнюю. Собственно, сам автор плагина предлагает бороться с этим косяком, используя гитлабовский форк. В результате получаем такой кусок Gemfile:

## Redmine 3.x
## Ruby/Rack Git Smart-HTTP Server Handler (use our own repository because Redmine uses Rails 4.2 and Rack 1.6)
#gem 'gitlab-grack', git: 'https://github.com/jbox-web/grack.git', require: 'grack', branch: 'fix_rails4'
#gem 'redcarpet', '~> 3.1.2'

# fix for Debian Jessie with rails 4.1
# (https://github.com/jbox-web/redmine_git_hosting/issues/497#issuecomment-133768646)
gem 'gitlab-grack', git: 'https://github.com/gitlabhq/grack.git', require: 'grack', branch: 'master'

После этих манипуляций все гемы собираются, как надо.

Следующй шаг — migrate

Здесь сразу же вылетает ошибка «The git source https: github.com/jbox-web/gitolite-rugged.git is not yet checked out. Please run bundle install before trying to start your application». Естественно, bundle install не помогает. Решение: закомментировать ссылки на git и поставить просто зависимость, как от обычных гемов. В результате получим что-то подобное:

# Gitolite Admin repository management
#gem 'gitolite-rugged', git: 'https://github.com/jbox-web/gitolite-rugged.git', tag: '1.1.1'
gem 'gitolite-rugged'

#gem 'gitlab-grack', git: 'https://github.com/gitlabhq/grack.git', require: 'grack', branch: 'master'
gem 'gitlab-grack', require: 'grack'

Кстати, в Интернете можно найти довольно много вопросов, связанных именно с таким глюком, когда какой-нибудь гем ставится из гита. ИЧСХ, внятных ответов, как бороться с этой напастью, никто не даёт. В основном какие-то шаманские рецепты типа придуманного мной. Это намекает на пару возможных причин: или эта ситуация настолько тривиальна, что отвечать просто нет смысла, или же действительно никто не знает, что там на самом деле происходит в недрах RoR вообще и Redmine в частности.

Ну так вот. После этого нужно ещё раз запустить bundle install, после чего migrate будет ругаться на другие вещи. Или, если redmine изначально был поставлен по-человечески, всё пройдёт гладко. В моём случае пользователю БД не хватало прав на создание и удаление таблиц. Выполнение в mysql

grant all privileges on `redmine_db`.* to 'redmine_user'@'localhost';
flush privileges;

решило проблему радикально.

Установка и настройка Gitolite

Пользователи и ключи

Поскольку Gitolite работает от одного пользователя через ssh, нам нужно сгенерировать некоторое количество ключей. Этот процесс вызвал единственный вопрос относительно места их хранения. В инструкции для создания пары административных ключей для плагина рекомендовано создать каталог ssh_keys в REDMINE_ROOT. Однако, если внимательно посмотреть на init.rb, становится понятно, что в дереве плагина уже есть ssh_keys, и создан он там отнюдь не случайно. Плагин в первую очередь именно там и ищет ключи. Впрочем, когда всё заработает, каталог с ключами можно переопределить в настройках.

Во время установки Gitolite нужно будет указать пользователя, из-под которого он будет работать (и в которого будут логиниться все имеющие доступ к репозиториям). Для общности пусть это будет юзер git. В качестве административного ключа нужно указывать открытый ключ того человека, который будет админом (ну или сразу ключ, сгенерированный для redmine). Дополнительные ключи (для redmine, в частности) кладутся в GITOLITE_HOME/.gitolite/conf/gitolite.conf. После этого нужно сделать gitolite compile от пользователя git. Но на самом деле ничего такого делать не нужно. Gitolite управляется через git-репу. Поэтому после установки с добавлением одного административного ключа можно и даже нужно просто склонировать репозиторий gitolite-admin тому пользователю, которого сделали git-админом. После этого можно настраивать конфиги как угодно, не забывая заливать коммиты обратно. Как и что делать, подробно разжёвано в соответствующем руководстве.

Дополнительно (для версии Gitolite 3) «патчится» пара скриптов, но это описывать не имеет смысла, поскольку процесс тривиален.

Если что-то пошло не так…

Но вот если забыть, как работает ssh, возникнут некоторые сложности с доступом по ключам. Во-первых, домашний каталог Gitolite должен принадлежать руту или тому юзеру, из-под которого работает Gitolite (и мы в самом начале решили, что это git). Следствие: если с репозиториями работает ещё кто-то (например, gitdaemon), этого кого-то нужно добавить в группу git. С другой стороны, что касается gitdaemon‘а, то его-то как раз можно запустить от имени любого нужного пользователя. Во-вторых, нужно выставить адекватные права на .ssh и то, что в нём. В-третьих, Gitolite различает git-юзеров по их ключам, поддерживая соответствующую структуру файла authorized_keys: перед ключом должна идти строчка

command="/usr/share/gitolite3/gitolite-shell <git_user_name>",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty

Если выполнены все эти условия, с доступом проблем не будет. В крайнем случае поможет анализ /var/log/auth.log. Вообще на сайте Gitolite есть специальная страница, где собраны все возможные косяки с ssh и способы их устранения. Опять же, если не лазить в конфиги руками, а делать всё через git, как расписано в документации, всё должно работать адекватно.

Что же там всё-таки с именами?

Кстати, есть ещё один нюанс, связанный с тем, как Gitolite определяет имена пользователей. Всё очень просто: как обзовёшь открытый ключ, так тебя и будут звать дальше. Опять же, всё не настолько фатально, если вспомнить, что вся конфигурация хранится в git-репозитории. Однако же, вот такая штука. Руководство по установке плагина предлагает назвать сгенерированный ключ каким-то нечеловечески длинным именем с суффиксом rsa_id. И это означает, что административный пользователь redmine будет назван этим самым непроизносимым именем. В сущности, и redmine, и плагину, и Gitolite — всем пофиг, формально всё будет работать. Однако, мне лично удобнее, когда подконтрольные мне сущности называются просто и понятно. Поэтому я переобозвал ключи в redmine-admin и redmine-admin.pub. И теперь в конфиге всё прозрачно и тихо.

Запуск Redmine и настройка плагина через веб-морду

Наконец-то, наконец-то! Если вы дошли до этого торжественного момента с минимальными потерями, вас можно поздравить. Остальных, наверное, тоже можно. Просто им уже не до поздравлений.

В общем, выполнение заключительной части инструкции особых сложностей не вызывает. Тем более, что есть целая страница с описанием тех параметров, которые нам предлагают настроить. Более того, там уже практически ничего не поломаешь, и можно, если что, исследовать систему методом научного тыка. С минимальным знанием английского или французского языков (других локализаций в этом плагине я не заметил) вполне реально разобраться даже без документации. Однако, в документации обычно пишут много интересного и полезного. :) Так что хотя бы краем глаза взглянуть всё же сто́ит.

Реальные баги

Так или иначе все ошибки, связанные с софтом, суть ошибки в коде. И если во время установки и настройки это относится к генетическому коду того, кто настраивает, то во время работы самой программы уже ничего не попишешь: мы сталкиваемся с реальными багами.

Вывод ReadMe

Итак, первый косяк в коде, с которым я столкнулся в процессе эксплуатации плагина, находится в файле REDMINE_HOME/plugins/redmine_git_hosting/lib/redmine_git_hosting/hooks/display_repository_readme.rb. Не буду рассказывать, как я его отлавливал и локализовал в конце концов, поскольку дебаггинг — это тема для отдельной статьи. Лучше сразу покажу, что нужно менять:

diff old/display_repository_readme.rb new/display_repository_readme.rb
58c58
<           raw_readme_text = repository.cat(readme_file.path, rev)
---
>           raw_readme_text = Redmine::CodesetUtil.to_utf8_by_setting(repository.cat(readme_file.path, rev))

А теперь поясню, ради чего, собственно, менять. Этот модуль должен выводить ReadMe под списком файлов и логом коммитов. Практически как на гитхабе. Однако же, без принудительного перевода прочитанного буфера в UTF-8 этот модуль падает на символах с кодами, выходящими за пределы таблицы ASCII. А внешне это выражается в том, что если в репе есть ReadMe с какими-то нестандартными символами (типа диакритики или расширенной пунктуации), то вместо репы мы увидим шиш с маслом Server Error 500. Это некрасиво да и вообще как-то неправильно. Поэтому вот такой нехитрый патч. Сделал pull request с этим «патчем»; будем ждать, когда окажется в апстриме. Upd[2015-10-02]:патч принят в основной репозиторий.

Дополнительно нужно отметить, что для отображения ReadMe в формате ReStructuredText требуется установка python-docutils. Да, именно. Это питоновский пакет, который нужен программе на ruby. Так тоже бывает.

Вывод новостей

В процессе работы был выявлен ещё один косяк, характерный именно для этой версии redmine. В случае, когда у пользователя выставлен признак «Отображать комментарии в обратном хронологическом порядке», при попытке просмотреть отдельную новость (вне зависимости от проекта и наличия комментариев) сервер выдавал Error 500. После анализа логов, мониторинга базы и изучения исходников удалось обнаружить ошибку в REDMINE_HOME/app/controllers/news_controller.rb. Косяк выпрямляется вот таким вот незатейливым способом:

diff old/news_controller.rb new/news_controller.rb
61c61
<     @comments = @news.comments
---
>     @comments = @news.comments.to_a

Кстати, как оказалось впоследствиии, в транке redmine этот баг был пофиксен в ревизии 13595 абсолютно так же.

Автоматическая подгрузка изменений

Собственно, это не то, чтобы баг… Скорее глюк. В общем, я заметил, что репы, переведённые в Redmine на Gitolite, не подхватывали автоматом изменения, сделанные снаружи, хотя соответствующая настройка в конфигурации была включена. В результате оперативно был воплощён в жизнь такой рецепт.

Чтобы redmine могла автоматически отслеживать изменения в репозиториях, в GITOLITE_HOME/.gitolite/hooks/common/post-receive.d нужно добавить скрипт, вызывающий метод fetch_changeset либо через WebAPI, либо напрямую через запуск redmine. Например, такой:

#!/bin/bash

API_KEY=XXXXXXXXXXXXXXXXX

PROJECT_ID=`git config redminegitolite.projectid || echo ''`

[ "${PROJECT_ID}" ] && {
    wget "https://<redmine.server.name>/sys/fetch_changesets?id=${PROJECT_ID}&key=${API_KEY}" >&/dev/null
    echo Redmine repository updated successfully
}

exit 0

Естественно, для доступа через веб должна быть включена соответствующая опция в настройках и получен ключик. Это делается в пару кликов на странице «Administration → Settings» на вкладке «Repositories».

Собственно, на этом всё.


Спасибо за внимание!


И как обычно, текст этой статьи в формате PDF можно совершенно свободно скачать вот по этой ссылке

]]>
http://omsklug.com/2015/09/smashing-redmine-git-hosting-in-deian-jessie/feed/ 0
Криптография с использованием ключей SSH http://omsklug.com/2015/09/ssh-crypto-pgp-for-poors/ http://omsklug.com/2015/09/ssh-crypto-pgp-for-poors/#comments Sun, 20 Sep 2015 16:18:42 +0000 Shroom http://omsklug.com/?p=1932 .local p {text-align: justify!important; text-justify: inter-word!important;} .local a {color: rgb(16, 8, 96)!important;} .local a:visited {color: Gray!important;} .local a:hover {text-decoration: underline; color: Blue!important;} .local code {font-family: Monospace,Courier!important;}

…или «PGP для бедных»

Внезапно за последнюю неделю у меня родилась вторая статья, имеющая отношение к криптографии и защите данных. Это несколько странно для меня, но вот поди ж ты, растащило на скрипты. Но если в прошлый раз речь шла о защите LUKS-разделов, то сейчас я вкратце расскажу, как можно что-нибудь зашифровать для конкретного человека, используя его открытый ключ ssh.

История вопроса

Итак, давным-давно, кажется в прошлую пятницу… Хотя нет. На самом деле в начале мая этого года… Так вот, именно в то время Родригес задался вопросом, можно ли в рамках концепции криптографии с открытым ключом использовать для шифрования ключи ssh. Они же по умолчаню есть практически всегда, чего не скажешь, например, о PGP/GnuPG. И, как оказалось, это возможно! В общем, академический интерес Родригеса был удовлетворён почти сразу же, а вот у меня до практческой реализации идеи руки дошли только сейчас.

Впрочем, для того, чтобы что-то зашифровать и подписать, ssh будет маловато: в любом случае нужно будет поставить дополнительно хотя бы openssl. Не будем спрашивать, почему бы не поставить GnuPG, раз уж в любом случае нужно что-то ставить. Лучше предположим, что шифровать будет какой-нибудь бездомный (в смысле, без ~ и с nologin) робот в автоматическом режиме, и специально для него генерить связку pgp-ключей будет, наверное, слишком жирно. Так что пусть удовлетворяется тем, что есть.

В чём суть

Так чем же удовлетворить себя несчастному одинокому роботу, если GnuPG не стоит, а шифровать хочется? Ответ очевиден: OpenSSL! Более конкретно — модуль rsautl, который позволяет шифровать небольшие клочки данных (в зависимости от типа пэддинга максимум будет составлять 214, 245 или 256 байтов) открытым RSA-ключом. Не нужно быть семи пядей во лбу, чтобы понять, что даже максмальные 256 байтов не пойдут ни в борщ, ни в красную армию. По той простой причине, что их слишком мало. Тем более, что та же openssl enc умеет шифровать симметричными алгоритмами, коих знает туеву хучу, практически ничем не ограниченные тонны информации. Так в чём же фишка?

Фишка, собственно, в асимметричности RSA. То есть, в данном случае не нужно никому передавать по защищённому каналу секрет для расшифровки. В наличии меется открытый ключ, который используется для шифрования и может быть известен неограниченному кругу лиц, а адресат расшифрует файл своим секретным закрытым ключом. Вернее, всё не совсем так. Даже совсем не так. Во-первых, открытым ключом никто сами данные шифровать не будет. Во-вторых, шифровать симметричным алгоритмом всё равно придётся. «Нувыпонели, да?» Это я сейчас пересказываю принцип работы PGP. В общем, те, кто понял, могут переходить прямо к следующему разделу, а всем остальным я предлагаю раскрыть тайну PGP.

А тут на самом деле всё просто. Берём байт 200 какого-нибудь случайного мусора, например, из /dev/random и говорим, что это наш «одноразовый сессионный ключ». Одноразовый, потому что он действительно будет использован только один раз, в данном конкретном случае. При этом его на самом деле никто не знает. То есть, он нигде не светится. Так вот. Берём этот ключ и шифруем на нём всё, что нам нужно. После этого начинается немного магии. Мы берём открытый ключ адресата и на нём шифруем сессионный ключ. Voilá! После этого можно подшить зашифрованный сессионный ключ к зашифрованным данным и отправлять это всё по любым каналам связи: всё равно никто ничего расшфровать не сможет.

На приёмной стороне происходит нечто подобное, но в обратном направлении. Сначала берём закрытый ключ адресата и расшифровываем им сессионный ключ. А после этого естественным образом сессионным ключом расшифровываем данные. Собственно, всё… Вся магия куда-то испарилась, как обычно… Ну а дабы окончательно разогнать остатки мистического огненного тумана, ниже даны команды для осуществления подобного безобразия дома. Для определённости условимся, что данные, подлежащие закрытию, находятся в файле data, сессионный ключ — в файле skey (да, да, я знаю, что так делать нельзя и всё такое, но это просто общая схема, в настоящем скрипте «всё по-другому»), а цифровая подпись — в файле signature. Также будем считать, что открытый ключ записан в файле rsa_key.pub, а закрытый — rsa_key.priv.

# Encryption:
openssl [здесь любимый алгоритм шифрования] -pass file:skey -in data -out data.encrypted
openssl rsautl -encrypt -pubin -inkey rsa_key.pub -in skey -out skey.encrypted
# Decryption
openssl rsautl -decrypt -inkey rsa_key.priv -in skey.encrypted -out skey
openssl [здесь любимый алгоритм шифрования] -d -pass file:skey -in data.encrypted -out data

Если хочется ещё и добавить цифровую подпись, это можно сделать таким образом:

openssl [здесь любмый хзш] -sign [ЗАКРЫТЫЙ ключ ОТПРАВИТЕЛЯ] -out signature -binary data

Проверять, соответственно, так:

openssl [здесь любмый хзш] -verify [ОТКРЫТЫЙ ключ ОТПРАВИТЕЛЯ] -signature signature data

Кстати, обратите внимание на то, что для шифрования используются ключи адресата, а для подписи — отправителя.

Собственно, скрипт

Реализация указанной идеи с помощью костылей shell и openssl повлекла за собой некоторое количество ограничений, о которых необходимо сказать сразу же. Из самого названия модуля rsautl легко можно сделать вывод, что использоваться будут только RSA-ключи. Это не самый удобный вариант, поскольку ssh-keygen умеет генерить не только RSA, но и DSA, а также ключи на основе эллиптических кривых, как, например, ECDSA и ED25519. И этот факт нужно учитывать, если всё-таки захочется шифровать файлы столь извращённым способом. В отношении подписи ограничения не столь суровы: не поддержвается только ED25519.

А собственно скрипт находится в репе на гитхабе. Ничего сверхъестественного, всё достаточно прозрачно и понятно. Если что-то всё-таки непонятно, можно запустить эту штуку с ключом --help, почитать ReadMe или, в конце концов, заглянуть в исходный код. Собственно, ради этого он и находится в свободном доступе.

Всем спасибо, все свободны!


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

]]>
http://omsklug.com/2015/09/ssh-crypto-pgp-for-poors/feed/ 0
LUKS Header Backup Helper http://omsklug.com/2015/09/luks-header-backup-helper/ http://omsklug.com/2015/09/luks-header-backup-helper/#comments Sun, 13 Sep 2015 18:02:20 +0000 Shroom http://omsklug.com/?p=1908 .local p {text-align: justify!important; text-justify: inter-word!important;} .local a {color: rgb(16, 8, 96)!important;} .local a:visited {color: Gray!important;} .local a:hover {text-decoration: underline; color: Blue!important;} .local code {font-family: Monospace,Courier!important;}
Связка ключей

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

Потеря — это всегда боль…

Потеря данных — не исключение. И неважно на самом деле, были ли эти данные рабочими базами с боевых серверов или же мегатоннами порнухи семейными фотографиями и личной перепиской. Важно то, что данные, которые не были сознательно удалены хозяином, обязаны оставаться доступными. А иногда даже и те, которые были удалены…

Особенно это касается систем хранения данных с шифрованием разделов. Просто потому, что зашифрованные данные особенно уязвимы к ошибкам. Да, безусловно, некоторые алгоритмы позволяют восстановить поток после сбойного блока. Но этот блок в любом случае будет безвозвратно потерян. И особенно это страшно, если речь идёт об ошибках в области заголовков LUKS. Ведь если ошибка появилась в том месте, где размещены слоты для ключей, это в контексте восстановленя данных практически равносильно низкоуровневому форматированию. Да, это очень удобно, когда срочно необходимо избавиться от информации. А когда эта самая информация, зашифрованная криптостойким алгоритмом с 256-битным ключом, позарез нужна для работы крупного предприятия? Что же делать в таких случаях?

Выход есть!

Во-первых, без паники! Если вы используете любое ПО для резервного копирования данных, в худшем случае вы потеряете время на развёртывании копии системы. Не имеет значения, bacula ли это будет, backuppc или голый rsync. Главное, что важные данные, которые требуются ежедневно, будут сохранены в надёжном месте. Безусловно, на другой машине. Желательно в другом здании. Ещё лучше — в другой стране в надёжном дата-центре.

«Но как же,» — спросите вы, — «это связано с LUKS?» Собственно, напрямую. Поскольку cryptsetup умеет делать бэкапы LUKS-заголовков и, соответственно, восстанавливать их. И что самое важное, восстановление заголовка из бэкапа может спасти диск даже в том случае, когда заголовок был просто полностью забит мусором из /dev/random. Да-да! Я лично проверял. Всё работает. Кстати, в связи с этим возникает некая идея «уничтожения» данных с последующим их «волшебным восстановлением»… Ну там если «маски-шоу»… Или если подзаработать захотелось… Гм… Впрочем, ближе к делу. Итак, вот они — две волшебные команды, которые спасут ваши данные/время/деньги/задницупрочие причиндалы.

Сделать бэкап LUKS-заголовка:

cryptsetup luksHeaderBackup <LUKS_DEVICE> --header-backup-file <header_file_name>

Восстановить LUKS-заголовок из бэкапа:

cryptsetup luksHeaderRestore <LUKS_DEVICE> --header-backup-file <header_file_name>

Да, есть ещё одна дополнительная возможность, которая считается весьма опасной. И правильно, в сущности, считается. Потому что это не что иное, как создание мастер-ключа. Удобно, на самом деле: можно на одном мастер-ключе наклепать шифрованных разделов и не бояться забыть пароли. Да вообще пароли можно не знать: нагенерить их автоматически из /dev/random и поскидывать на флэшки, которые вставлять по мере надобности при загрузке. В случае чего мастер-ключ позволит расшифровать раздел, даже без знания обычных ключей. Однако, очевидно, что это палка о двух концах: посеял файлик с мастер-ключом, и все соответствующие разделы можно считать скомпрометированными. Ну либо мёртвыми. И неизвестно ещё, что хуже. Кстати, вот команда для сдампливания мастер-ключа:

cryptsetup luksDump --dump-master-key <LUKS_DEVICE>

Да, вот так просто можно подарить кому-то все свои заботливо зашифрованные данные.

Ну так, собственно, к чему это я всё? К тому, что следующим логичным шагом в деле защиты данных будет

Автоматизация

Собственно, отсюда и начинается та самая реклама, про которую был соответствующий тэг.

Итак… [барабанная дробь] Встречайте! Скрипты для автоматического создания бэкапа заголовков LUKS и мастер-ключа! А на…зачем, собственно, нужны какие-то там непонятные скрипты, если всё делается буквально в полторы-две команды? Отличный вопрос!

  • Во-первых, теперь даже не нужно набирать эти полторы команды, достаточно одной.
  • Во-вторых, для файлов заголовка и мастер-ключа подсчитываются контрольные суммы по нескольким алгоритмам.
  • В-третьих, всё это добро архивируется и шифруется.
  • В-четвёртых, к шифрованному архиву по мере возможностей добавляются тома для восстановления. Чтобы в случае, если флэшку с бэкапом пробьёт шальной протон с высокой энергией, и банк в 128 кБ окажется мёртвым, то была бы возможность откачать этот архиив. А то кому нужен супер-пупер защищённый, вусмерть зашифрованный, но при этом битый бэкап, который невозможно восстановить?

Подробно работу со скриптами описывать не буду, поскольку всё есть в Readme. Однако, на всякий случай отмечу, что кроме coreutils и cryptsetup, скриптам для работы понадобится ещё и xxd. А если хочется ещё и создать тома для восстановления архива, то нужно будет поставить par2. Больше никаких сложностей возникнуть не должно.

Так что, если кто хочет дополнительно обезопасить свои данные и себя, заходите в репу на гитхабе (по ссылке выше).


P.S.: Этот пост посвящается памяти всех данных, безвозвратно утерянных вследствие обстоятельств непреодолимой силы или просто пользовательского/админского раздолбайства (что по сути одно и то же).

]]>
http://omsklug.com/2015/09/luks-header-backup-helper/feed/ 0
День свободы программного обеспечения 2015 http://omsklug.com/2015/08/sfd2015/ http://omsklug.com/2015/08/sfd2015/#comments Sun, 30 Aug 2015 17:21:05 +0000 linuxmasterz http://omsklug.com/?p=1883 Software Freedom Day LogoЧто такое?

День свободы программного обеспечения (Software Freedom Day, SFD, День СПО) — ежегодное всемирное мероприятие, посвященное свободному программному обеспечению и ПО с открытым исходным кодом. День свободы программного обеспечения — публичная образовательная инициатива, нацеленная на повышение уровня осведомленности о свободном программном обеспечении и его преимуществах, информирование о последних технологиях и тенденциях в свободном программном обеспечении.

Идея Дня свободы программного обеспечения пояилась в 2004 году и первый раз такой день был проведен 28 августа того же года. В Омске он проводится с 2007 г. обычно группой пользователей Linux.

Что там будет?

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

Когда и где?

2015-09-19T15:00+0600 OMST (19 сентября 2015 года в три часа дня после обеда по омскому времени) в #Омском ITLoft (г. Омск, ул. Учебная, 83, второй этаж, каб. 212).

Ссылка на карту в OSM: http://www.openstreetmap.org/?mlat=54.97682&mlon=73.39135#map=19/54.97682/73.39135

Ссылка на карту в 2GIS: http://go.2gis.com/a0j12

Регистрация и что взять с собой?

Вы можете пройти добровольную регистрацию и ответить на небольшой опрос тут:

http://bit.ly/sfd2015omsk

- это позволит нам сделать мероприятие ещё интереснее.

С собой желательно взять тапочки, чтобы не ходить босиком по полу с ковролином. Можно взять свой ноутбук, компьютер, если вы всегда хотели свободное ПО, но стеснялись делать это сами.

Трансляция и контакты:

Если не сможете прийти, будет трансляция в Интернет всего действа вот тут: http://www.omsklug.com/tv. Если вы желаете активно участвовать, рассказать о своей истории успеха в свободном ПО пишите на post@omsklug.com или заходите в jabber-конференцию: omsklug@conference.jabber.ru

До встречи на SFD2015!

]]>
http://omsklug.com/2015/08/sfd2015/feed/ 1
Омские линуксоиды на Омском городском пикнике 2015 http://omsklug.com/2015/08/linux-at-omsk-local-picnic-3/ http://omsklug.com/2015/08/linux-at-omsk-local-picnic-3/#comments Tue, 11 Aug 2015 17:34:42 +0000 linuxmasterz http://omsklug.com/?p=1872 Омский городской пикник— это первый городской праздник организованный горожанами, без администраций, организаций и корпораций, который включает в себя: живой концерт лучших омских групп, десятки выставок, перфомансов, аттракционов, игры, лекции и кино под открытым небом.

И все это омичи делают сами для себя. Теперь на Омском городском пикнике целая секция информационных компьютерных технологий, в том числе и наша. Поэтому приглашаем всех на нашу замечательную площадку на Омском городском пикнике!

Дата проведения: 2015-08-16

Место проведения: г. Омск, парк по проспекту академика Королёва, д. 20 (остановка общественного транспорта УчХоз)

Что же интересного у нас будет:

  1. Трансляция, раздача свободной музыки (jamendo.com и др.)
  2. Трансляция свободного видео (Elephant Dream, Big Buck Bunny, Sintel, Tears of Steel и др.)
  3. Различные интерактивы (“Погладь кота, Карл!”, “Гадание по USB” и др.)
  4. Безвозмездная раздача свободного программного обеспечения, музыки, видео
  5. Консультации, как использовать свободное программное обеспечение, как правильно лицензировать свободные произведения
  6. Безбашенная криптовечеринка (PGP)

Для участия в криптовечеринке:

(a) неплохо бы направить ваш публичный ключ PGP заранее на электропочту: post@omsklug.com;
(b) не забыть документ, удостоверяющий личность, желательно подлинный (например, один из ваших паспортов);
(c) прийти самому лично.

]]>
http://omsklug.com/2015/08/linux-at-omsk-local-picnic-3/feed/ 1