Шурику отдельное спасибо, что просветил и посоветовал.

Доклад будет проходить на английском языке. После доклада планируется небольшая PGP key-signing party для интересующихся.

Место проведения: второй учебный корпус МГУ, аудитория П-13.
Время 18:00.

Слушатели не имеющие пропуска в здания МГУ должны предварительно записаться в список для прохода через охрану. Для этого необходимо послать письмо со своими ФИО (да-да, анонимность торжествует) на адрес gq@cs.msu.su. В subject имеет смысл написать слово Tor.

The Tor Project makes software used worldwide by a diverse set of people that is aimed at protecting people’s anonymity online. As the internet grows, more and more threats to people’s privacy grow with it, and Tor aims to minimize or remove those dangers.

This talk will give an overview of Tor’s architecture and design, its use as an anti-censorship and anti-surveillance tool, as well as discussing the basic concepts of privacy and anonymity on the Internet.

В наличии:

• Мегафон, который имеет на Северном Кавказе давнюю историю и приличное покрытие, но пока у него только 2G.
• Билайн, который ловится хуже, но к которому доверия больше. Да и 3G у него уже работает.

Как выяснилось, после посещения офисов, у Мегафона модем + 100 с  копейками рублей на счете стоит 1100 (или около того) и трафик продается пакетами (что-то вроде 700 рублей за гигабайт). В Билайне всё сильно радостнее: 500 рублей за 3G модем и 495 в месяц за “Лёгкий Безлимит”. Лёгкий он потому, что хватает его только на гигабайт в месяц, после чего скорость обрезают до 64кбит/сек. Правда за 120 рублей можно докупить еще гигабайт. Плюс сейчас еще идет акция: первые месяцы из каждого ежемесячного платежа возвращают 1/5 стоимости модема до полного погашения.

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

Выбор в общем-то очевиден: Билайн. Но не всё оказалось так просто…

Вроде всё установилось/подключилось, а нихрена не работает. Пинги не проходят, хотя DNS как-то худо-бедно резолвится. С моей симкой вроде что-то работает, но никакого 3G. На всякий случай позвонил в техподдержку, а то фиг их знает, как оно у них устроено. По крайней мере деньги списывают в полнось на следующие после активации сутки. Там мне сказали “сейчас я вам там обновила, попробуйте минут через 10-15″.

Минут через 10-15 попробовал – всё равно не работает (по крайней мере нормально). Долгими исследованиями было обнаружено, что небольшие пакеты проходят с вероятностью 10%, а вот максимальные 1500байт – очень хреново. Вначале долго искал как в винде для ppp ограничить mtu, не нашел, но спасся OpenVPN соединением с небольшим mtu. По крайней мере этим стало можно худо-бедно пользоваться, но на очень смешной скорости.

Долго При этом билайновская звонилка показывала уверенный прием: 4-5 палок из 6. Пробовал играться с другой симкой, с другим модемом (тем, который в телефоне) – результат плавает, но никакой закономерности нету. И тут случайно один из своих экспериментов провожу чуть ближе к окну, чем обычно… Уверенный пинг. При чем задержка всего 200мс, вместо обычных 3000. А билайновская звонилка умеет помимо всего прочего еще показывать текущий страндарт связи. Оказалось всё до предела банально: у окна ловился 3G. А на диване только EDGE.

Получается, что GPRS/EGDE у Билайна в Невинномысске просто не работает. А всякие UMTS/HSDPA/HSUPA вполне себе. И вполне пристойный получился интернет. Пока в Винде. С Линуксом всё несколько сложнее, но об этом в следующий раз.

Приятелю письмо из штатов ФедЭксом доставили за 4 дня. При чем с прохождением таможни в воскресенье.
Мне бандероль из ЮК приехала за 12 дней. Обычной почтой.

Или это случайное чудо?

Садись, малыш, сегодня я расскажу тебе как пользоваться интернет-банкингом Авангарда в Линуксе.

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

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

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

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

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

Во-первых, для работы ЭЦП требуется 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 у него по самым адекватным тарифам. В общем рекомендую. Кстати, обещают подружиться до конца года(?) с московским наземным транспортом и питерской подземкой.

ЗЫ Кстати о паранойе. Очень впечатлили дельцы, которые продают в Москве RFID-блокирующие обложки на “биометрические” паспорта по цене в 3т.р. Хорошо так люди деньги делают. (Купил на e-bay в 5 раз дешевле.)

ЗЫ Через 2 недели Бегущий Город. На этот раз команда будет полностью из ЛВК. Все 4 человека.

Довольно любопытно. Оказывается, что Нокиевцы сами не ожидали, что 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, на первый, скорее всего тоже, но надо еще уточнить, потому что я использовал за основу творчество Сэма Хосевара, напишу ему и спрошу.

#!/bin/sh

rm -f /etc/bind/mydns/db.*
echo -n > /etc/bind/named.conf.mydns

echo "select origin from dns_soa where active='Y';" | mysql --defaults-file=/etc/mysql/debian.cnf dbispconfig | while read DOMAIN;do
[ "$DOMAIN" = "origin" ]&&continue

mydnsexport "$DOMAIN" > /etc/bind/mydns/db."$DOMAIN"

XFER=$(echo "select xfer from dns_soa where origin=\"$DOMAIN\"" | mysql --defaults-file=/etc/mysql/debian.cnf dbispconfig | tail -n1|tr , \;| sed -e 's/;;/;/g' -e 's/^;$//')\;

echo "zone \"$DOMAIN\" { type master; allow-transfer { $XFER }; file \"/etc/bind/mydns/db.$DOMAIN\"; };" >> /etc/bind/named.conf.mydns

done

/etc/init.d/bind9 reload > /dev/null

где /etc/mysql/debian.cnf – это файл содержащий параметры доступа к mysql:

[client]
host     = localhost
user     = root
password = password
socket   = /var/run/mysqld/mysqld.sock

Правда, как оказалось, mydnsexport генерирует невалидный файл зоны, так что пришлось его слегка пропатчить:

diff -rNu mydns-1.2.8/src/lib/rr.c mydns-1.2.8.patched/src/lib/rr.c
--- mydns-1.2.8/src/lib/rr.c	2009-02-03 12:15:26.000000000 +0300
+++ mydns-1.2.8.patched/src/lib/rr.c	2009-09-27 05:00:26.000000000 +0400
@@ -866,6 +866,7 @@
 			     "%s%s%s"
 			     "%s%s"
 			     "%s%s"
+			     "%s"
 			     "%s",

 			     columns,
@@ -891,8 +892,9 @@
 			     (filter)? " AND " : "",
 			     (filter)? filter : "",

+			     " ORDER BY name,type",
 			     /* Optional sorting */
-			     (mydns_rr_use_stamp)? " ORDER BY stamp DESC" : "");
+			     (mydns_rr_use_stamp)? ",stamp DESC" : "");

   RELEASE(namequery);

Ну и вставить вызов скрипта в крон. Извращение, но работает.