[Security] Remove dependency on PeterO.Cbor package

[abergs]

Decrease dependency count by removing the dependency on PeterO.Cbor and instead copy the CBOR decode implementation.

Disadvantage: No automatic updates in case of bugs in implmentation
Advantage: No package poisoning.

[redhook62]

Yes, it would certainly be more reliable when integrating into a software.

[abergs]

@aseigler Do you think his code would be hard to copy?

Repo: https://github.com/peteroupc/CBOR
License is Public Domain, so he is probably OK with this.

[aseigler]

It looks like there is not much there, but it an actively maintained project so it is a double edged sword in that if we copy a point in time version of that source, we then become responsible for watching for important updates and copying those locally, whereas if we simply reference the library, it's up to the user to do all package maintenance. I can see both sides of the argument.

[redhook62]

I agree with you, it is actually not difficult to integrate. but I think I'll need a snapshot to deliver reliable server modules for production.
Thanks again to you for all the efforts you make

[aseigler]

I have a fix for this here aseigler@941bb2a and here aseigler@28e41cb but the PeterO.CBOR project file is configured to sign binaries with a PeterO.snk file which is missing.

I am guessing this is a very common problem. What's the best resolution for it these days?

[peteroupc]

I am guessing this is a very common problem. What's the best resolution for it these days?

That is a good question, and I have no answer for it, either.

[aseigler]

Best info I have found on the topic so far: https://github.com/dotnet/corefx/blob/master/Documentation/project-docs/strong-name-signing.md.

[peteroupc]

Thank you for that, but that document doesn't discuss the other way around: What issues can happen when a new version of a library is no longer strong-named when previous versions were? Fortunately, I am now working on version 4.0 of my CBOR library (in the 4.0 branch) and will consider removing the strong name from that version.

[abergs]

Thank you for joining in @peteroupc and for your work on the CBOR parser. We can definitely wait for the 4.0 package since this issue is a "long term" enhancement. The risk factor we want to remove is for example if someone were to gain control of your nuget package sometime down the line.

[aseigler]

The binding policy section kind of talks about a backward compatibility story, but not in a straightforward way like you describe.

In the no drop-in replacement section it plainly recommends checking in the private key, the immediate thought of which makes me very uncomfortable as a foil hat wearing security practitioner. I wish they worded that sentence differently.

[peteroupc]

For your information, the signing key for my project is now checked in.

[aseigler]

Thanks for letting us know!