Tworzę zestaw startowy, który instaluje skompilowane złożenia z projektu open-source do GAC, aby ułatwić odwoływanie się do złożeń w szablonie. Odkąd są w GAC, muszą być podpisane.Czy muszę zabezpieczyć mój silny plik kluczy nazw dla projektu open-source?
Czy muszę zabezpieczyć hasłem i zabezpieczyć plik klucza, czy też można go pozostawić otwarte i dołączyć plik do kontroli źródła?
Strong nazwa podpisanie ma kilka celów (choć nie dla rzeczywistej ochrony przed ingerencją z programem, jak to jest błędne) - w przypadku korzystanie z silnym kluczem do jednoznacznej identyfikacji (i weryfikacji) konkretną wersję specjalny zestaw wymagany przez GAC. Inne użycie, które zapobiega podszywaniu się pod inne zespoły, nie wydaje się w tym przypadku konieczne (popraw mnie, jeśli się mylę). Z tego powodu uważam, że całkowicie dopuszczalne jest pozostawienie klucza otwartego (nie chronionego hasłem) i uwzględnienie pliku w kontroli źródła. O ile widzę, nie zatrzymasz niczego, czego nie chcesz, używając hasła chroniącego klucz. (Jeśli jednak można podać więcej szczegółów na temat kontekstu zabezpieczeń, być może będę musiał zmienić ten widok.)
Zobacz także this MSDN article, aby uzyskać dokładną dyskusję na temat prawidłowego używania silnego podpisywania nazw.
Powiedziałbym, że klucz do "rozwoju" w kontroli źródła, aby ułatwić budowanie i uniknąć zmuszania ludzi do zabawy z tworzeniem i używaniem własnego klucza. Klucz w kontroli źródła jest bezsensowny pod względem bezpieczeństwa, ponieważ każdy może się z nim podpisać. Jeśli ludzie chcą podpisać swoją wersję projektu open source, mogą zastąpić klucz, którym mogą zarządzać w dowolny sposób.
Można również udostępniać kompilacje do pobrania, podpisane za pomocą bezpiecznego klucza (którego nikomu nie udostępniasz), ale aby ludzie chcieli używać tych plików binarnych, będą musieli Ci zaufać. Czy jesteś godny zaufania? :)
Czy mógłbyś rozwinąć ten błędny pogląd na temat ochrony przed naruszeniem złożenia? Nie wydaje mi się to poprawne (patrz http://stackoverflow.com/questions/369248/can-strong-naming-an-assembly-be-used-to-verify-the-assembly-author/369477#369477), ale może czegoś mi brakuje? Jednak sama silna nazwa nie jest w stanie zweryfikować uprawnień (które wymagałyby mechanizmu certyfikatów, takiego jak Authenticode). –
@divo: Co jest nie tak, dokładnie? Problem z silnym podpisywaniem klucza polega na tym, że nie można zweryfikować źródła klucza publicznego, aby mógł on zostać zregenerowany przez innego autora i nadal zgadzać się z przypisami (które mogą zostać zmienione). Jeśli uważasz, że połączona odpowiedź nie zgadza się z moją (jestem pewna, że tak nie jest), spróbuj ją przeczytać ostrożnie (w połączeniu z odpowiedzią Mehrdada, która jest również dobra). Jest tu kilka subtelności, które w żaden sposób nie są łatwe do zrozumienia. – Noldorin