W pewnym kodzie C #, który przejąłem (w Visual Studio 2005), zauważyłem, że wszystkie zespoły są podpisane tym samym .snkplikiem.
Odpowiedzi:
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ć.
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.
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.
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
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: