Comments 12
Мы пользуемся для одного проекта и дописываем таким образом информацию о пользователе во время скачивания дистрибутива. Это позволяет отслеживать от какого партнера скачивался инсталятор.
Гуд! Значит тема в некоторых кругах известная. Как реализовали серверную часть, если не секрет?
Насколько я помню, до безобразия просто. У нас есть сборочная ферма, которая собирает инсталяторы для разных партнеров. Во время подписывания инсталлера мы делаем секцию нужного нам размера и заполняем ее нулями. А потом при отдаче скрипт клиента пишет вместо нулей туда все что нужно. Как-то так. Скрипт же инсталлера, умеет «извлекать» из себя эту информацию.
переподписывание – очень долгий процесс, если речь идёт про отдачу сотен больших (100 MB+) дистрибутивов игр в секунду, как в нашем случае.Может я ошибаюсь, но если процесс подписывания требует последовательного поступления входных данных, то можно хранить незавершённый вариант подписи, а затем завершать её с разными наборами конечных данных. Тогда размер файла не будет иметь значения.
Timestamp ещё надо наложить от кого-нить типа verisign. А это несколько секунд.
А не знаете ли, зачем при подписи куда-то подключаться? До сих пор не раскопал зачем signcode.exe подключаться к какому-то веб-серверу чтобы установить timestamp. Сертификат от verisign есть, время годности в нем прописано. Физически подписывание им — это добавление сертификата вовнутрь .exe файла, подсчет контрольной суммы получившегося, шифрование контрольной суммы парным сертификату приватным ключем и сохранение полученного числа также вовнутрь .exe. Не понимаю, какую роль в этой довольно простой схеме имеет подключение к серверу :(
Временная метка начинает работать, когда истекает срок сертификата. Если её нет, то в этот момент подпись становится недействительной и приложение переходит в разряд «Неизвестный издатель».
При наличии временной метки приложение всегда будет доверенным, даже после истечения срока действия сертификата, которым оно было подписано.
При наличии временной метки приложение всегда будет доверенным, даже после истечения срока действия сертификата, которым оно было подписано.
Да, совершенно верно. Можно кэшировать digest context и генерировать подпись за сравнительно короткий промежуток времени. Но помимо подписи есть ещё timestamp, который в идеале хочется оставить, но хождение к этому сервису сводит на нет попытку ускорения.
Если timestamp исключить из схемы подписывания, то этот вариант интересен своей универсальностью и 100% честностью подписи, но требует больше затрат при разработке и более сложен в поддержке. Нужна реализация алгоритма подписи, кэширование digest context для различных добавляемых данных, в случае аварии подпись может перестать генерироваться и всё станет совсем печально.
Зато перспективы этого способа гораздо интересней — по сути можно собирать инсталлятор совершенно из любых частей кода и ресурсов прямо в процессе отдачи файла с сервера.
Если timestamp исключить из схемы подписывания, то этот вариант интересен своей универсальностью и 100% честностью подписи, но требует больше затрат при разработке и более сложен в поддержке. Нужна реализация алгоритма подписи, кэширование digest context для различных добавляемых данных, в случае аварии подпись может перестать генерироваться и всё станет совсем печально.
Зато перспективы этого способа гораздо интересней — по сути можно собирать инсталлятор совершенно из любых частей кода и ресурсов прямо в процессе отдачи файла с сервера.
Спасибо, коллеги. Идеальная статья для рекламы компании на хабре :). Можно заносить в справочник начинающего маркетолога. И alawar ненавязчиво попиарили, и сложную, интересную тему раскрыли. Сам недавно с сертификатами возился — информации по ним мало, все что есть — описание каких-то шаманских ртиуалов вообще без понимая как это работает. Картинка с внутренним устройством вообще зачетная. Респект.
А плагин для nginx в opensource?
Sign up to leave a comment.
Тегирование EXE файлов без повреждения цифровой подписи