Итак ты являешься клиентом банка Авангард. У тебя должны быть:

• логин и пароль от интернет-банкинга;
• карточка с одноразовыми паролями;
• флэшка с ключом ЭЦП.

С первыми двумя пунктами всё просто: логин с паролем позволяют зайти в веб-интерфейс и получить любую информацию. Если требуется выполнить типовой платеж, то раз в сеанс будет запрошен одноразовый пароль с карточки. Самое интересное происходит в ситуации, когда требуется выполнить какое-либо действие, которое по законодательству требует твоей подписи. Например, хочется открыть вклад. Или поменять какой-нибудь лимит для карточки. Или перевести миллионы в другой банк. Казалось бы надо идти в офис и там писать заявление, но не всё так страшно: в нашей самой лучшей на свете стране есть закон об Электронных Цифровых Подписях и Авангард как раз одну такую ЭЦП с православным ГОСТовским криптоключем внутри тебе сгенерировал.

Но тут-то и кроется подстава: софт, конечно же, кривой. Ну как не то чтобы совсем уж, чего обижать авторов, но не без забавностей.

Для того, чтобы проверить работу цифровой подписи можно попробовать изменить какой-нибудь лимит на закладке “Справочники/Лимиты по картам”.

Во-первых, для работы ЭЦП требуется java-plugin. Не знаю, как там с icedtea (или как там оно зовется), хотя вроде где-то писали, что и он работает, но я не стал оригинальничать и поставил java-plugin от некогда славной фирмы SUN (пакет sun-java6-plugin).

И ничего не заработало. Честно сказать, я это заметил еще месяца полтора назад, что не работают у меня java-апплеты, но списал это на то, что где-то прописалась какая альтернативная джава из gcj или еще какого проекта, и забил. А тут занялся вопросом серьезно – сносил, переставлял… Ничего не помогает. Вместо апплета выдает окошко с надписью “Error. Click for detail”, по клику на которое вызывается java-console с текстом о Class not found и прочих эксепшнах, но главное с ключевой строчкой: “Caused by: java.net.ConnectException: Network is unreachable”

Небольшое расследование вывело на следующую проблему: #560238. Если коротко, то суть ее состоит в том, что Marco d’Itri добавил в пакет netbase установку sysctl’я ломающего некоторый “кривой” софт. Не будем сейчас обсуждать Марко и его маму, равно как кривость сановской джавы и информационность RFC 3493. Просто факт остается фактом. Сейчас сановская джава не сможет подключиться к сети при установленном net.ipv6.bindv6only=1

Так что первым нашим шагом будет открытие /etc/sysctl.d/bindv6only.conf и установку там net.ipv6.bindv6only в значение 0. После чего стоит сказать “/etc/init.d/procps start” Ну это всё пока что актуально только на Debian Squeeze, остальным повезло. (Пока?)

Теперь апплет-таки запускается и, если тебе особенно повезло, радостно сообщает: “Обнаружение программы… Err” с очень содержательным пояснением: “Ошибка обнаружения/скачивания программы шифрования: invalid stream header: 0D0A0D0A”

Тут всё просто и очевидно (да, это сарказм): открываешь настройки IceWeasel/FireFox и разрешаешь там “Third-party cookies”. Они там в разных версиях в по разному называются/находятся, так что проще всего открыть “about:config” и там поставить значение переменной network.cookie.cookieBehavior в 0. Кстати эта проблема, наверняка должна проявляться и под виндой.

Едем дальше: аппет сообщает “Ошибка выполнения программы подписи  : Cannot run program “c:\avn_ib/avn_cc.exe”: java.io.IOException: error=13, Permission denied”. Если посмотреть в домашний каталог пользователя (а именно он является текущим для java-приложений, запускаемых из браузера), то мы радостно обнаружим там каталог “c:\avn_ib” внутри которого действительно есть неисполняемый файл avn_cc.exe

Как ты уже догадался, гений русских программистов бесконечен. Java-апплет всего-лишь является троян-дропперомзагрузчиком для настоящей боевой криптографии. Которая написана, естественно под винду. Ну тут всё просто. Он хочет запускать этот бинарник? Нет проблем! Чтобы работали виндовые программы, ставим wine. Чтобы бинарник можно было запускать напрямую, ставим binfmt-support. (Вообще он рекомендуется вайном, но мало ли, у тебя он не стоит. Ну и в других дистрибутивах пакет может называться иначе, ты уж сам разберись, главное чтобы работал прямой запуск виндовых прог: не только “wine prog.exe”, но и просто “./prog.exe”) Дальше, понятно, надо сделать бинарник avn_cc.exe исполняемым.

Нет, это еще не всё. Теперь апплет выдает нам не менее экзистенциальное “Ошибка выполнения программы подписи: ret 2 команда <c:\avn_ib/avn_cc.exe c:\avn_ib/avn_clb_sign.in>” Надо немного подумать: чтобы бинарник можно было запустить из вайна, он должен быть доступен внутри виндового окружения. А какой путь сейчас у этого бинарника? Правильно Z:\home\user\c:\avn_ib\avn_cc.exe В общем не бывает таких путей в виндовсе. Решаем всё просто:

mv ~/c:\\avn_ib ~/.wine/drive_c/avn_ib&&ln -s ~/.wine/drive_c/avn_ib ~/c:\\avn_ib

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

Велик русский Левша. Умеет подковать англицкую джаву.

PS А Авангард и его интернет-банкинг действительно хорош. Ну и MasterCard.Metro у него по самым адекватным тарифам. В общем рекомендую. Кстати, обещают подружиться до конца года(?) с московским наземным транспортом и питерской подземкой.

Довольно любопытно. Оказывается, что Нокиевцы сами не ожидали, что N900 удастся (в такой степени), а сейчас они расходятся как пирожки. В России 4е место по прибыли (порядка 1500-2000шт в месяц), в мире 5е. Планы на 2009 Q4 были перевыполнены в два с лишним раза. При этом средний покупатель, оказывается, вовсе даже не гик (политкорректно маркетинговые люди их называют “тэкникал лидерз”), а человек, переросший E серию (не по статусу, а по потребностям). Хотя встречаются перебежчики с яблок и форточек.

Кстати Россия сейчас для Нокии “4й по величине рынок”. Не совсем понятно правда, в мире или в азиатском регионе, но всё равно.

Люди из Нокии потравили много интересных баек в коридоре. Они всерьез уверены, что за Маэмо будущее. При этом вроде бы настроены очень лицом к сообществу. Правда основная причина это “лучше я сейчас потрачу 30 тысяч, чтобы замейнлайнить наше изменение в апстрим, чем 3 лимона за поддержку всего этого самим в течении 5 лет”. Но всё равно это звучит весьма позитивно.

Насколько их планы на завоевание рынка кажутся реалистичными? Не знаю. Но они говорят очень много правильных вещей в том, что касается юзабилити (в более широком, чем юзабилити пользовательского интерфейса, смысе), возможностей, которые они требуют от платформы. Хочется надеяться, что прок будет. В общем, если и вправду N920 будет без клавиатуры, и если навител портирует под него свою навигацию, то я, пожалуй, куплю себе и то и другое. А пока FS n560. Хотя и исключительно в роли нафигатора.

SPIN is a general tool for verifying the correctness of distributed software models in a rigorous and mostly automated fashion. It was written by Gerard J. Holzmann and others in the original Unix group of the Computing Sciences Research Center at Bell Labs, beginning in 1980. The software has been available freely since 1991, and continues to evolve to keep pace with new developments in the field.

http://spinroot.com

Unfortunately Bell Labs use strange non-free copyleft-like license instead of good old GPL. So it could not be included in Debian archive. But as I need Debian package for it, I’ve prepared one and put into my repository.

В другом потоке:
dd if=/dev/zero of=/dev/sdc2 bs=1024 count=1024
mkfs.reiserfs /dev/sdc2

Вот я теперь думаю: я был не прав или всё-таки оно не должно было упасть?
Что ответит Александр ДрузьКО?

Редактирование истории в git

Более строго следует говорить не о "редактировании" или "изменении" истории,
а о cоздании "альтернативной" истории. Если специально ничего не предпринимать,
в репозитории git остаются все объекты "старой" истории, соответствующие
предыдущим коммитам и версиям файлов.
На эти объекты не будут "ссылаться" ветки, но если Вы вспомните их SHA1-ключи,
либо как-то специально позаботитесь их "пометить" (тэгом, или другой веткой),
то старая история будет c точки зрения git "ничем не хуже" новой.

Почти во всех командах git можно ссылаться на коммиты любым способом:
 - с помощью SHA1-ключа,
 - с помощью имени ветки (если это последний коммит на ветке),
 - с помощью тэга (если вы его предусмотрительно поставили git tag),
 - c помощью специальных имён, например HEAD - последний коммит на
   данной ветке, HEAD^ - предпоследний (точнее, первый предок
   последнего коммита) и т.п. Подробности см. git-rev-parse --help
Ниже в командах, которые допускают любую идентификацию коммита, я буду
указывать в качестве аргумента <id>, или <id-...>. Если допускается только
имя ветки, указывается <ветка>.

Для начинающих я рекомендую приступая к редактированию истории пометить
все ключевые точки тэгами. Их хорошо видно в gitk.
Только не забудьте их потом удалить git tag -d

В понятие истории git я буду включать не только совокупность коммитов
git-а, но и содержание рабочего каталога (да простят меня потомки).

Типовые задачи редактирования истории:

1. Отказаться от всех изменений в рабочем каталоге (аналог revert в svn).
   Кошерный способ: git checkout -f
   Отказаться от части изменений можно с помощью: git checkout <path>
   НО: git checkout . не удалит, например, вновь добавленных файлов.
   Более жёсткий способ удалить _все_ изменения: git reset --hard HEAD

2. "Сохранить" изменения (состояние) рабочего каталога.
   git stash
   При этом рабочий каталог "очищается" до HEAD, а сохранённые изменения
   можно в последствии "применить" к текущему, либо к любому другому
   состоянию рабочего каталога с помощью git stash apply
   В частности, это позволяет "переносить" изменения между ветками
   (хотя, лучше их оформлять как коммиты, и оперировать потом уже с ними).

3. Отредактировать/дополнить последний коммит:
   git commit --amend
   Можно применять даже если Вам просто понадобилось переписать commit-log
   (например, Вы его "недописали" или он оказался не в той кодировке).
   Фактически при выполнении этой операции будет создан _другой_ commit
   object, и HEAD ветки будет связан с ним. (Старый объект в репозитории
   git тоже сохранится).

4. "Отказаться" от нескольких последних коммитов в истории (в частности,
    от последнего)
   Создать новую ветку new в нужной нам точке истории и переставить на
   неё существующую:
   git checkout <id> -b new
   git branch -M <нужная нам ветка>
   Например, отказаться от последнего коммита на ветке master (если мы
   на нём находимся), можно так:
   git checkout HEAD^ -b new_master
   git branch -M master
   После первой команды мы находимся "на один коммит назад" и создали там
   новую ветку с именем new_master (текущей веткой является new_master).
   После второй команды мы "переименовали" new_master в master, -M позволяет
   проигнорировать, что master уже есть.
   Тоже самое можно сделать одной командой:
   git reset --hard <id>
   Но это менее безопасно (см. ниже).

5. "Переставить" метки веток.
   git reset [--ключ] <id>
   Позволяет "передвинуть" текущий HEAD (и метку ветки) на заданный коммит.
   Есть три варианта, задаваемых ключами:
    --hard - "выкидывает" всё текущее состояние рабочий копии, вы оказываетесь
             на коммите <id>, как будто после него ничего не было;
             Т.е. это просто "перестановка ветки".
    --soft - "сохраняет" изменения в рабочей копии (и в "индексе" git) и добавляет
             к ним изменения из "истории" от <id> до точки, из которой мы переходим.
             Более подробно см. п. "Слияние нескольких коммитов в один".
    --mixed - (по умолчанию) - ведёт себя как --soft, но не изменяет состояние
             "индекса" git (оно будет соответствовать коммиту <id>, на который мы
             перешли) - новые и изменённые файлы не считаются "добавленными" в индекс,
             т.е. в отличии от --soft для них требуется явно делать git add,
             git rm, .etc
   Поскольку git reset (особенно --hard), позволяет "потерять" последнее
   положение ветки (т.е. оставить HEAD "непомеченным"), следует использовать
   эту команду с осторожностью.

6. Слияние нескольких коммитов в один.
   Если это "последние" коммиты в истории этой ветки:
   git reset --soft <id>
   git commit -a -s [--amend]
   Первая команда позволяет "отскочить" HEAD на несколько коммитов назад, при
   этом сохранив все "изменения" этих коммитов в рабочем каталоге.
   Например, git reset --soft HEAD^^ позволит "объединить" изменения последнего
   и предпоследнего коммитов.
   Если мы хотим "добавить" к этим изменениям, изменения из коммитов с другой
   ветки, нам поможет git cherry-pick --no-commit <id>
   Эта команда "добавляет" изменения коммита в рабочий каталог и в индекс, но не
   выполняет операцию commit.

7. Удаление нескольких коммитов "внутри истории". git-rebase magic
   Например, у Вас есть история ветки:
    ...-(N-5)-(N-4)-(N-3)-(N-2)-(N-1)-(N) - ветка
   и вам захотелось удалить коммиты (N-4)-(N-2) включительно.
   Это можно сделать с помощью команды git-rebase:
   git-rebase --onto <ветка>~5 <ветка>~2 <ветка>
   Например, git-rebase --onto master~5 master~2 master
   Нотация <id>~<n> означает n-ый коммит назад, т.е. в данном случае:
    - master - (N)
    - master~2 - (N-2)
    - master~5 - (N-5)
   Смысл операции git-rebase --onto <id-newbase> <id-upstream> <id-head>:
    1) Переключиться на коммит <id-head> (== git checkout <ветка>, если
       <id-head> - это HEAD ветки)
    2) Начать новую ветку от точки <id-newbase>
    3) "Поместить" на новую ветку коммиты от <id-upstream> до <id-head>,
       не включая <id-upstream>
    4) Если <id-head> - это HEAD ветки, переставить <ветку> на то, что получилось
   В данном случае:
   От коммита (N-5) мы начинаем "применять" коммиты (N-1) и (N), и переставляем
   метку ветки, в результате чего получается "новая история":
        (N-1)'-(N)' - ветка
         /
   ...-(N-5)-(N-4)-(N-3)-(N-2)-(N-1)-(N)

8. Объединение коммита с "внутренним" коммитом в истории.
   Например, в коммите <id-src> Вы исправили ошибку в "старом исправлении" <id-dst>,
   которое было несколько коммитов назад.
   Последовательность действий:
   1) Создать новую ветку new_branch от коммита <id-dst>, который надо
      поменять (дополнить).
      git checkout <id-dst> -b new_branch
   2) Сделать cherry-pick коммита <id-src>, который вы хотите "приплюсовать" к
      внутреннему.
      git cherry-pick --no-commit <id-src>
   3) "Дополнить" последний коммит изменениями из рабочего каталога.
      git commit --amend
   4) Добавить в новую историю последовательность "правильных" коммитов:
      git rebase --onto HEAD <id-первый коммит>^  <id-последний коммит>
   5) Переставить ветку на новый HEAD
      git branch -f <имя ветки>

   Пояснения требуют два последних действия:
     git rebase в данном случае добавляет нужную последовательность коммитов
     "в голову" новой ветки, но если <id-последний коммит> - это не HEAD
     старой ветки, то после git rebase новый HEAD не будет соответствовать
     ни какой ветке ! (так уж работает git rebase)
     Для этого требуется последняя операция, она явно переставляет ветку
     на HEAD.

   Если наше исправление было бы не закоммичено, можно было воспользоваться
   git stash и git stash apply вместо git cherry-pick.

9. Редактирование "внутреннего" коммита.
   Действия аналогичны п.8, но проще. Пусть мы находимся на ветке <имя ветки>.
   1) Извлечь коммит <id-dst>, подлежащий редактированию; ветку new_branch
      создавать при этом не обязательно, но желательно:
      git checkout <id-dst> [-b new_branch]
   2) Исправить код, "дополнить" последний коммит изменениями из рабочего
      каталога.
      git commit -a --amend
   3) Добавить в новую историю последовательность "правильных" коммитов:
      git rebase --onto HEAD <id-dst> <имя ветки>
   4) Удалить ветку new_branch, если она была создана на шаге 1)
      git branch -D new_branch

   Специально переставлять ветку <имя ветки> в данном случае не требуется, т.к.
   в команде git rebase в п. 3) в качестве последнего аргумента было имя ветки,
   а не просто SHA1-id. В такой ситуации эта команда "автоматически" переставит
   ref ветки.

10. rebase ветки с помощью git rebase.
    git rebase <upstream-branch>
    Эта операция подробно рассмотрена в разъяснениях Никиты по идеологии и
    сценариям использования git.
    Не следует относится к git rebase "формально": например, если Вы считаете,
    что некоторые коммиты с ветки разумнее было бы переместить на master, можно
    "продублировать" их на master с помощью git cherry-pick, после чего сделать
    git rebase. После этого, с веки эти коммиты волшебным образом исчезнут.

11. "Откат" отдельного коммита.
    Строго говоря, это не редактирование истории: просто автоматически добавляется
    коммит (либо, изменение в рабочей копии), "отменяющее" заданный коммит.
    git revert [--no-commit] <id>
    Эту возможность следует использовать если Вы не хотите "честно" редактировать
    историю. Например, коммит надо откатить только на одной из ветвей, либо
    этот коммит был "очень давно", и не хочется перестраивать из-за него всю
    историю целиком.

(cc) Mike Chistolinov

Таки нет! Нам все эти годы врали! Английское Copyright обозначает только отчуждаемые авторские права. А к неотчуждаемым правам отношения не имеет.

А вы говорите, что изюм это сушеный виноград…

ЗЫ В моем репозитории в секции main лежат бэкпорты под все актуальные дистрибутивы Debian/Ubuntu.

Upd: Лицензия на второй файл cc-3.0-by-sa, на первый, скорее всего тоже, но надо еще уточнить, потому что я использовал за основу творчество Сэма Хосевара, напишу ему и спрошу.

Неочевидное тут вот что:
закрывать тикеты надо тогда, когда коммит попадает на master (такая у нас модель разработки), соответственно надо отлавливать мержи и в случае мержа просматривать смерженные коммиты.

Upd: Гит оказался умнее меня и сам (rev-list) выводит коммиты со смерженных веток. Поэтому всё намного проще и получившийся скрипт даже и не интересен ни разу.

Скрипт получился такой:

#!/bin/sh
# This script is run after receive-pack has accepted a pack and the
# repository has been updated.  It is passed arguments in through stdin
# in the form
#  oldrev newrev refname
# For example:
#  aa453216d1b3e49e7f6f98441fa56946ddcd6a20 68f7abf4e6f922807889f52bc043ecd31b79f814 refs/heads/master

TRAC_HOOK="/srv/git/hooks/trac-post-commit-hook"
TRAC_DIR="/srv/trac/stand"

procrevs() {
    while read gitrev; do
	"$TRAC_HOOK" -p "$TRAC_DIR" -r "$gitrev"
    done
}

while read OLD NEW NAME;do
	test "$NAME" == "refs/heads/master"||continue
	git rev-list --no-merges "$OLD..$NEW"|procrevs
done

Где TRAC_HOOK – это trac-post-commit-hook из дистрибутива trac, TRAC_DIR – каталог с проектом trac. В самом trac’е должен быть включен и настроен плагин trac-git.

Пингвины откладывают яйца? Галагтеко опасносте?

Мой новый ключ:

pub   2048R/2AAC33F1 2009-05-18
Отпечаток ключа = 04B5 9D90 DF7C C2AB CD49  BAEA CA87 E9E8 2AAC 33F1
uid                  Alexander GQ Gerasiov <gq@cs.msu.su>

Подробнее: gpg-transition-gq-2009-05-18.txt.

PS Если кто-то хочет обменяться подписями – можете отмечаться в комментах.

Хотя, с другой стороны, за такие деньги…

Почитал внимательнее minix3.org. Таненбаум, похоже, понял, что сказки про микроядро не интересны никому, кроме гиков. Теперь он упирает на BSD-лицензию и смотрит на проприетарные встроенные системы как целевую аудиторию.
В общем даже интересно. Где бы найти немножко времени, чтобы посмотреть на код…