Sign the dynamically created NDesk.DBus.Proxies assembly
Bug #465716 reported by
tml
This bug affects 1 person
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| NDesk D-Bus |
Confirmed
|
Medium
|
Unassigned | ||
Bug Description
If a (signed) NDesk.DBus.dll is stored in the .NET GAC, also
NDesk.DBus.Proxies needs to be signed, otherwise we get
TypeLoadExceptions. (Mono apparently is more lenient.) So sign the
dynamic assembly.
A security-sensitive distributor might use a personal signing key for
the code assemblies (and not the ndesk.snk from the sources), and not
distribute the private key. A complete key pair is obviously needed to
sign the dynamically generated assembly. So use a separate key pair
stored in-line in TypeImplementer.cs, not that from ndesk.snk. Update
the PublicKey for NDesk.DBus.Proxies in AssemblyInfoSta
AssemblyInfo.cs.in accordingly.
Revision history for this message
| alp (atoker) wrote | #2 |
| Changed in ndesk-dbus: | |
| status: | New → Confirmed |
| importance: | Undecided → Medium |
To post a comment you must log in.
Thanks Tor,
This is definitely a problem. This fix is really quite heavy though, and I imagine a security-sensitive distributor isn't going to be happy with private keys inlined for self-signing code either.
DynamicMethod does allow for inherited security credentials, and we're already using this in some places. I think this breaks for the runtime-generated interface proxy implementations though -- wonder if there's a way to mark them as runtime-only so they can inherit permissions the same way as DynamicMethod?
If not, maybe it's a better idea to split out the lower level internal code into a public assembly with its own versioning at this point. This could be done without breaking the public ABI which has a tiny footprint.