Евгений Бодунов mOlind

Привет, Хабр! Сегодня я расскажу вам страшную историю.

Однажды утром, открыв почтовый ящик, я увидел два письма схожего содержания: "На вас поступила жалоба о нарушении торговой марки". Первое было от юридического отдела Apple, второе от робота из Google. Но давайте обо всем по порядку.

Во время разработки большого проекта наступает такой момент, когда надо встроить в приложение библиотеку из мира open source с подходящей лицензией. Например, вам захотелось ускорить декодирование картинок, или понадобился sqlite3 с fts4, или нужны какие-то плюшки из libicu, которых нету в системной libicucore.

Для этого библиотеку, которая понадобилась, нужно будет собрать для 5 архитектур: armv7, armv7s, arm64, i386, x86_64. С кросскомпиляцией есть много подводных камней, на которые не хотелось бы наткнуться, когда есть уже проверенные решения. В этом коротком посте я расскажу об автоматизации сборки библиотек на примере protobuf и sqlite3.

После моего предыдущего поста о bcache, мне посоветовали использовать более быстрый btier. Через некоторое время появилась возможность попробовать его в боевых условиях. Этот пост будет о сравнении двух разных подоходов к ускорению работы жестких дисков…

С четверга Apple Developer Center был закрыт для проведения каких-то работ. Разработчики гадали что случилось, выходит ли это новая бета iOS или плановые работы. И чем больше времени с момента закрытия проходило, тем больше догадок возникало по этому поводу. Обычно такие работы завершаются за несколько часов.

Сегодня утром разработчикам, зарегистрированным в Developer Center, пришло письмо следующего содержания:

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

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

Для работы мы используем postgresql + postgis базу данных с данными для всей планеты от osm.org. На диске она занимает около 350 Gb и работает не быстро, да и хранится на обычном винчестере 2Tb 7200rpm, без RAID-a. Т.к. нагрузка на базу данных постепенно растет, было решено ускорить дисковую подсистему, потратив при этом минимум денег. Вариантов было не много:

• купить еще один такой же винчестер и объединить их в raid-0.
• купить небольшой SSD и организовать на нем быстрый кэш:
  
  • dm-cache. Был добавлен в ядро 3.9, ставится просто.
  • bcache. Судя по обзорам самый быстрый. Основной минус — надо форматировать диски перед началом использования. Официально добавлен в ядро 3.10, распространяется как пропатченое ядро 3.9.
  • EnhanceIO. В обзорах я встретил упоминание его, как самого медленного, но простого в использовании.

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

Во время недавней оптимизации запросов в базу данных наткнулся на описание работы SQLite с rowid. Если вкратце: в каждой таблице есть int64 столбец rowid, значение которого является уникальным для каждой записи в таблице. Посмотреть значение можно по имени «rowid» и в запросе * оно не показывается.

Записи хранятся как B-дерево по rowid. И это делает очень быстрым поиск и выборку по rowid. В два раза быстрее чем по primary key или по индексированному полю. Как я понял, поиск по индексированному столбцу — это поиск по B-дереву, в результате которого мы находим rowid. И уже имея rowid — ищем нужную запись.

Напрашивается очевидный вопрос: как сделать чтобы rowid и наш PRIMARY KEY совпадали?

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

Что было плохо?

• Было недостаточно проверок на соответствие чека и данных в SKTransaction.
• Было недостаточно проверок ответа сервера.

Описанный ниже метод защиты был взломан, читайте продолжение этого поста: Защита против взломов in-app покупок. Часть 2.

Не так давно шумели новости о активации in-app покупок бесплатно и даже без джейлбрейка. Идея проста: в систему устанавливаются ssl сертификаты и прописывается кастомный dns сервер, который запросы к серверам apple будет пересылать на сервер взломщиков. Сервер взломщиков будет подтверждать покупку и она успешно активируется на устройстве. После выхода этой новости паники было много и Apple даже пришлось что-то делать и рассказывать разработчикам, как защитить их приложение. На самом деле проблема была не нова, на джейлбрейкнутых устройствах уже давно можно было активировать in-app покупки бесплатно. Решение проблемы также не ново, оно описано в документации Apple, но практической реализацией никто себя не утруждал. О моей версии такой защиты и пойдет речь ниже.

Данный топик это некоторая компиляция из руководства по установке gitosis на Ubuntu Server и Leopard, плюс акценты от меня на некоторые места в которых могут возникнуть проблемы.