Code signing of Windows .msi/.dll/.exe's for 2.6/3.0
Hi Barry, Friendly poke to see if there's been any progress on acquiring the relevant certificates such that we can code sign binaries on Windows for 2.6/3.0 ;-) Trent.
Trent Nelson schrieb:
Hi Barry,
Friendly poke to see if there's been any progress on acquiring the relevant certificates such that we can code sign binaries on Windows for 2.6/3.0 ;-)
Can you explain: * Why the binaries should be signed? * What is required to sign the binaries? * Which binaries should be signed? Christian
* Why the binaries should be signed?
Makes the installation process on Windows Vista and Server 2008 a little nicer; instead of getting an "unknown-executable-could- be-a-virus-aaaaaahhhh-watchout"-type dialog with a big red flag, you get a less threatening message saying that you're about to run something that's been digitally signed by the Python Software Foundation. (I've come across a few entities (NSA, government bodies, etc), who mandate that all installers/binaries they get must be digitally signed.)
* What is required to sign the binaries?
1. Obtain a code signing certificate from someone. I used VeriSign. You end up with an .spc and a .pvk file. You need to combine them into a single .pfx file via a tool called pvk2pfx.exe: Usage: pvk2pfx -pvk <pvk-file> [-pi <pvk-pswd>] -spc <spc-file> [-pfx <pfx-file> [-po <pfx-pswd>] [-f]] -pvk <pvk-file> - input PVK file name. -spc <spc-file> - input SPC file name. -pfx <pfx-file> - output PFX file name. -pi <pvk-pswd> - PVK password. -po <pfx-pswd> - PFX password; same as -pi if not given. -f - force overwrite existing PFX file. if -pfx option is not given, an export wizard will pop up. in this case, options -po and -f are ignored. C:\..> pvk2pfx.exe -pvk verisign-privatekey.pvk -pi ****** -spc onresolve-verisign.spc -po ****** -pfx onresolve-verisign.pfx 3. The resulting .pfx file, onresolve-verisign.pfx in this case, can then be installed as a 'Personal' certificate in Windows, using the Certificate Management facility (CertMgr.exe). When you install it, you provide a name that the certificate can be referred to by apps; in my case I just used 'VeriSign'. This name is used below by the signtool.exe app. 4. Sign the executable, MSI or DLL as follows: C:\..> signtool.exe sign /i "VeriSign" /d "Python 2.6.0" /du http://www.python.org /t http://timestamp.verisign.com/scripts/timstamp.dll Python-2.6.msi Successfully signed and timestamped: Python-2.6.msi
* Which binaries should be signed?
Personally, once I figured out the steps above, I hooked the signing process into all my Visual Studio projects as a post-build step, such that I sign all .exe and .dll files. Not really necessary, but eh, it does have the advantage of looking more professional (users can view properties on the .dll, for example, and see that it's been digitally signed by the PSF). Additionally, it prevents any tampering; Windows can detect if it's been altered in any way since it's been signed, and will flat out prevent it from being loaded/run if that's the case. Trent.
This is going to be a major administrative hassle. Obviously you have
to be extremely cautious with the private part of the certificate, or
it's worthless. That means that there will probably be only one person
who can sign binaries. That person would have also have to build all
the binaries -- signing binaries you retrieved from the internet
sounds like a complete bypassing of the security procedures. *And*
that person would forever have to be extremely cautious with the
machine on which the certificate resides, keeping it turned off and
locked away securely most of the time, or else risk that the machine
is infected by malware, again bypassing the point. While the chances
of ever signing something bad are low, the bad effects could be huge
(sort of like the risk of an earthquake as compared to a car crash).
I'm not at all sure that we are set up to do this right, and that it
is worth the minor inconvenience to users of having to acknowledge a
red-flag dialog. After all, they will be ack'ing such dialogs all the
time if they are at all used to downloading software from the
internet.
--Guido
On Thu, Apr 17, 2008 at 4:56 AM, Trent Nelson
* Why the binaries should be signed?
Makes the installation process on Windows Vista and Server 2008 a little nicer; instead of getting an "unknown-executable-could- be-a-virus-aaaaaahhhh-watchout"-type dialog with a big red flag, you get a less threatening message saying that you're about to run something that's been digitally signed by the Python Software Foundation. (I've come across a few entities (NSA, government bodies, etc), who mandate that all installers/binaries they get must be digitally signed.)
* What is required to sign the binaries?
1. Obtain a code signing certificate from someone. I used VeriSign. You end up with an .spc and a .pvk file. You need to combine them into a single .pfx file via a tool called pvk2pfx.exe:
Usage: pvk2pfx -pvk <pvk-file> [-pi <pvk-pswd>] -spc <spc-file> [-pfx <pfx-file> [-po <pfx-pswd>] [-f]]
-pvk <pvk-file> - input PVK file name. -spc <spc-file> - input SPC file name. -pfx <pfx-file> - output PFX file name. -pi <pvk-pswd> - PVK password. -po <pfx-pswd> - PFX password; same as -pi if not given. -f - force overwrite existing PFX file.
if -pfx option is not given, an export wizard will pop up. in this case, options -po and -f are ignored.
C:\..> pvk2pfx.exe -pvk verisign-privatekey.pvk -pi ****** -spc onresolve-verisign.spc -po ****** -pfx onresolve-verisign.pfx
3. The resulting .pfx file, onresolve-verisign.pfx in this case, can then be installed as a 'Personal' certificate in Windows, using the Certificate Management facility (CertMgr.exe). When you install it, you provide a name that the certificate can be referred to by apps; in my case I just used 'VeriSign'. This name is used below by the signtool.exe app.
4. Sign the executable, MSI or DLL as follows:
C:\..> signtool.exe sign /i "VeriSign" /d "Python 2.6.0" /du http://www.python.org /t http://timestamp.verisign.com/scripts/timstamp.dll Python-2.6.msi Successfully signed and timestamped: Python-2.6.msi
* Which binaries should be signed?
Personally, once I figured out the steps above, I hooked the signing process into all my Visual Studio projects as a post-build step, such that I sign all .exe and .dll files. Not really necessary, but eh, it does have the advantage of looking more professional (users can view properties on the .dll, for example, and see that it's been digitally signed by the PSF). Additionally, it prevents any tampering; Windows can detect if it's been altered in any way since it's been signed, and will flat out prevent it from being loaded/run if that's the case.
Trent.
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/guido%40python.org
-- --Guido van Rossum (home page: http://www.python.org/~guido/)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Apr 17, 2008, at 10:48 AM, Guido van Rossum wrote:
This is going to be a major administrative hassle. Obviously you have to be extremely cautious with the private part of the certificate, or it's worthless. That means that there will probably be only one person who can sign binaries. That person would have also have to build all the binaries -- signing binaries you retrieved from the internet sounds like a complete bypassing of the security procedures. *And* that person would forever have to be extremely cautious with the machine on which the certificate resides, keeping it turned off and locked away securely most of the time, or else risk that the machine is infected by malware, again bypassing the point. While the chances of ever signing something bad are low, the bad effects could be huge (sort of like the risk of an earthquake as compared to a car crash).
I'm not at all sure that we are set up to do this right, and that it is worth the minor inconvenience to users of having to acknowledge a red-flag dialog. After all, they will be ack'ing such dialogs all the time if they are at all used to downloading software from the internet.
MvL is leading this effort and is currently trying to get a code signing certificate (my attempts having utterly failed on the Mac ;). Please coordinate with him. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iQCVAwUBSAdnMHEjvBPtnXfVAQKkhQP/frCWs9sLcWyrAmDouCIq0n2X0B0TUbbG +tEUQVBj2hJ/CVnmc6PjyFNjOhlfhIv+BI544QhsvoAlC2OdQe9d8hHX8sqnPUJy lsm0gZ49ldqOhM91Q285RPtoELEEXQtfTYS2RUI/whNy+O/EDiRMVIDtNfaJOMgS j6zeojy8d4E= =m4aj -----END PGP SIGNATURE-----
Barry Warsaw schrieb:
MvL is leading this effort and is currently trying to get a code signing certificate (my attempts having utterly failed on the Mac ;). Please coordinate with him.
Apropos certificate, I like to suggest a PGP signing party for the next PyCon. :] Christian
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Apr 17, 2008, at 11:32 AM, Christian Heimes wrote:
Barry Warsaw schrieb:
MvL is leading this effort and is currently trying to get a code signing certificate (my attempts having utterly failed on the Mac ;). Please coordinate with him.
Apropos certificate, I like to suggest a PGP signing party for the next PyCon. :]
/me smacks his head for not doing one in 2008! - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iQCVAwUBSAdzS3EjvBPtnXfVAQJEygP/SNB+nQ+XfEnOprAji9pGj5YcmJJSoKb3 A8UFR3LAI3EK3CVzgIXEeFuQOKZV34p0nTabVM9FEzsPrIbvnbzp1k4V4Go1bK/G iBktzoG8F/VCmdbF7OjwBLb7O5GVVK1MRIO1KvdHp00lW311VYYMYdRuZ150lsct doLzOH7kriU= =LCTo -----END PGP SIGNATURE-----
>> Apropos certificate, I like to suggest a PGP signing party for the >> next PyCon. :] Barry> /me smacks his head for not doing one in 2008! Maybe a bunch of Python local user groups could be coaxed into having mini-signing parties during upcoming meetings, then let natural cross-fertilization between groups (such as Fitz visiting Google Mountain View or a few US folk attending EuroPython (mid-July), EuroSciPy (late July) or PyCon UK (September)) connect those groups. It wouldn't be as convenient as one big key signing party, but probably as effective in the long run. Skip
participants (5)
-
Barry Warsaw -
Christian Heimes -
Guido van Rossum -
skip＠pobox.com -
Trent Nelson