www-infrastructure-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Hall <Richard_H...@symantec.com>
Subject RE: Proposed: Code (.jar/.msi/binaries) Signing Service Offer
Date Thu, 19 Jul 2012 13:50:21 GMT
Hi Dave,

Our hosted signing service does not currently provide the ability to sign Air applications,
but we do offer Code Signing certs for Adobe Air from our website:


Would this work for you?  Please let us know if you have any questions.



-----Original Message-----
From: Dave Fisher [mailto:dave2wave@comcast.net] 
Sent: Wednesday, July 18, 2012 7:12 PM
To: infrastructure-dev@apache.org
Cc: Dean Coclin; Richard Hall
Subject: Re: Proposed: Code (.jar/.msi/binaries) Signing Service Offer

On Jul 17, 2012, at 3:14 PM, William A. Rowe Jr. wrote:

> Richard, Dean, can you provide any insight? I just reviewed the infra-dev
> list history... if I missed your earlier reply I apologize in advance.


The Apache Flex podling would like to sign AIR applications as well:


Thanks for your consideration,

> Bill
> On 6/28/2012 6:18 PM, William A. Rowe Jr. wrote:
>> Q's for Dean inline;
>> 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.
>> 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 :)
>> 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