В данный момент я работаю над очень интересным проектом ExtremeMember (который, кстати, работает на WordPress). Одной из особенностей разработки является то, что мы используем Subversion (также известный как SVN) для обновления кода на всех сайтах (будь то основной, тестовый или клиентский — которых больше сотни — сайт).

Другой особенностью разработки является то, что мы предоставляем клиентам FTP-доступ ко всему сайту (разумеется, каждый клиент имеет доступ только к своему сайту — целиком — а не только к каталогу uploads). Логично, что для предотвращения "кражи интеллектуальной собственности" мы шифруем все наши файлы (в целях безопасности мы также ограничиваем доступ к некоторым другим файлам — например, базовые файлы WordPress доступны только для чтения, но это другая история). Для шифрования мы используем ionCube Encoder.

Задача такова: при изменении ветки с кодом клиентских сайтов её нужно автоматически зашифровывать. Проблема в том, что мы (разработчики) работаем над открытым кодом, а клиенты должны получить закрытый (шифрованый) код; как следствие, одну и ту же ветки в репозитории мы использовать не можем.

Возможное решение: шифровать код непосредственно после обновления (svn up на клиенте с последующим шифрованием). Такое решение не подходит: шифрование изменяет исходный файл, поэтому обновление кода породит кучу конфликтов, ибо Subversion просто не сможет объединить (merge) столь разношерстные изменения. Можно, конечно, выполнить svn revert на зашифрованых файлах перед обновлением, но это решение всё равно нас не устраивает: будет ненулевой момент времени после начала обновления и перед окончанием шифрования, когда исходный код будет открыт (а длительность этого момента времени очень сильно зависит от нагрузки на сервер). По соображениям безопасности такое решение не подходит.

Другой вариант: выполнять обновление всего открытого кода; код для шифрования писать в отдельную папку, шифровать и заливать на все сайты. Кроме трудностей в реализации (из-за структуры кода) есть и другие недостатки: например, какое-то время код может находиться в нерабочем состоянии из-за того, что обновление разбито на два этапа; длительность этого состояния определяется загрузкой процессора.

Радикальный вариант: грохать всё нафиг и записывать свежую версию кода. Есть существенный недостаток: клиент может вносить свои изменения (темы, плагины и т.д.); в результате выполнения действия "грохать всё нафиг" они будут безвозвратно утеряны.

Мой вариант (возможно, не самый оптимальный, но рабочий): использовать post-commit hook. Код клиентских сайтов хранится в /tags/stable; при обнаружении изменений, внесённых в эту ветку, мы зашифровываем нужные нам файлы и заливаем изменения в ветку /tags/encrypted.

repository_root/hooks/post-commit:

[-]
View Code Bash
#! /bin/sh

# Используем путь к репозиторию через протокол file - будет быстрее
REPOS="file:///var/svn/extreme"
REV="HEAD"

/usr/bin/svn log --verbose -r $REV $REPOS | grep "/tags/stable" > /dev/null

# Смотрим, были ли изменения в /tags/stable
if [ 0 -eq $? ]; then
    /usr/bin/svn export -q -r $REV $REPOS/tags/stable/public/ /tmp/$$/ >/dev/null
    /usr/bin/svn checkout -q $REPOS/tags/encrypted/ /tmp/_$$/ >/dev/null

    REV_STABLE=`/usr/bin/svn info $REPOS/tags/stable/public/ | grep 'Last Changed Rev:' | awk '{ print $4; }'`
    REV_CRYPT=`/usr/bin/svn info $REPOS/tags/encrypted/ | grep 'Last Changed Rev:' | awk '{ print $4; }'`

    /usr/bin/svn merge $REPOS/tags/encrypted/@$REV_CRYPT $REPOS/tags/stable/public/@$REV_STABLE /tmp/_$$/

    # Шифрование файлов - не привожу код полностью
    /opt/ioncube/ioncube_encoder5 --ignore .svn/ --merge-target --optimize max --no-doc-comments ...

    # Заливаем зашифрованую версию
    /usr/bin/svn commit -m "* Encrypted revision $REV_STABLE" /tmp/_$$/
    rm -rf /tmp/$$ /tmp/_$$
fi
Добавить в закладки

Связанные записи

3
Авг
2008

Комментарии к статье «Subversion, ionCube и прозрачное шифрование» (2)  »

  1. Jurgen says:

    Как тесен этот мир. Я поработал над этим проектом пару дней - и отказался - по впечатлениям, практически обратным (говно-проект, в общем)

  2. Vladimir says:

    Именно поэтому я за него и взялся… Если заниматься только тем, что легко, тем, что всегда получится — и без лишних усилий — то теряется возможность к развитию и самосовершенствованию. Из крайне неудачной реализации блестящей идеи сделать что-то действительно стоящее, имеющее успех, и при этом научить разработчиков чему-то новому — разве оно не стоит того?

    Да, иногда это бессонные ночи, иногда — желание пожать автору горло, но конечный результат стоит того! Есть простор для творчества и развития, но самое главное: оно работает!

Подписаться на RSS-ленту комментариев к статье «Subversion, ionCube и прозрачное шифрование» Trackback URL: http://blog.sjinks.org.ua/linux/290-subversion-ioncube-transparent-encryption/trackback/

Оставить комментарий к записи «Subversion, ionCube и прозрачное шифрование»

Вы можете использовать данные тэги: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Оставляя комментарий, Вы выражаете своё согласие с Правилами комментирования.

Подписаться, не комментируя