www-infrastructure-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jürgen Schmidt <jogischm...@googlemail.com>
Subject Re: Proposed: Code (.jar/.msi/binaries) Signing Service Offer
Date Thu, 28 Jun 2012 08:00:42 GMT
Hi Willaim,

I don't know if Dean is on the infra-dev list subscribed, probably not.
Means your answer will not reach Dean.

On 6/27/12 7:21 PM, William A. Rowe Jr. wrote:
> On 6/27/2012 11:11 AM, Jürgen Schmidt wrote:
>> sorry for jumping in but I hope that a short question is allowed.
> [Yes, that's why we launched the thread here for anyone interested in
> signing ASF binary objects.]
>> I am currently investigating in a reliable code signing process for
>> Apache OpenOffice (AOO) to become a good citizen in the Windows world
>> and especially the upcoming Windows 8.
>> AOO is bigger and we have to sign a lot of *.dll and *.exe during the
>> build, package the files in an msi/setup etc., sign the final setup bits
>> and finally sign a downloadable self extracting exe.
>> Because of the huge size and the many many files I believe that it makes
>> most sense to have a certificate on a dedicated build machine.
> Hi Jurgen; meaning no disrespect, that wouldn't be likely to happen in any
> case for reasons already spelled out on the list.  As I was designing the
> svn <-> signing service, I was actually laying it out that I myself would
> never have access to that key myself.
> On the other hand, I was designing it to unfold a .cab (or .msi), sign all
> the individual bits in that package, and refold it back into a .cab (and
> nested back into the .msi, which is then itself signed).  The same could
> be true for a Java .jar (.zip) binaries collection.

I see it more practical, we have several installation packages and we
support many languages and hopefully even more in the future. I talk not
about a few MBs only but GBs and a much more complicate process at all.

And of copurse I don't see really a problem to share for example a pfx
file + passcode between different persons who are responsible for the
signing part. And ideally each project is responsible for it's own cert
to limit the risk to the project.

I think everything at Apache is based on trust and I think people
understand the security issues. We talked about a serious and trustful
handling of the certificate and nobody talked about a broader sharing.

> Dean, a few additional questions for you from these thoughts;
> Can the code signing service accept a rolled up .msi or .jar (.zip) and
> sign multiple embedded bits?
> Is the logic out there for 'batching' a bunch of files together?
> In either case, will a single 'signing key' be used, or will each individual
> artifact be individually signed?
> Can .msi or .jar packages themselves be signed through the service?
> And finally, has anything changed in the past year about an organization having
> OU subordinate keys?  E.g. "O=Apache Software Foundation,OU=Apache Open Office"
> individual or department keys?  Last I understood, only a single org code
> signing cert would be made available.  We have approx 12 RM's at the ASF today
> would would like to begin signing packages, if one key/cert can be tied into one
> individual committer.  Or (in this case) can "O=Apache Open Office" be its own
> signing key?
>> But anyway whatever process in the end is working and possible, I would
>> like to ask if it is possible to get some kind of test certificate to
>> improve our testing.
> Or, perhaps test-integrate with the signing service, if it provides for batch
> submission?
>> My self signed certificate created with makecert is 1024 bit only and I
>> have read that a code signing cert have to be at least 2024 bits. I
>> don't know if that makes a difference in the Windows 8 App Certification
>> Kit.
> First off, 1024 is not 21'st +10y friendly.  The minimum cert size for any
> reliable cryptography is 2048 bits today (measured as an RSA style key,
> obviously DSS/DH and ECC use different logic and different 'safe' key
> sizes).  If you believe the US NIST, 2048 is going to hold us till 2030,
> but I won't be holding my breath on that one :)

I was saying that I don't know if the MS testing app for Windows 8
checks the certificates in detail and if it makes a difference here. I
never wanted to use a 1024 bit cert in reality ;-)


> Secondly, any pointers to local test signing certs for binaries and .msi
> packages on windows would be very helpful to me as well.
>> I think AOO with currently >6million downloads (since May 8th) can be a
>> good promotion for Symantec when people notice where the certificate
>> comes from.
> +1 :)

View raw message