Coś nie tak z NIE podpisywaniem zestawu .NET?


95

Jeden z moich kolegów bardzo chętnie podpisuje zgromadzenia. Dosłownie próbuje coś podpisać. Nawet jeśli używamy zestawów firmy Microsoft, które nie są podpisane, weźmie kod źródłowy, podpisze go, a następnie poprosi innych programistów, aby zamiast tego użyli jego kopii.

Rozumiem podstawową ideę podpisywania zestawu: aby upewnić się, że dany zestaw nie zostanie naruszony przez jakiegoś podejrzanego hakera. Więc jeśli jesteśmy firmą programistyczną, powinniśmy podpisać nasz zestaw przed udostępnieniem jakiejś biblioteki .NET naszym klientom.

Jednak głównie tworzymy aplikacje internetowe na własny użytek i po prostu nie widzę sensu podpisywania każdego zestawu, którego używamy.

Czy coś mi umyka?


1
Warto zauważyć pewne zamieszanie w tym miejscu, „podpisy cyfrowe” (które mają cel bezpieczeństwa) i „Zestawy o silnych nazwach”, które są naprawą dll hell i pomagają GAC w łączeniu się z bibliotekami. Używanie jednego lub drugiego jest podobne i obu można mówić w kategoriach podpisywania zgromadzenia. Wygląda na to, że niektóre plakaty myślą o jednym, a inne o innym lub obu.
połączono

Odpowiedzi:


50

Podpisywanie zestawów używanych w zaufanym środowisku brzmi dla mnie jak przesada.

Ciekawostką dotyczącą podpisanych zestawów jest to, że ładują się one nieco wolniej niż zestawy niepodpisane, ponieważ muszą zostać zweryfikowane kryptograficznie.

Aby podpisać zgromadzenie, wszystkie zespoły, od których zależy, muszą być również podpisane. Domyślam się, że przyczynia się to do chęci twojego kolegi do podpisania wszystkiego - kompilator tego żąda.


EDYCJA Od napisania tej odpowiedzi widać, że zarówno obóz za, jak i przeciw ma z grubsza równoważne wsparcie. Oczywiście nie ma tutaj właściwej odpowiedzi.

Punktem, który wymusił tę edycję, jest jednak to, że obecnie bierzemy tak wiele bibliotek open source z NuGet, a wiele z nich w ogóle nie jest podpisanych. Jeśli chcesz podpisać swój zestaw, musisz mieć również podpisane wszelkie zależności. Wiele z podpisanych bibliotek typu open source ma klucze prywatne używane do podpisywania, które są publicznie dostępne w ich repozytoriach źródłowych.

Jak w przypadku wszystkiego, trzeba dokonać kompromisów. Z mojego doświadczenia w pracy w środowiskach prywatnych wynika , że korzyści płynące z podpisywania są głównie teoretyczne (lub akademickie, jak wspomina @ user289100 ), chyba że obawiasz się , że agencje rządowe modyfikują twój kod. W takim przypadku musisz mieć paranoję na tak wielu poziomach Twoja infrastruktura, że ​​podpisanie wydawałoby się wymagające niewielkiego wysiłku. W przeciwnym razie ilość wyzwań płynących z konieczności podpisywania wszystkiego po prostu nie wydaje się tego warta. Jednak twoje środowisko może mieć inne wymagania, albo możesz być masochistą!

Zobacz także odpowiedź Teun D, aby uzyskać informacje na temat wyzwań związanych z wersjonowaniem zestawów podczas używania silnych nazw.


17
Zgoda, to jest teraz dla niego uzależnienie od cracków
Janie

3
Jeszcze jedną kwestią, na którą należy zwrócić uwagę, jest to, że jeśli chcesz udostępnić ten zestaw w różnych aplikacjach, podpisywanie jest koniecznością (tj. GAC).
rajesh pillai

60

Skorzystałem z niezatwierdzonych zgromadzeń, aby obejść problemy, zanim iw środowisku akademickim pokazałem ludziom, dlaczego jest to ważne. Zastąpiłem niepodpisany plik DLL (ponownie w środowisku akademickim), utworzonym przeze mnie z tą samą nazwą, tymi samymi podpisami i użyłem .NET Reflector do skopiowania i wklejenia oryginalnego kodu, ale w moim wysłałem e-mailem nazwy użytkowników i hasła, które były przekazywane przed wywołaniem „prawdziwego” kodu.

Jeśli jest podpisany, możesz dopasować podpis, ale nie możesz go zastąpić. W przeciwieństwie do tego, co mówi Zippy, wystąpi błąd komplikacji w czasie wykonywania.

Podpisywanie zestawów nigdy nie jest przesadą. Trwa to 30 sekund. To tak, jakby powiedzieć, że zamykanie drzwi jest przesadą, jeśli mieszkasz na wsi. Jeśli chcesz uprawiać hazard ze swoimi rzeczami, nie krępuj się, zostaw to otwarte. Aby zostać zwolnionym, wystarczy jedno naruszenie bezpieczeństwa. Podpisanie zestawu zajmuje tylko 30 sekund i nie ma uzasadnienia biznesowego, aby tego nie robić. Wpływ na wydajność jest pomijalny.


11
Jeśli haker może zmienić bibliotekę dll, może również zmienić aplikację, która ją wywołuje.
ZippyV

12
To jest poprawne Zippy, ale bez klucza do podpisania aplikacji będą mieli trudności z uruchomieniem aplikacji w środowisku, w którym może działać tylko podpisana wersja oryginalnej aplikacji, co miałoby miejsce w kilku środowiskach, w których pracowałem. Tęsknienie za lasem dla drzew: niepodpisanie zestawu oznacza niepotrzebne zagrożenie bezpieczeństwa, którego uniknięcie zajmuje 30 sekund i nie ma żadnego uzasadnienia biznesowego ani rzeczywistego przypadku, którego nigdy nie widziałem podpisać zgromadzenie.
user289100

39

Jeden dodatkowy punkt: podpisywanie zestawów przerywa zgodność wsteczną z wersjami. Wszystkie Twoje odniesienia zaczynają zawierać numery wersji, a wersje z innymi numerami wersji są uważane za niekompatybilne. Utrudnia to uaktualnianie do nowszych wersji zestawów rozproszonych.

Moim zdaniem, zespoły ze znakiem kodu powinny być tylko wtedy, gdy widzisz z tego konkretny zysk:

  • jeśli wdrażasz w środowiskach, w których niezaufane osoby mogą dotykać Twoich zestawów
  • w niektórych modelach wtyczek, w których chcesz użyć certyfikatu jako dowodu na zwiększenie zaufania
  • jeśli twój kod powinien być wywoływalny z innego podpisanego kodu (projekt taki jak, powiedzmy log4net, słusznie podpisuje swój kod, aby był szeroko użyteczny; bardzo zawiedli w kompatybilności, tracąc swój tajny klucz kilka lat temu, kolejne ryzyko podpisywania kodu) .
  • jeśli chcesz wdrożyć w GAC

9

Czy twój kolega dał ci jakieś wskazówki, dlaczego lubi podpisywać apele? Jedną z zalet podpisywania, która nie została jeszcze tutaj omówiona, jest to, że tylko podpisane zestawy można umieścić w GAC (tj. Udostępniać w zarządzanych procesach), ale wady wydają się przeważać wady z mojej (co prawda niedoświadczonej) perspektywy.

Twoja anegdota o samopodpisującym się kodzie Microsoft wydaje mi się szczególnie podejrzana. Jeśli firma MS nie podpisała kodu, prawdopodobnie jest powód, prawda? Podpisując go, bierzesz na siebie odpowiedzialność, gdy tego nie napisałeś - kolejna okazja, by cię ugryźć w przyszłości.


2
właściwie nie jestem pewien dlaczego, ale Microsoft z pewnością nie podpisał Enterprise Library 3.1
oscarkuo

1
Dlaczego współdzielenie zespołu między procesami wymagałoby, aby zestaw znajdował się w GAC?
Dirk Vollmar

4
Nie chodzi o to, że nie można udostępniać odwołań środowiska uruchomieniowego do tego samego pliku .dll, ale tylko zestawy o silnych nazwach (tj. Podpisane) mogą dostać się do GAC - a zestawy są umieszczane w GAC, aby można je było udostępniać.
Dan Davies Brackett

4

Inną rzeczą związaną z podpisywaniem montażu jest to, że nie można wstrzyknąć niewłaściwego w miejsce swojego (również - przez przypadek). Na przykład, jeśli utworzysz program, który odwołuje się do zestawu Foo.dll w wersji 1.0, ktoś może utworzyć zestaw w tej samej wersji i zastąpić twój, kiedy podpiszesz swoją bibliotekę, nie będzie to możliwe (w przynajmniej nie sądzę, żeby było to łatwo możliwe).


4

Podpisy są konieczne tylko wtedy, gdy zestawy są umieszczane w GAC, nic więcej. Podpisane zestawy nie uniemożliwiają komuś bałaganu z nimi. Haker nadal może usunąć podpis i każdy inny kod sprawdzający podpis.


2
W przypadku aplikacji internetowej haker musiałby również zmodyfikować plik web.config.
Tangurena

3
Jeśli haker może usunąć podpisy z zestawu, plik web.config również ich nie zatrzyma.
ZippyV,

4
Osobom osłabiającym zaleca się przeczytanie ianpicknell.blogspot.com/2010/02/ ... i podobnych artykułów, do których prowadzą linki z tego artykułu.
Constantin

1
Obecne: tak i nie. Próbowałem, a Windows domyślnie NIE sprawdza podpisu („silna nazwa”). Prawdopodobnie przyjazny dla użytkownika :-) Odnośniki, do których się odwołujemy, pokazują, co dodać do App.config, aby wymusić sprawdzanie podpisów. A potem, w przeciwieństwie do artykułu, sprawdzanie podpisów naprawdę działa i wykrywa wszelkie manipulacje, czy to w przypadku numeru wersji, czy treści.
Roland

3

Zgadzam się, wydaje się to trochę marnotrawstwem. Jest to naprawdę konieczne, aby upewnić się, że plik jest tym, czym myślisz, że jest (i nie został zmieniony). Ale jeśli ufasz ograniczeniom własnego bezpieczeństwa sieci i serwera WWW, podpisywanie zestawów sieci Web wydaje się zbędnym krokiem.

Ale może tak mówi moje doświadczenie w małej firmie. Jeśli mówisz o witrynie bankowości internetowej o znaczeniu krytycznym, wyloguj się.


2

Pomyśl o zrobieniu tego, jeśli zamierzasz coś wysłać i / lub faktycznie masz powód, aby to zrobić. W każdym innym przypadku jest to po prostu kłopotliwe. Zapytałabym twojego kolegę z pracy, co tak naprawdę ma z robienia tego.

Zetknąłem się już wcześniej z podpisanym montażem i jest to ból na później, zwłaszcza biorąc pod uwagę liczbę ludzi, którzy mają niewielką wiedzę na temat podpisywania zgromadzeń, do czego służy i jak to zrobić. To kolejna rzecz, o którą nie powinieneś się martwić, chyba że jest to absolutnie konieczne.


1

Musisz podpisać zestaw, gdy jest używany we wdrażaniu z sieci Web ClickOnce XBAP .

Ponadto wszystkie zestawy, do których istnieją odwołania, również będą musiały zostać podpisane.


1

Podpisujemy nasze zestawy, ponieważ zdarza się, że pojawiają się błędy takie jak poniżej (ten pochodzi z testowania, ale może wystąpić podczas uruchamiania aplikacji):

System.IO.FileLoadException : Could not load file or assembly 'Latitude.Platform.Core, Version=1.0.5871.22518, Culture=neutral, PublicKeyToken=7926214d13e12325' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)

TearDown : System.IO.FileLoadException : Could not load file or assembly 'Latitude.Platform.Core, Version=1.0.5871.22518, Culture=neutral, PublicKeyToken=7926214d13e12325' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)

Odkryliśmy, że Visual Studio czasami popełnia błąd i uruchamia stary kod .

Jeśli chcesz, aby wystąpił błąd, jeśli używasz starego kodu, podpisz swoje zestawy.

Jeśli piszesz pakiet nuget , podpisz swoje zestawy . Niepodpisane zestawy są niewygodne dla nas, którzy chcą mieć pewność, że korzystamy z najnowszej wersji naszego kodu. Nie mogę naprawić programu Visual Studio . Wszystko, co mogę zrobić, to wykryć, że program Visual Studio się pomylił. Więc proszę, podpisz swoje zestawy nuget .


Aktualizacja: Fala używania niepodpisanych zestawów wygrywa;) Rozwiązujemy powyższy problem inaczej: buduj i testuj na serwerze CI, zaczynając od pustego lub „czystego” katalogu ed. Może mamy scenariusz lokalnie na naszych maszynach deweloperskich, ale rzadko się zdarza lub nie ma dużego praktycznego wpływu.
Clay Lenhart
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.