Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add strongname to assembly #76

Closed
LamarLugli opened this issue Nov 5, 2017 · 24 comments
Closed

Add strongname to assembly #76

LamarLugli opened this issue Nov 5, 2017 · 24 comments
Milestone

Comments

@LamarLugli
Copy link

Can we add a strong name signing key to this assembly. I can't include it in my project that has a strong name.

@merbla
Copy link
Contributor

merbla commented Mar 7, 2018

Currently we are blocked on this by Referenced assembly 'Splunk.Logging.Common, Version=1.5.0.0, Culture=neutral

Perhaps after TCP/UDP is addressed in #65

@merbla
Copy link
Contributor

merbla commented May 1, 2018

Initial dev signed packages are at https://www.nuget.org/packages/Serilog.Sinks.Splunk/3.0.0-dev-00212

@jgbright
Copy link

@merbla Are there any plans for further follow-up on this? I'm seeing this error when I try to reference 3.0.0-dev-00223 from a signed assembly.

Could not load file or assembly 'Serilog.Sinks.Splunk' or one of its dependencies. Strong name signature could not be verified. The assembly may have been tampered with, or it was delay signed but not fully signed with the correct private key.

@merbla
Copy link
Contributor

merbla commented Mar 1, 2019

Sorry @jgbright I have dropped the ball on this one.

Staged a PR to get 3.0 out the door.

@jgbright
Copy link

jgbright commented Mar 2, 2019

Outstanding! Thank you.

@jwcurnalia
Copy link

@merbla I am still seeing this error with the 3.0.0 nuget.

Could not load file or assembly 'Serilog.Sinks.Splunk' or one of its dependencies. Strong name signature could not be verified. The assembly may have been tampered with, or it was delay signed but not fully signed with the correct private key.

@merbla
Copy link
Contributor

merbla commented Apr 4, 2019

@jwcurnalia can you provide a reference sample app illustrating the issue.

Thanks!

@jmiddour
Copy link

jmiddour commented Apr 16, 2019

@merbla I am also getting this error when accessing from a web service running .net 4.6.2. I don't have a ready made example or fix, but what I'm noticing is that the version number of the assembly that is loaded shows up as version 0.0.0.0. I am able to replicate this in a simple console app (also targeting .Net 4.6.2) referencing the latest stable version of the splunk sink....

using Serilog;
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using Serilog.Sinks.Splunk;

namespace SplunkSinkTest
{
    class Program
    {
        static void Main(string[] args)
        {
            var myLog = new LoggerConfiguration().WriteTo.EventCollector("example.com","token").CreateLogger();

            Serilog.Log.Logger = myLog;

            Log.Error("Test splunk load");
            Log.CloseAndFlush();
            var test = 1;
        }
    }
}

Here is what the reference looks like with v2.5 of the nuget pacakge:
Splunk sink v2 5

And here it is with v3.1:
Splunk sink v3 1

ETA: I just replicated with a .Net Core console app and did not get the same issue. So it may just be an individual framework version of the .dll is not signed correctly.

@BrettJaner
Copy link
Contributor

Pretty sure this is because of the missing AssemblyVersion number. Full name of loaded assembly under .net core or .net framework is:

Serilog.Sinks.Splunk, Version=0.0.0.0, Culture=neutral, PublicKeyToken=24c2f752a8e58a10

This doesn't seem to effect my library that extends serilog-sinks-splunk because I'm not signing it, but I'm guessing it would be a problem if I was. Looks like @merbla removed the AssemblyVersionAttribute with the pull request associated to this issue #86. Hopefully he can provide more insight.

@merbla merbla reopened this Apr 16, 2019
@merbla
Copy link
Contributor

merbla commented Apr 16, 2019

Re-opening this issue.Along with that changes was this update.

My assumption was that GenerateAssemblyVersionAttribute would apply the correct version.

Feel free to add a PR.

@BrettJaner
Copy link
Contributor

BrettJaner commented Apr 16, 2019

Opps wrong PR. #90 is what was merged. #90 is missing the GenerateAssemblyVersionAttribute set to true. I'll add a PR quick.

@cxt240
Copy link

cxt240 commented Jun 4, 2019

Hi, I was attempting to use the 3.2 version of the Splunk sink in a project and ran into an issue inside IIS where I get the following message on startup:

Could not load file or assembly 'Serilog.Sinks.Splunk' or one of its dependencies. Strong name signature could not be verified. The assembly may have been tampered with, or it was delay signed but not fully signed with the correct private key.

I checked the assembly with the verification option in sn.exe and got the following:

>sn.exe -v Serilog.Sinks.Splunk.dll

Microsoft (R) .NET Framework Strong Name Utility  Version 4.0.30319.0
Copyright (c) Microsoft Corporation.  All rights reserved.

Failed to verify assembly -- Strong name validation failed.

@mk-mrshll
Copy link

sn.exe -v Serilog.Sinks.Splunk.dll

I'm getting this same issue on my .Net Framework app using this package. Are there any workarounds @cxt240 @merbla ???

@merbla
Copy link
Contributor

merbla commented Jun 9, 2019

@cxt240 @mk-mrshll can you confirm if this behavior also exists in v3.1?

@cxt240
Copy link

cxt240 commented Jun 10, 2019

@merbla I pulled down 3.1.0 and ran sn -v against all 3 frameworks and can confirm that the same behavior exists for all 3.

@msmeby
Copy link

msmeby commented Jun 10, 2019

@merbla It looks like the failure is explicitly because there's no signature. Snooping around with snremove on 3.2.0 shows:

>snremove.exe -d Serilog.Sinks.Splunk.dll
Strong name signature in Serilog.Sinks.Splunk.dll:
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Oh man that looks suspicious ... Let's see what Serilog.dll itself says:

>snremove.exe -d Serilog.dll
Strong name signature in Serilog.dll:
CF 3C A1 05 B3 2E 8F 46 ED 92 B1 77 28 94 82 60
84 21 55 23 50 77 10 9F 46 0F AD EE 62 67 69 35
4A 80 50 F0 92 DA A1 6B 2C 30 CD 53 F0 85 C4 0E
64 CF C0 60 64 96 11 74 F3 C9 21 7B FD 3C 37 B3
EB 0B A8 6B 81 B4 8B B8 F3 D7 10 F7 CC 75 C0 80
32 2E 83 16 CA 07 5E DF 21 52 E6 46 0E 20 3D C2
8C 3A A6 6A 93 31 2E 7F 4A 6C 62 BF 40 27 F7 7B
BC 81 13 77 E5 23 FA 76 C7 80 15 73 42 FB 92 BC

For laughs, here's the other dependency, Serilog.Sinks.PeriodicBatching.dll:

>snremove.exe -d Serilog.Sinks.PeriodicBatching.dll
Strong name signature in Serilog.Sinks.PeriodicBatching.dll:
AC 31 61 BB 55 A9 DB CE 19 EC 0D DB 5F 18 8A 7D
38 F5 C6 44 C6 8B 90 AE AA 55 37 79 11 E2 0C AF
92 38 46 8F 4C B3 E7 A6 4D 5F 41 06 BC E6 AC A5
D3 D1 B2 C0 2C 02 67 D3 7F 07 C3 30 32 60 D3 98
3D 78 46 D8 2E BA 08 8B 37 2C D5 5C 37 D5 2E A8
74 EB 5D 36 CE FB DC C9 26 8F 87 70 0C 4C DE B5
A0 69 7A 05 94 B0 7C 62 E9 B9 5E 6F B2 16 FA 27
6A DE 97 7A 11 E2 4E 02 20 75 DF 20 EC DC AF 54

Both of these pass the dreaded sn -v test just fine.

For what it's worth, I'm only encountering this when I'm forced into a full framework 461 project. In Core and NetStandard, things work great. Hope this helps!

@mk-mrshll
Copy link

Yup, my research shows the same issue as @msmeby and @cxt240 . This is only a problem on .Net Framework apps.

@BrettJaner
Copy link
Contributor

BrettJaner commented Jun 12, 2019

If I remove the <PublicSign> attribute from Serilog.Sinks.Splunk.csproj, the assembly is signed correctly passing the sn.exe -v Serilog.Sinks.Splunk.dll test. Looks like the public sign flag is used to fake sign the assembly when a private key is not available. The Serilog.snk seems to be a private/public key pair tho.

@merbla do you think we are safe to remove the <PublicSign> attribute?

The core Serilog library conditionally applies this attribute like so

<PublicSign Condition=" '$(OS)' != 'Windows_NT' ">true</PublicSign>

$(OS) has two possible values, Windows_NT or Unix. So when Serilog is built on Unix, we'd see the same behavior/problem as we are seeing with Serilog.Sinks.Splunk today. Not sure why this would be desirable? But when Serilog is built on Windows the <PublicSign> is dropped and the assembly is signed correctly.

@magico13
Copy link

I'm seeing the same thing that @BrettJaner is seeing. Removing the PublicSign from the csproj does cause it to pass the sn.exe -v Serilog.Sinks.Splunk.dll test for me as well. Adding that back causes it to fail again.

@merbla
Copy link
Contributor

merbla commented Jun 17, 2019

Dev package now available at https://www.nuget.org/packages/Serilog.Sinks.Splunk

3.3.0-dev-xxx

@cxt240
Copy link

cxt240 commented Jun 17, 2019

@merbla I can confirm that the latest dev package (3.3.0-dev-00258) is properly signed (sn -V test). Testing using the package in an IIS hosted application also works now.

@merbla
Copy link
Contributor

merbla commented Jun 20, 2019

@cxt240 @magico13 @BrettJaner @mk-mrshll @msmeby a new release 3.3 is up on NuGet from this PR.

Apologies for the delay.

@merbla
Copy link
Contributor

merbla commented Jun 20, 2019

@merbla
Copy link
Contributor

merbla commented Nov 7, 2021

Closing as a part of larger Serilog contrib reorg

Checkout serilog/serilog#1627

@merbla merbla closed this as completed Nov 7, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

10 participants