C #: po co podpisywać zestaw?

146

W pewnym kodzie C #, który przejąłem (w Visual Studio 2005), zauważyłem, że wszystkie zespoły są podpisane tym samym .snkplikiem.

  • Dlaczego poprzedni autor miałby podpisywać zgromadzenia w ten sposób?
  • Czy podpisywanie zestawów jest konieczne i co byłoby złego w braku podpisu?
  • Jakie wady ma podpisywanie złożeń - czy to powoduje opóźnienia?
Craig Johnston
źródło

Odpowiedzi:

186

Dlaczego poprzedni autor miałby podpisywać zgromadzenia w ten sposób?

Nie mam pojęcia, może chciał, żeby wszystkie jego zgromadzenia były podpisane tym samym kluczem.

Czy podpisywanie zgromadzeń jest konieczne i co byłoby złego w ich niepodpisywaniu?

Nie, nie jest to konieczne, ale jest to mechanizm umożliwiający zapewnienie autentyczności zestawu. Pozwala to upewnić się, że zespół nie został zmieniony i faktycznie pochodzi od tego autora. Jest to również konieczne, jeśli chcesz umieścić je w GAC.

Jakie wady ma podpisywanie złożeń - czy to powoduje opóźnienia?

Podpisane zestawy mogą ładować tylko inne podpisane zestawy. Są one również powiązane z określoną wersją, co oznacza, że ​​musisz użyć przekierowań powiązań lub ponownie skompilować aplikację, jeśli chcesz użyć innej wersji. Istnieje również niewielki narzut wydajności ze względu na weryfikację podpisu, ale jest to tak mało, że nie powinieneś się tym przejmować.

Darin Dimitrov
źródło
2
Zwróć uwagę, że weryfikacja podpisów nie odbywa się już (od .NET 2.0) po umieszczeniu w GAC; dzieje się to tylko raz, podczas dodawania go do GAC .
Abel
1
Co myślisz o podpisaniu go obecnie? Na systemach internetowych? Jeśli mam rację, było to konieczne tylko, gdy mówiłem o zainstalowanym oprogramowaniu, prawda? Jeśli opublikuję moją aplikację na platformie Azure przy użyciu TFS, wiem, że nie została ona naruszona, prawda? A może brakuje mi jakiejś części zabezpieczającej?
Rick Wolff
Pierwsze pytanie: stworzył szablon projektu z projektu, który miał plik klucza sygnatury zespołu, następnie użył tego szablonu projektu do stworzenia innego elementu i zapomniał zastąpić plik klucza. (po prostu zamień „on” na „ja” i wiesz, co robiłem dziś rano :)). Więc to jest przypadkowe.
hardyVeles
33

Musisz podpisywać zestawy, jeśli chcesz je umieścić w GAC .

Jeśli podpiszesz plik wykonywalny, wszystkie biblioteki klas, do których prowadzi łącze, również muszą zostać podpisane. Może to być trudne, jeśli korzystasz z biblioteki innej firmy (zwłaszcza jeśli musisz użyć formantu ActiveX lub podobnego).

Richard Grimes napisał dobre warsztaty na temat bezpieczeństwa w .NET i zawiera rozdział na ten temat: Warsztaty bezpieczeństwa

Przyczyną podpisywania wszystkich zestawów tym samym plikiem .snk może być użycie testów jednostkowych z pokryciem kodu. Aby móc pokryć kod (przynajmniej za pomocą narzędzi wbudowanych w testową wersję Visual Studio 2005) i jeśli zestawy są podpisane, musisz określić, jakie pliki .snk są używane do podpisywania, ale myślę, że możesz tylko określ jeden plik .snk dla całego rozwiązania, więc jeśli podpiszesz różne biblioteki klas różnymi plikami .snk, możesz sprawdzić pokrycie kodu tylko jednego z nich na raz.

Hans Olsson
źródło
17

Bardzo ważnym powodem do podpisania zestawu jest upewnienie się, że to Twoje zgromadzenie. Ponieważ klucz prywatny należy do Ciebie, nikt inny nie może podpisać zestawu tym samym kluczem. Oznacza to, że kiedy klucz publiczny zestawu jest tym, który znasz (możesz go odzyskać za pomocą GetType().Assembly.GetName().GetPublicKey()funkcji), zestaw jest Twój i nie został zmieniony.

Pieter van Ginkel
źródło
1

Pomimo wszystkich zastosowań podpisywania biblioteki dll, biblioteka dll powinna być podpisana tylko z dwóch powodów

1. Wersjonowanie

2. Uwierzytelnienie

za. Wersjonowanie oznacza, na jakiej wersji dll została zbudowana i podczas wypychania ich do GAC dwie biblioteki dll o tej samej nazwie mogą istnieć, ale inna wersja

b. Uwierzytelnianie wskazuje, czy dll nie została naruszona i czy istnieje tak samo, gdy została utworzona.

Jeśli chcesz dowiedzieć się więcej o podstawach i podpisywaniu bibliotek dll, możesz zapoznać się z tutaj

Karthikeyan VK
źródło
1
Co myślisz o podpisaniu go obecnie? Na systemach internetowych? Jeśli mam rację, było to konieczne tylko, gdy mówiłem o zainstalowanym oprogramowaniu, prawda? Jeśli opublikuję moją aplikację na platformie Azure przy użyciu TFS, wiem, że nie została ona naruszona, prawda? A może brakuje mi jakiejś części zabezpieczającej?
Rick Wolff
1
Nie widzę powodu, dla którego powinniśmy podpisać bibliotekę dll już za kilka dni, która zostanie wdrożona jako rozwiązanie Paas w kolorze lazurowym. Ale jeśli masz rozwiązanie iaas, możesz ponownie użyć biblioteki dll przez aplikację internetową w tym samym iis. Czego nie polecam. Powinniśmy je wywoływać przez api url, zamiast używać tych bibliotek dll z GAC (architektura mikrousług).
Karthikeyan VK
1

Oprócz istniejących odpowiedzi chciałbym dodać, że musisz użyć podpisu, gdy twoja biblioteka DLL ma być dynamicznie ładowana i używana przez oprogramowanie innej firmy. Nie jest to wymóg techniczny jako taki, ale racjonalne, dlatego bardzo powszechne jest, aby producent oprogramowania będący stroną trzecią egzekwował taką politykę ze względów bezpieczeństwa.

Przykłady, w których należy podpisać zestaw:

  • rozwój rozszerzenia Windows Shell / Windows Explorer, takich jak: rozszerzenie menu kontekstowego dla Eksploratora Windows
  • rozwój rozszerzeń Visual Studio, takich jak: GUI Kreatora szablonu projektu / elementu
hardyVeles
źródło
0

Podpisywanie i montaż są ważne. Aby upewnić się, że exe lub zestaw jest zainstalowany tylko na tym komputerze.

To znaczy: jeśli skopiujesz ten folder i umieścisz go na innym komputerze, to nie zadziała. ponieważ jest to podpisywanie tego zestawu tylko na tym komputerze.

Ram Kumar
źródło