Hello Will,

On Nov 1, 11:21 am, Will <[email protected]> wrote:
> I'm working on a cheesy in-house project to centralize both strong
> name and Authenticode signing of binaries.

The mono project has (opensource, MIT licensed) code that implements
both the sn.exe and signcode.exe tools.

> As it is cheesy, I'm more than happy to shell out and use signtool.exe
> to take care of the authenticode signing.  However, I cannot do this
> with sn.exe as you cannot specify the password in command line
> arguments.
>
> I was looking through the .NET API for loading and signing assemblies
> in code and it scares me; the p/invoking isn't that bad, but the lack
> of documentation is.  In addition, as I look into it I get the feeling
> I'm going down the rabbit hole, as each step recursively requires I go
> two steps deeper to accomplish.

Both use the Mono.Security.dll assembly, which is fully managed, and
works under Windows (and Linux...).

> While thinking about this task, I remembered reading about the awesome
> stuff Cecil can do with altering code in memory (e.g., AOP-style code
> injection).  I have been sniffing around the edges and read some pages
> in the wiki that suggests Cecil can strong-name sign binaries with a
> minimum of mess and fuss.  The example wasn't exactly what I needed,
> so I come to ask for help.
>
> This is what I need to do:
>
> 1) Run on Windows 7
> 2) Load an assembly targeting any version of the framework (well, 2.0
> and greater)
> 3) Load a public/private key pair from a password protected PFX file
> 4) Strong-name sign the assembly with this key pair
> 5) Save the newly signed assembly to a stream
> 6) Targeting .NET 4.0 CLR (this is a preference; I can target the 2.0
> CLR with only a little regret)
>
> Can this be done with Cecil?  

Maybe, but this is one (of the few things) that is far easier
without ;-)

> Can it be done to assemblies that target
> 4.0?

Without any problem. Stuff has not changed much since 1.0 (2.0 accept
strong name key larger than 1024 bits).

> Can I get teh coedz for steps 2 and 3?

Check mono's github and look for sn.cs, signcode.cs and Mono.Security/
*.cs

Have fun!
Sebastien

p.s. just remember that the signing order is important (I don't recall
the 'correct' order this morning) or one signature will break the next
one.

-- 
--
mono-cecil

Reply via email to