Ну вот есть у вас сборка, она пойдет в релиз и будет находится в гаке. Как вы ее подпишете?
Ну не будет же там пароль "12345йцуке", так ведь? Однако каждый раз пасс генерить тоже не очень? Один какой-то ключ на весь проект?
Здравствуйте, -n1l-, Вы писали:
N>Ну вот есть у вас сборка, она пойдет в релиз и будет находится в гаке. Как вы ее подпишете? N>Ну не будет же там пароль "12345йцуке", так ведь? Однако каждый раз пасс генерить тоже не очень? Один какой-то ключ на весь проект?
Пароль вы ставите на контейнер закрытого ключа pfx. На подпись этот пароль никак не повлияет. Он нужен только для открытия контейнера с ключом.
Здравствуйте, Shmj, Вы писали:
S>Здравствуйте, -n1l-, Вы писали:
N>>Ну вот есть у вас сборка, она пойдет в релиз и будет находится в гаке. Как вы ее подпишете? N>>Ну не будет же там пароль "12345йцуке", так ведь? Однако каждый раз пасс генерить тоже не очень? Один какой-то ключ на весь проект?
S>Пароль вы ставите на контейнер закрытого ключа pfx. На подпись этот пароль никак не повлияет. Он нужен только для открытия контейнера с ключом. S>Есть контейнеры ключа без пароля -- snk.
Причём, релизного snk-файла или пароля к pfx-файлу у рядовых разработчиков в общем случае быть не должно — при правильной организации безопасности.
Здравствуйте, Qbit86, Вы писали: Q>Причём, релизного snk-файла или пароля к pfx-файлу у рядовых разработчиков в общем случае быть не должно — при правильной организации безопасности.
Т.е. сборка подписывается два раза, дебаговым ключом для отладки и сборки где бы то ни было и релизным ключом с паролем?
Здравствуйте, Shmj, Вы писали: S>Пароль вы ставите на контейнер закрытого ключа pfx. На подпись этот пароль никак не повлияет. Он нужен только для открытия контейнера с ключом.
S>Есть контейнеры ключа без пароля -- snk.
Ну я и имею ввиду пароли. Как вы организовываете систему подписи сборок с паролями?
Каждый раз придумывается пароль заново? Где-то хранится?
Здравствуйте, -n1l-, Вы писали:
N>Ну я и имею ввиду пароли. Как вы организовываете систему подписи сборок с паролями? N>Каждый раз придумывается пароль заново? Где-то хранится?
Зачем? Ключ же один. Пароль вбивается в соответствующее окошко билдсервера.
Здравствуйте, -n1l-, Вы писали:
N>Ну вот есть у вас сборка, она пойдет в релиз и будет находится в гаке. Как вы ее подпишете? N>Ну не будет же там пароль "12345йцуке", так ведь?
Там не пароль, там пара открытый-закрытый ключ. Пары для локальных отладочных сборок и для сборок, собранных на билдсервере разные.
Первый защищать смысла нет никакого, утечка приватного ключа для публичных сборок (особенно ключа Authenticode) — вещь крайне неприятная.
Чем отличается authenticode key от strong name key — тынц
Для разных команд/проектов ключи могут отличаться, но особого смысла с точки зрения безопасности в этом нет: скомпроментирован билдсервер — меняем все ключи.
В теории, есть вариант, когда корпоративный заказчик просит отдельный ключ под себя, чтобы определить источник утечки, или (до .net 4) чтобы навесить разрешения по ключу сборок. На практике с подобным не сталкивался.
Здравствуйте, -n1l-, Вы писали:
N>На каждый проект на каждую сборку одинаковый пароль?
Ещё раз: сборки подписываются не паролем.
Когда вы разберётесь с этим, сможете задавать осмысленные вопросы.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, -n1l-, Вы писали:
N>Т.е. сборка подписывается два раза, дебаговым ключом для отладки и сборки где бы то ни было и релизным ключом с паролем?
Есть термины, в которых неплохо бы разбираться по Википедии безотносительно реализации соответствующих механизмов в Visual Studio: "симметричная криптография — пароли", "асимметричная криптография — ключи", "цифровая подпись", и далее "PKI (Public Key Infrastructure)" и "сертификат открытого ключа".
N>релизным ключом с паролем?
Ключ без пароля, он просто приватный (асимметричная криптография для цифровой подписи). Вот pfx-контейнер, в котором он лежит — может быть с паролем (симметричная криптография для хранения/передачи).
Утрировано: ты генерируешь официальную релизную RSA-пару, хранишь приватный ключ на флэшке в сейфе, а публичный размещаешь на стене Вконтакте. Программисты в процессе разработки могут использовать какие угодно ключи, им надо удовлетворить требования CLR для загрузки сборок (строгое имя), и не важна безопасность. Когда же ты собираешь релизную сборку, то используешь приватный ключ из сейфа, хранящийся, например, в snk-файле. Если тебе надо передать приватный ключ "релиз-менеджеру", то можешь запаковать его в zip-архив с паролем, чтоб не пересылать в открытом виде по Скайпу; но как раз для этого уже сделали утилиту — pfx-контейнер с паролем, который можно передавать Студии непосредственно. Pfx-файл и его пароль вторичны; важен хранящийся в этом контейнере ключ. Для другого релиз-менеджера можешь создать другой pfx-файл с другим паролем, но тем же RSA-ключом.
Далее при необходимости можешь попросить некий доверенный центр связать твою identity и публичный ключ (или несколько) — путём подписи этих данных. Этот доверенный центр может в свою очередь быть заверен более доверенным — создаётся цепочка доверия, см. "сертификаты", "PKI", etc.
Я знаю.
Может быть я не правильно выражаюсь?
Есть несколько проектов, там есть сборки которые должны быть подписаны и подписи должны храниться в контейнере .pfx с паролем.
Так вот, пароли же не случайно генерятся в умах людей?