.NET 어셈블리에 서명하지 않는 데 문제가 있습니까?

제 동료 중 한 명이 어셈블리 서명에 매우 열심입니다. 그는 말 그대로 무엇이든 서명하려고합니다. 서명되지 않은 Microsoft의 어셈블리를 사용하더라도 그는 소스 코드를 가져 와서 서명 한 다음 다른 개발자에게 자신의 복사본을 대신 사용하도록 요청할 것입니다.

어셈블리 서명의 기본 개념을 이해할 수 있습니다. 특정 어셈블리가 일부 멍청한 해커에 의해 손상되지 않도록하는 것입니다. 따라서 소프트웨어 개발 회사 인 경우 일부 .NET 라이브러리를 고객에게 릴리스하기 전에 어셈블리에 서명해야합니다.

그러나 우리는 주로 여기에서 자체적으로 사용할 웹 응용 프로그램을 개발하고 있으며 우리가 사용하는 모든 단일 어셈블리에 서명하는 시점을 알 수 없습니다.

여기에 뭔가 빠졌나요?

신뢰할 수있는 환경에서 사용되는 어셈블리에 서명하는 것은 나에게 지나친 것처럼 들립니다.

서명 된 어셈블리의 흥미로운 점은 암호화 방식으로 확인해야하므로 서명되지 않은 어셈블리보다로드 속도가 약간 느리다는 것입니다.

어셈블리에 서명하려면 해당 어셈블리에 의존하는 모든 어셈블리도 서명해야합니다. 내 생각 엔 이것이 모든 것에 서명하려는 동료의 욕구에 기여한다는 것입니다. 컴파일러가 그것을 요구하고 있습니다.

편집하다 이 답변을 작성한 후 프로와 반대 캠프 모두 대략 동등한 지원을받는 것을 볼 수 있습니다. 여기에는 정답이 분명히 없습니다.

그러나이 편집을 강요 한 요점은 오늘날 NuGet에서 많은 오픈 소스 라이브러리를 가져 와서 그 중 많은 부분이 전혀 서명되지 않았다는 것입니다. 어셈블리에 서명하려면 종속성도 서명해야합니다. 서명 된 많은 오픈 소스 라이브러리에는 서명에 사용되는 개인 키가 소스 리포지토리에서 공개적으로 사용 가능합니다.

모든 것이 그렇듯이 절충안이 있습니다. 개인 환경에서 일한 경험상, 서명의 이점은 대부분 이론적 (또는 @ user289100이 언급 한 바와 같이 학술적 )입니다. 서명이 약간의 노력처럼 보일 수있는 인프라. 그렇지 않으면 모든 것에 서명해야하는 문제의 양이 그만한 가치가없는 것 같습니다. 그러나 환경에 다른 요구 사항이 있거나 매저 키스트 일 수 있습니다!

강력한 이름을 사용할 때 어셈블리 버전 관리와 관련된 문제에 대한 정보 는 Teun D의 답변 을 참조하십시오 .

나는 서명되지 않은 어셈블리를 활용하여 사람들에게 왜 중요한지 보여주기 전과 학업 환경에서 문제를 해결했습니다. 서명되지 않은 DLL 파일 (학술적 설정에서 다시)을 동일한 이름, 동일한 서명으로 만든 DLL 파일로 교체하고 .NET Reflector 를 사용 하여 원본 코드를 복사하여 붙여 넣었 지만 내에서는 사용자 이름과 암호를 이메일로 보냈습니다. '실제'코드를 호출하기 전에 전달되었습니다.

서명 된 경우 서명을 일치시킬 수 있지만 교체 할 수는 없습니다. Zippy가 말하는 것과 달리 런타임 컴파일 오류가 있습니다.

어셈블리에 서명하는 것은 결코 지나치지 않습니다. 30 초가 걸립니다. 그것은 당신이 시골에 살고 있다면 문을 잠그는 것이 과잉이라고 말하는 것과 같습니다. 소지품을 가지고 도박을하고 싶다면 열어 두십시오. 한 번의 보안 위반으로 해고됩니다. 어셈블리에 서명하는 데 30 초 밖에 걸리지 않으며 서명하지 않는 비즈니스 사례는 없습니다. 성능에 미치는 영향은 무시할 수 있습니다.

한 가지 추가 사항 : 어셈블리에 서명하면 버전에 대한 이전 버전과의 호환성이 깨집니다. 모든 참조에 버전 번호가 포함되기 시작하고 다른 버전 번호가있는 버전은 호환되지 않는 것으로 간주됩니다. 이로 인해 최신 버전의 분산 어셈블리로 업그레이드 할 수 없습니다.

제 생각에는 구체적인 이득을 본다면 어셈블리에 코드 서명을해야합니다.

• 신뢰할 수없는 사람이 어셈블리를 만질 수있는 환경에 배포하는 경우
• 신뢰를 업그레이드하기위한 증거로 인증서를 사용하려는 특정 플러그인 모델에서
• 코드를 다른 서명 된 코드에서 호출 할 수 있어야하는 경우 (예 : log4net과 같은 프로젝트는 코드를 널리 사용할 수 있도록 정당하게 서명합니다. 몇 년 전 비밀 키를 잃어 버리고 코드 서명의 또 다른 위험으로 인해 호환성이 크게 망가졌습니다) .
• GAC에 배포하려는 경우

동료가 집회에 서명하는 것을 좋아하는 이유에 대해 알려준 적이 있습니까? 아직 논의되지 않은 서명의 한 가지 장점은 서명 된 어셈블리 만 GAC에 넣을 수 있다는 것입니다 (즉, 관리되는 프로세스간에 공유 할 수 있음). 그러나 단점이 내 (실질적으로 경험이없는) 관점에서 볼 때 장점보다 큰 것 같습니다.

Microsoft 코드 자체 서명에 대한 귀하의 일화는 특히 저에게 의심스러운 것 같습니다. MS가 코드에 서명하지 않았다면 아마도 이유가 있겠죠? 그리고 그것에 서명함으로써, 당신은 그것을 쓰지 않았을 때 책임을지게됩니다. 미래가 당신을 물릴 또 다른 기회입니다.

어셈블리 서명에 대한 또 다른 점은 귀하의 어셈블리 대신 잘못된 어셈블리를 주입 할 수 없다는 것입니다 (또한 사고로 인해 귀하 자신). 예를 들어 어셈블리 Foo.dll, 버전 1.0을 참조하는 프로그램을 만들면 다른 사람이 동일한 버전으로 어셈블리를 만들고 교체 할 수 있습니다. 라이브러리에 서명 할 때 가능하지 않습니다. 적어도 나는 그것이 쉽게 가능하다고 생각하지 않는다).

서명은 어셈블리가 GAC에 배치 된 경우에만 필요합니다. 서명 된 어셈블리는 누군가가 그들을 엉망으로 만드는 것을 막지 않습니다. 해커는 서명과 서명을 확인하는 다른 코드를 제거 할 수 있습니다.

나는 그것이 약간의 낭비처럼 보인다는 데 동의합니다. 파일이 당신이 생각하는 그대로 (그리고 변조되지 않았는지) 확인하는 것이 정말로 필요합니다. 그러나 자신의 네트워크 보안 및 웹 서버의 한계를 신뢰한다면 웹 어셈블리에 서명하는 것은 중복 단계처럼 보입니다.

그러나 아마도 그것은 나의 소기업 경험이 말하는 것입니다. 미션 크리티컬 한 온라인 뱅킹 웹 사이트에 대해 이야기하고 있다면 서명하십시오.

무언가를 배송 할 예정이거나 실제로 배송 할 이유가있는 경우이를 고려해보십시오. 다른 모든 경우에는 번거 롭습니다. 직장 동료에게 실제로이 일을 통해 얻는 것이 무엇인지 물어보고 싶습니다.

나는 이전에 서명 된 어셈블리-염을 만났고, 특히 어셈블리 서명에 대해 거의 또는 전혀 모르는 사람들의 수, 그것이 무엇을위한 것인지, 어떻게 하는지를 고려할 때 후부의 고통입니다. 절대적으로 필요한 경우가 아니라면 걱정할 필요가없는 또 다른 문제입니다.

웹에서 배포 ClickOnce XBAP 에서 사용되는 경우 어셈블리에 서명해야합니다. .

또한 참조 된 모든 어셈블리도 서명해야합니다.

다음과 같은 오류가 발생하는 경우가 있기 때문에 어셈블리에 서명합니다 (이는 테스트에서 발생하지만 응용 프로그램을 실행할 때 발생할 수 있음).

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)

Visual Studio가 때때로 잘못되어 오래된 코드를 실행 한다는 것을 발견했습니다. .

이전 코드를 실행중인 경우 오류가 발생하면 어셈블리에 서명하십시오.

너겟 패키지를 작성하는 경우 어셈블리에 서명하십시오 . 서명되지 않은 어셈블리는 최신 버전의 코드를 실행하고 있는지 확인하려는 우리에게 어색합니다. Visual Studio를 수정할 수 없습니다 . 내가 할 수있는 일은 Visual Studio가 잘못되었음을 감지하는 것뿐입니다. 따라서 너겟 어셈블리에 서명하십시오 .