А как вы подписываете сборки для GAC
От: -n1l-  
Дата: 17.09.14 10:41
Оценка: :)
Ну вот есть у вас сборка, она пойдет в релиз и будет находится в гаке. Как вы ее подпишете?
Ну не будет же там пароль "12345йцуке", так ведь? Однако каждый раз пасс генерить тоже не очень? Один какой-то ключ на весь проект?
Re: А как вы подписываете сборки для GAC
От: Shmj Ниоткуда  
Дата: 17.09.14 14:15
Оценка: 12 (1)
Здравствуйте, -n1l-, Вы писали:

N>Ну вот есть у вас сборка, она пойдет в релиз и будет находится в гаке. Как вы ее подпишете?

N>Ну не будет же там пароль "12345йцуке", так ведь? Однако каждый раз пасс генерить тоже не очень? Один какой-то ключ на весь проект?

Пароль вы ставите на контейнер закрытого ключа pfx. На подпись этот пароль никак не повлияет. Он нужен только для открытия контейнера с ключом.

Есть контейнеры ключа без пароля -- snk.
Отредактировано 17.09.2014 14:15 Shmj . Предыдущая версия .
Re[2]: А как вы подписываете сборки для GAC
От: Qbit86 Кипр
Дата: 17.09.14 14:30
Оценка:
Здравствуйте, Shmj, Вы писали:

S>Здравствуйте, -n1l-, Вы писали:


N>>Ну вот есть у вас сборка, она пойдет в релиз и будет находится в гаке. Как вы ее подпишете?

N>>Ну не будет же там пароль "12345йцуке", так ведь? Однако каждый раз пасс генерить тоже не очень? Один какой-то ключ на весь проект?

S>Пароль вы ставите на контейнер закрытого ключа pfx. На подпись этот пароль никак не повлияет. Он нужен только для открытия контейнера с ключом.

S>Есть контейнеры ключа без пароля -- snk.

Причём, релизного snk-файла или пароля к pfx-файлу у рядовых разработчиков в общем случае быть не должно — при правильной организации безопасности.
Глаза у меня добрые, но рубашка — смирительная!
Re[3]: А как вы подписываете сборки для GAC
От: -n1l-  
Дата: 17.09.14 15:55
Оценка:
Здравствуйте, Qbit86, Вы писали:
Q>Причём, релизного snk-файла или пароля к pfx-файлу у рядовых разработчиков в общем случае быть не должно — при правильной организации безопасности.
Т.е. сборка подписывается два раза, дебаговым ключом для отладки и сборки где бы то ни было и релизным ключом с паролем?
Re[2]: А как вы подписываете сборки для GAC
От: -n1l-  
Дата: 17.09.14 15:55
Оценка: :)
Здравствуйте, Shmj, Вы писали:
S>Пароль вы ставите на контейнер закрытого ключа pfx. На подпись этот пароль никак не повлияет. Он нужен только для открытия контейнера с ключом.

S>Есть контейнеры ключа без пароля -- snk.


Ну я и имею ввиду пароли. Как вы организовываете систему подписи сборок с паролями?
Каждый раз придумывается пароль заново? Где-то хранится?
Re[3]: А как вы подписываете сборки для GAC
От: hardcase Пират http://nemerle.org
Дата: 17.09.14 15:59
Оценка:
Здравствуйте, -n1l-, Вы писали:

N>Ну я и имею ввиду пароли. Как вы организовываете систему подписи сборок с паролями?

N>Каждый раз придумывается пароль заново? Где-то хранится?

Зачем? Ключ же один. Пароль вбивается в соответствующее окошко билдсервера.
/* иЗвиНите зА неРовнЫй поЧерК */
Re[4]: А как вы подписываете сборки для GAC
От: -n1l-  
Дата: 18.09.14 02:34
Оценка:
Здравствуйте, hardcase, Вы писали:

H>Зачем? Ключ же один. Пароль вбивается в соответствующее окошко билдсервера.



На каждый проект на каждую сборку одинаковый пароль?
Re: А как вы подписываете сборки для GAC
От: Sinix  
Дата: 18.09.14 05:01
Оценка:
Здравствуйте, -n1l-, Вы писали:

N>Ну вот есть у вас сборка, она пойдет в релиз и будет находится в гаке. Как вы ее подпишете?

N>Ну не будет же там пароль "12345йцуке", так ведь?

Там не пароль, там пара открытый-закрытый ключ. Пары для локальных отладочных сборок и для сборок, собранных на билдсервере разные.
Первый защищать смысла нет никакого, утечка приватного ключа для публичных сборок (особенно ключа Authenticode) — вещь крайне неприятная.

Чем отличается authenticode key от strong name key — тынц
Автор: Sinix
Дата: 10.11.13
.

Для разных команд/проектов ключи могут отличаться, но особого смысла с точки зрения безопасности в этом нет: скомпроментирован билдсервер — меняем все ключи.
В теории, есть вариант, когда корпоративный заказчик просит отдельный ключ под себя, чтобы определить источник утечки, или (до .net 4) чтобы навесить разрешения по ключу сборок. На практике с подобным не сталкивался.
Re[5]: А как вы подписываете сборки для GAC
От: Sinclair Россия https://github.com/evilguest/
Дата: 18.09.14 05:56
Оценка: +2
Здравствуйте, -n1l-, Вы писали:

N>На каждый проект на каждую сборку одинаковый пароль?

Ещё раз: сборки подписываются не паролем.
Когда вы разберётесь с этим, сможете задавать осмысленные вопросы.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[4]: Асимметричная криптография
От: Qbit86 Кипр
Дата: 18.09.14 06:09
Оценка: 3 (1) +2
Здравствуйте, -n1l-, Вы писали:

N>Т.е. сборка подписывается два раза, дебаговым ключом для отладки и сборки где бы то ни было и релизным ключом с паролем?


Есть термины, в которых неплохо бы разбираться по Википедии безотносительно реализации соответствующих механизмов в Visual Studio: "симметричная криптография — пароли", "асимметричная криптография — ключи", "цифровая подпись", и далее "PKI (Public Key Infrastructure)" и "сертификат открытого ключа".

N>релизным ключом с паролем?


Ключ без пароля, он просто приватный (асимметричная криптография для цифровой подписи). Вот pfx-контейнер, в котором он лежит — может быть с паролем (симметричная криптография для хранения/передачи).

Утрировано: ты генерируешь официальную релизную RSA-пару, хранишь приватный ключ на флэшке в сейфе, а публичный размещаешь на стене Вконтакте. Программисты в процессе разработки могут использовать какие угодно ключи, им надо удовлетворить требования CLR для загрузки сборок (строгое имя), и не важна безопасность. Когда же ты собираешь релизную сборку, то используешь приватный ключ из сейфа, хранящийся, например, в snk-файле. Если тебе надо передать приватный ключ "релиз-менеджеру", то можешь запаковать его в zip-архив с паролем, чтоб не пересылать в открытом виде по Скайпу; но как раз для этого уже сделали утилиту — pfx-контейнер с паролем, который можно передавать Студии непосредственно. Pfx-файл и его пароль вторичны; важен хранящийся в этом контейнере ключ. Для другого релиз-менеджера можешь создать другой pfx-файл с другим паролем, но тем же RSA-ключом.

Далее при необходимости можешь попросить некий доверенный центр связать твою identity и публичный ключ (или несколько) — путём подписи этих данных. Этот доверенный центр может в свою очередь быть заверен более доверенным — создаётся цепочка доверия, см. "сертификаты", "PKI", etc.
Глаза у меня добрые, но рубашка — смирительная!
Re[6]: А как вы подписываете сборки для GAC
От: -n1l-  
Дата: 18.09.14 06:20
Оценка: -1
Я знаю.
Может быть я не правильно выражаюсь?
Есть несколько проектов, там есть сборки которые должны быть подписаны и подписи должны храниться в контейнере .pfx с паролем.
Так вот, пароли же не случайно генерятся в умах людей?
Re[5]: Асимметричная криптография
От: -n1l-  
Дата: 18.09.14 06:22
Оценка:
Здравствуйте, Qbit86, Вы писали:
Спасибо большое, за детальные пояснения.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.