Podpisywanie kodu w ramach procesu budowania

Question

Chciałbym poznać niektóre z najlepszych praktyk w zakresie podpisywania kodu. Mamy aplikację opartą na platformie Eclipse i myślimy, że byłoby właściwe podpisanie naszych wtyczek. Ta wzbudziła wiele pytań:

• może/powinien być klucz prywatny w kontroli źródła?

• Czy powinniśmy podpisać kod jako część naszej nocnej kompilacji lub jako część naszego procesu wydawania?

• Czy kod zostanie automatycznie podpisany , czy jest powód, dla którego , dlaczego to powinien być krok ręczny?

Moje nachylenie jest powiedzieć: „Yes”, „nocnej” i „automatycznie”, ale widziałem tylko argument za podpisanie produkty uwalnianiu. Mogę nawet wysunąć argument, że SQA powinien podpisać kod po jego weryfikacji, chociaż byłoby to naprawdę nieładne z naszym procesem zwalniania.

Jak radzą sobie z tym inni?

Answer 1

To zależy od tego, jak bezpieczny ma być twój prywatny klucz, może to nie być coś, co chcesz, aby pracownik tymczasowy z dostępem do źródła miał pełny dostęp.

W mojej pracy, mamy następujące:

„znak test” binaria jako część naszego codziennego buduje z sprawdzane w kluczu. Wymaga to, aby testowy certyfikat główny znajdował się na komputerach w celu zaufania plikom binarnym, ale nie będą one zaufane, jeśli bity zostaną wdrożone poza firmą.

Co tydzień (i dla wersji zewnętrznych) podpisujemy za pomocą prawdziwego klucza. Odbywa się to w oddzielnym, nieco ręcznym procesie. Tylko kilka osób ma dostęp do klucza umożliwiającego podpisanie produktu.

Answer 2

Mogę Ci powiedzieć, jak widzę, jak to się robi w wielkim korpusie. Poszczególni programiści mogliby zbudować kod, ale nie mogli go podpisać. To byłaby prywatna kompilacja. Maszyna integracyjna Contiguos opuściłaby nocne kompilacje podpisane za pomocą klucza przechowywanego w magazynie kluczy maszyny budującej, który byłby kluczem testowym podpisanym przez korporacyjny urząd certyfikacji (tj. Kluczem zaufanym tylko w obrębie korpusu). Oficjalny build może być podpisany tylko przez kontrolowane maszyny z oficjalnym, globalnym zaufanym organem podpisanym, kluczem podpisu przechowywanym w modułach sprzętowych w kontrolowanym pokoju dostępowym.

Chodzi o to, że klucz prywatny powinien mieć tylko jedną kopię na świecie (najwyżej jedną dodatkową dla escrow). Cała wartość klucza pochodzi z jego prywatności, a nie z niczego innego. Ta chwila jest dostępna dla całego org, jest równie dobra, jak wystawianie jej na piracką zatokę.