You are viewing a plain text version of this content. The canonical link for it is here.
Posted to infrastructure-dev@apache.org by Rob Weir <ro...@apache.org> on 2012/08/03 15:24:22 UTC
Re: Official code signing certificate
Adding another one to the list: With the MacOS Mountain Lion update,
code signing is now expected by default, by their "Gatekeeper"
feature.
Some possibly useful information on how Mozilla dealt with this in Firefox:
http://arstechnica.com/apple/2012/05/mozilla-preparing-mac-code-signing-for-mountain-lions-gatekeeper/
It sounds like in this case the certs come from Apple, not from a 3rd
party CA. So a solution based on a Symantec coding signing service
would not help there.
Regards,
-Rob
On Wed, Jul 18, 2012 at 6:01 PM, Om <bi...@gmail.com> wrote:
> I know that whatever process we will choose (if we choose one at all) it
>> will cause some work and I am willing to help where I can. But I am
>> really interested in bringing this forward and need some feedback or
>> opinions to continue.
>>
>
> I was informed about this discussion on the flex-dev list and I thought I
> would jump in with my thoughts. We are currently looking to create a
> similar set of installers packaged as AIR apps which needs to be signed in
> a very similar way described here. The process of signing AIR apps is
> described here [1]
>
> [1]
> http://livedocs.adobe.com/flex/3/html/help.html?content=distributing_apps_4.html
>
>>>>
>> >>> I like Roy's outline better. The AOO PPMC designs a build environment
>> >>> that can be verified and implemented by ASF contractors. The AOO PPMC
>> >>> validates the output of that process before distribution.
>> >>>
>> >>> Tell me that can be done, or why that is not possible, or describe
>> >>> something better.
>> >>>
>>
>
> The Apache Flex PPMC would be glad to help out with this process as well.
>
>
>> >> Proposal:
>> >> The proposal will be described by the example of AOO. But can be applied
>> >> on other projects who have demand for code signing as well!
>> >>
>> >> Set up a dedicated Windows build machine that has all the AOO build
>> >> requirements installed and AOO can be build like on a build bot. It can
>> >> be of course a special build bot. Only specific and authorized people
>> >> have access to this machine! I don't give comments if the machine is
>> >> accessible via network or not because this includes also some security
>> >> risks.
>> >>
>> >> When AOO plan to release a new version the project will request an
>> >> official build based on revision XY. The code version will be checked
>> >> out and build in the same way as on the build bots + some special
>> >> switches to enable code signing. The final bits will be verified by AOO
>> >> project members and as final step they will be signed by the release
>> >> manager as always (sha, asc, md5) and uploaded. Potentially several
>> >> iterations are necessary depending on the voting process on the RC's.
>>
>
> The only thing I would add here is that we would also need a Mac build
> machine to create the same installer for Macs. We have one code base that
> would get compiled into to the two different operating systems.
>
>
>> >>
>> >> #1
>> >> The certificate including the private key is installed on this machine
>> >> and any signing process can get access on the certificate.
>> >>
>> >> #2
>> >> The certificate is provided as a *.pfx file + pass code and is made
>> >> accessible to any signing process. The pfx file can be stored in a
>> >> secure place on this machine or on an external cryptographic device
>> >>
>> >>
>>
>
> I prefer #2 because of the above mentioned Mac build requirement.
>
>
>
>> >> The information about the setup of such a dedicated Windows machine and
>> >> the AOO specific build requirements are documented and of course AOO
>> >> project members would help with the setup if they get temporary access
>> >> or would provide at least support.
>>
>
> Again, the Flex project members would be glad to help out here as well.
>
>
>>>
>> >> I hope that is the information you are looking for.
>> >>
>> >>
>> >> Side note:
>> >> The other approach which is secure from my perspective as well is to
>> >> support project specific certificates and allow only a few trusted
>> >> people (e.g. release manager, project chair) access to the files.
>> >> Projects have to take care of their own dedicated build machines with
>> >> limited net access (to get the sources) for example.
>> >> It can be of course a mixed solution where projects with different
>> >> demand will be handled differently. A project where only a jar file have
>> >> to be signed can be handled of course different compared to AOO where we
>> >> have a complex multi step signing process with hundreds of files.
>> >>
>> >> I am looking forward to feedback.
>> >
>> > any opinions or general feedback?
>>
>
> This approach should work for us as well.
>
> Right now, we are using a self-signed certificate to sign our installer
> (before the official release PGP signing). The ant script finds the
> certificate and uses it appropriately. All that remains to be done is use
> a real signed certificate from a trusted certificate authority. The Apache
> Flex team would greatly appreciate it if we find a solution to this as soon
> as possible, so that we can use it for our upcoming first release.
>
> Thanks,
> Om
> Apache Flex PPMC Member
Re: Official code signing certificate
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
> On Fri, Mar 22, 2013 at 06:57:13PM +0200, Daniel Shahaf wrote:
> > How about only signing with the real certificate once three PMC
> > members PGP-signed the
> > binaries-built-against-the-self-signed-certificate.
As an RM and PMC member, I will never apply my PGP key to a binary
artifact where I was not completely in control of both verifying
the legitimacy of the sources (e.g. an approved tarball) and the
associated build environment. I have no way to inspect project
member Jay's binaries so I have no basis on which to sign them.
I *can* sign Jay's key because I trust him, but only Jay who had
built the binaries can attest to their validity. And if it turns
out I mistrusted Jay, I can revoke my sig, but if it turns out
I mistrusted Jay's binary I may be forced into a position of revoking
my own signing key as well.
On Tue, 26 Mar 2013 19:58:41 +0000
Daniel Shahaf <da...@apache.org> wrote:
> Note that after the binaries-signed-with-the-real-certificate are
> built, they ould have to be PGP-signed _again_ before they can be
> distributed.
Very true, I never expected anything different. For example, if you
want to validate your mirror copy on linux, using MS Authenticode
sigs would be unacceptably challenging.
Re: Official code signing certificate
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On Fri, 12 Apr 2013 13:32:20 +0200
Jürgen Schmidt <jo...@gmail.com> wrote:
> How we can we move forward? I would like suggest that we copy a
> Windows build bot VM and start working on a real scenario.
I'm certain that Infra will insist on an audited VM build. So it
would be a good idea to build an example VM, but it is much more
important to document every step for building up that box, every
tool and binary which is to be installed on that box with their
sources/origins, so that Infra can follow the process step by step
in creating the 'real' signing box.
Given that it could be as simple as corrupting a single make file
to compromise the key, running builds on the same signing VM seems
somewhat insane; see Sander's well thought out comments and Clint's
observations.
I am aware of applications of automated signing, but I don't know
of any org which physically does so on the same box as the builds
themselves, they are batched to a signing server with sources.
Re: Official code signing certificate
Posted by Jürgen Schmidt <jo...@gmail.com>.
On 4/12/13 3:08 PM, Ulrich Stärk wrote:
> On 12.04.2013 13:32, Jürgen Schmidt wrote:
>> On 3/26/13 8:58 PM, Daniel Shahaf wrote:
>>> On Fri, Mar 22, 2013 at 06:57:13PM +0200, Daniel Shahaf wrote:
>>>> How about only signing with the real certificate once three PMC members
>>>> PGP-signed the binaries-built-against-the-self-signed-certificate.
>>>
>>> Note that after the binaries-signed-with-the-real-certificate are built, they
>>> ould have to be PGP-signed _again_ before they can be distributed.
>>>
>>> That's because infra has tools and policies around signing that assume PGP, and
>>> we won't be changing them to suit N different ideas by M different PMCs.
>>>
>> adding pgp signature at the final step should be possible, we have to
>> validate the builds anyway.
>>
>> How we can we move forward? I would like suggest that we copy a Windows
>> build bot VM and start working on a real scenario.
>>
>> 1. preparing the AOO build env to sign all necessary files and bits and
>> use a test certificate (provided by the AOO PMC)
>>
>> 2. the test certificate is installed on the test VM
>>
>> 3. we define and work on a process to communicate which revision should
>> be used for the build and how the build is triggered. How the results
>> are provided etc.
>>
>> I believe we have to start working on it now and have to figure out what
>> works best in a practical scenario.
>>
>> What does other think about it?
>>
>
> I haven't seen Sander's concerns addressed yet. Of course you can start now and build a test-bed but
> Sander is right when he says that "the signing keys [should be surrounded] with the proper process
> and equipment".
I think I proposed to start doing exactly this. Start with something
real and stop talking only. I haven't seen any real new information in
the discussion. Valid concerns are repeated again and again but no
practical solution. I have no solution either but I believe we should
start working on it and should try to figure out what can work for us.
Maybe figure out that it have to be a machine physically stored in
someones office who is trusted enough and where the keys are stored on
an encrypted device or whatever. I even don't know for sure.
Or we figure out that ASF is not able to provide a secure infra
structure that can support all requirements. This can be a valid option
as well and then we have to look for another option.
Maybe a partner have a working infra structure and is interested in
helping us and can do the builds for us in a secure environment. I am
personally are open for everything and if I had 400$ I would simply buy
a cert on my own after the PMC and the ASF have approved that I can sign
it.
I can for sure provide AOO builds powered by Juergen Schmidt with a
valid cert. Important is that we have signed builds for our users.
Juergen
Re: Official code signing certificate
Posted by Ulrich Stärk <ul...@spielviel.de>.
On 12.04.2013 13:32, Jürgen Schmidt wrote:
> On 3/26/13 8:58 PM, Daniel Shahaf wrote:
>> On Fri, Mar 22, 2013 at 06:57:13PM +0200, Daniel Shahaf wrote:
>>> How about only signing with the real certificate once three PMC members
>>> PGP-signed the binaries-built-against-the-self-signed-certificate.
>>
>> Note that after the binaries-signed-with-the-real-certificate are built, they
>> ould have to be PGP-signed _again_ before they can be distributed.
>>
>> That's because infra has tools and policies around signing that assume PGP, and
>> we won't be changing them to suit N different ideas by M different PMCs.
>>
> adding pgp signature at the final step should be possible, we have to
> validate the builds anyway.
>
> How we can we move forward? I would like suggest that we copy a Windows
> build bot VM and start working on a real scenario.
>
> 1. preparing the AOO build env to sign all necessary files and bits and
> use a test certificate (provided by the AOO PMC)
>
> 2. the test certificate is installed on the test VM
>
> 3. we define and work on a process to communicate which revision should
> be used for the build and how the build is triggered. How the results
> are provided etc.
>
> I believe we have to start working on it now and have to figure out what
> works best in a practical scenario.
>
> What does other think about it?
>
I haven't seen Sander's concerns addressed yet. Of course you can start now and build a test-bed but
Sander is right when he says that "the signing keys [should be surrounded] with the proper process
and equipment".
Uli
Re: Official code signing certificate
Posted by Jürgen Schmidt <jo...@gmail.com>.
On 3/26/13 8:58 PM, Daniel Shahaf wrote:
> On Fri, Mar 22, 2013 at 06:57:13PM +0200, Daniel Shahaf wrote:
>> How about only signing with the real certificate once three PMC members
>> PGP-signed the binaries-built-against-the-self-signed-certificate.
>
> Note that after the binaries-signed-with-the-real-certificate are built, they
> ould have to be PGP-signed _again_ before they can be distributed.
>
> That's because infra has tools and policies around signing that assume PGP, and
> we won't be changing them to suit N different ideas by M different PMCs.
>
adding pgp signature at the final step should be possible, we have to
validate the builds anyway.
How we can we move forward? I would like suggest that we copy a Windows
build bot VM and start working on a real scenario.
1. preparing the AOO build env to sign all necessary files and bits and
use a test certificate (provided by the AOO PMC)
2. the test certificate is installed on the test VM
3. we define and work on a process to communicate which revision should
be used for the build and how the build is triggered. How the results
are provided etc.
I believe we have to start working on it now and have to figure out what
works best in a practical scenario.
What does other think about it?
Juergen
Re: Official code signing certificate
Posted by Daniel Shahaf <da...@apache.org>.
On Fri, Mar 22, 2013 at 06:57:13PM +0200, Daniel Shahaf wrote:
> How about only signing with the real certificate once three PMC members
> PGP-signed the binaries-built-against-the-self-signed-certificate.
Note that after the binaries-signed-with-the-real-certificate are built, they
ould have to be PGP-signed _again_ before they can be distributed.
That's because infra has tools and policies around signing that assume PGP, and
we won't be changing them to suit N different ideas by M different PMCs.
Re: Official code signing certificate
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Daniel Shahaf wrote on Tue, Mar 26, 2013 at 13:49:38 +0200:
> Jürgen Schmidt wrote on Tue, Mar 26, 2013 at 10:40:57 +0100:
> > On 3/25/13 11:56 PM, Daniel Shahaf wrote:
> > > Well that works but it has more moving parts: the artifacts need to
> > > encode the path@rev they were built from and then the build process has
> > > to extract those. Also the build process uses a new working copy so
> > > it'll rebuild everything from scratch: that (a) takes longer,
> > > (b) subjects you to the risk of upgraded system dependencies (libc, gcc,
> > > etc.) used in the new build.
> >
> > the baseline of the dedicated build machines should be maintained
> > carefully. We for example build on special Linux systems to ensure that
> > our binaries are worked on as many as possible Linux distros.
> >
>
> Well I'm not sure how possible that is. We do need to do OS upgrades
> sometimes, and if sufficiently many projects use the facility we'll
> almost always have one within the "built, but not built-with-cert"
> window yet.
>
> IOW I don't like the idea of projects being a blocking factor for doing
> OS upgrades. That will never work.
>
> Can one of the buildmasters weigh in here?
According to Niklas, we could probably keep a couple of dedicated VMs
sufficiently stable for the purposes of the "build twice" procedure.
Re: Official code signing certificate
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Jürgen Schmidt wrote on Tue, Mar 26, 2013 at 10:40:57 +0100:
> On 3/25/13 11:56 PM, Daniel Shahaf wrote:
> > Well that works but it has more moving parts: the artifacts need to
> > encode the path@rev they were built from and then the build process has
> > to extract those. Also the build process uses a new working copy so
> > it'll rebuild everything from scratch: that (a) takes longer,
> > (b) subjects you to the risk of upgraded system dependencies (libc, gcc,
> > etc.) used in the new build.
>
> the baseline of the dedicated build machines should be maintained
> carefully. We for example build on special Linux systems to ensure that
> our binaries are worked on as many as possible Linux distros.
>
Well I'm not sure how possible that is. We do need to do OS upgrades
sometimes, and if sufficiently many projects use the facility we'll
almost always have one within the "built, but not built-with-cert"
window yet.
IOW I don't like the idea of projects being a blocking factor for doing
OS upgrades. That will never work.
Can one of the buildmasters weigh in here?
> We in AOO retrieve already the svn revision during the build process and
> put this information in the about dialog for reference. And we retrieve
> "Last Changed Rev: *******" in our AOO related tree to avoid confusion.
>
You should use svnversion output, 'Last Changed Rev' won't deal with
three different conditions that svnversion does deal with. (_if_
svnversion output =~ /^\d+\n?$/, you can then use the 'Last Changed Rev'
if you prefer that.)
> >
> > Can you write this all down somewhere? A wiki page maybe, or a *.txt
> > file under (a new dir under)
> > https://svn.apache.org/repos/infra/infrastructure/trunk/projects/
> > (world-readable subtree).
>
> everybody is free to extend additional information on the already
> started wiki page http://wiki.apache.org/general/ASFCodeSigning
>
> I don't think we need a further one
+1
Amended request: add the agreed-upon details from this thread to that
page.
> By the way this page is not new and was proposed weeks ago to collect
> requirements and general information. One reason why I have restarted
> the discussion in this thread.
Re: Official code signing certificate
Posted by janI <ja...@apache.org>.
On 26 May 2013 09:53, Mechtilde <oo...@mechtilde.de> wrote:
> Hello Andrea,
>
> Am 26.05.2013 00:07, schrieb Andrea Pescetti:
> > janI wrote:
> >> in all fairness jsc and rob have worked with this for over a
> >> year, so it would be more fair to have them do it, and I do not want to
> >> come "in between".
> >
> > This is a good summary written by Juergen:
> > http://wiki.apache.org/general/ASFCodeSigning
> >
> > Note that at FOSDEM we were (inconclusively) discussing with Cacert an
> > SSL certificate (to be used for serving HTTPS traffic), not a
> > code-signing certificate (to be used for signing released files).
>
> This can be done with the same Certificat.
>
Technically it could be the same certificate but SSL certificates are
handled by infra, and codesigning might be (still a discussion) be handled
by the projects, making it impractical and less secure to have a single
certificate.
Work on the SSL certificate is ongoing. Code signing certificate seems to
be a longer discussion, where the technical part is the least of the
discussion.
rgds
jan I.
>
> Kind regards
>
> Mechtilde
> >
> > Regards,
> > Andrea.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> > For additional commands, e-mail: dev-help@openoffice.apache.org
> >
> >
>
>
>
Re: Official code signing certificate
Posted by Mechtilde <oo...@mechtilde.de>.
Hello Andrea,
Am 26.05.2013 00:07, schrieb Andrea Pescetti:
> janI wrote:
>> in all fairness jsc and rob have worked with this for over a
>> year, so it would be more fair to have them do it, and I do not want to
>> come "in between".
>
> This is a good summary written by Juergen:
> http://wiki.apache.org/general/ASFCodeSigning
>
> Note that at FOSDEM we were (inconclusively) discussing with Cacert an
> SSL certificate (to be used for serving HTTPS traffic), not a
> code-signing certificate (to be used for signing released files).
This can be done with the same Certificat.
Kind regards
Mechtilde
>
> Regards,
> Andrea.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
>
Re: Official code signing certificate
Posted by Andrea Pescetti <pe...@apache.org>.
janI wrote:
> in all fairness jsc and rob have worked with this for over a
> year, so it would be more fair to have them do it, and I do not want to
> come "in between".
This is a good summary written by Juergen:
http://wiki.apache.org/general/ASFCodeSigning
Note that at FOSDEM we were (inconclusively) discussing with Cacert an
SSL certificate (to be used for serving HTTPS traffic), not a
code-signing certificate (to be used for signing released files).
Regards,
Andrea.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Official code signing certificate
Posted by janI <ja...@apache.org>.
On 25 May 2013 18:01, Mechtilde <oo...@mechtilde.de> wrote:
> Hello Jan,
>
> can you give me a short description what we/you need and what are the
> problems with apache infrastructure.
>
I could, but in all fairness jsc and rob have worked with this for over a
year, so it would be more fair to have them do it, and I do not want to
come "in between".
>
> I'm not so familar with the apache infrastructure to understand all
> things of the thread.
>
> Then I will give this information to people who are familar with
> organisation assurance by Cacert.
>
Thx I hope jsc and/or rob will pick it up.
rgds
jan I.
>
> Thanks
>
> Mechtilde
>
>
> Am 25.05.2013 15:38, schrieb janI:
> > On 25 May 2013 15:31, Mechtilde <oo...@mechtilde.de> wrote:
> >
> >> Hello,
> >>
> >> what about an organisation assurance by Cacert.
> >>
> >> At FOSDEM 2013 there are some discussions with people from cacert.
> >>
> >> If you need more informations and contacts I will act as an agent.
> >>
> > If you can get some information, I would like to read it, and pass it on
> to
> > infra.
> >
> > rgds
> > jan I.
> >
> >
> >>
> >> Let me know
> >>
> >> Kind regards
> >>
> >> Mechtilde
> >>
> >>
> >> Am 25.05.2013 15:22, schrieb janI:
> >>> On 25 May 2013 12:04, Andrea Pescetti <pe...@apache.org> wrote:
> >>>
> >>>> Dave Fisher wrote:
> >>>>
> >>>>> The main concern that the ASF has with digitally signing with a
> >>>>> singular apache.org certificate for the whole foundation is keeping
> >>>>> it in strict control. For some this means physical machines. This is
> >>>>> a high bar.
> >>>>> I wonder if the ASF would allow AOO to experiment with an
> >>>>> OpenOffice.org codesigning certificate?
> >>>>>
> >>>>
> >>>> If there is willingness to experiment on this, for sure the OpenOffice
> >>>> project would benefit from it. It is clear what the goal is: it would
> be
> >>>> beneficial to our users if the Windows and Mac binaries were signed,
> to
> >>>> avoid potentially confusing security warnings. And it would be very
> >> good to
> >>>> have it by version 4.0. And the problem is much more with policy (or,
> in
> >>>> general, with security/infra concerns) than technology.
> >>>>
> >>>
> >>> Seen with infra eyes the major problem is to find a working procedure
> >> that
> >>> are secure, meaning only few people have access to signing, the
> >> discussions
> >>> there have been very little on politics
> >>>
> >>>>
> >>>> We never thought we would get the wildcard certificate, but hey who
> >>>>> knows?
> >>>>>
> >>>>
> >>>> I thought it was hard, but not impossible. But honestly, it also
> raised
> >>>> fewer concerns than a code-signing certificate.
> >>>>
> >>>> On May 24, 2013, at 2:43 PM, Rob Weir wrote:
> >>>>>
> >>>>>> And I should mention that pushing the code signing side is
> >>>>>> probably premature until we have the build side more solidly
> >>>>>> automated.
> >>>>>>
> >>>>>
> >>>> This has been Infra's approach in the current discussion. For those
> not
> >>>> following that list: see http://mail-archives.apache.
> >> **org/mod_mbox/www-**
> >>>> infrastructure-dev/<
> >> http://mail-archives.apache.org/mod_mbox/www-infrastructure-dev/>(you
> >> will see the "code signing" thread appearing in most of the recent
> >>>> months' archives).
> >>>>
> >>>> On Fri, May 24, 2013 at 5:01 PM, janI wrote:
> >>>>>>>
> >>>>>>>> I am sorry I defended our viewpoint, and made this list aware
> >>>>>>>> that there are other projects with similar needs. You just
> >>>>>>>> managed to kill the messenger, next time this issue is
> >>>>>>>> discussed on IRC, I will refer to this thread and keep silent.
> >>>>>>>>
> >>>>>>>
> >>>> No, no need for this. Of course you should discuss options that would
> be
> >>>> beneficial to the OpenOffice project, and it's well-known that you do
> >> get
> >>>> things done, a lot of them. In this case, the ongoing frustration that
> >> you
> >>>> see reflected in some messages is due to the fact that the long
> >> discussion
> >>>> on infra-dev made it clear, so far, that there are infrastructure
> >>>> requirements that must be satisfied as a prerequisite for code
> signing.
> >>>>
> >>>> So, while code-signing is the ultimate goal, with the current approach
> >> we
> >>>> would have to get other infrastructure work done before it (namely,
> >> improve
> >>>> buildbots). Unless we have, or find, a way to work around it to
> properly
> >>>> sign the 4.0 release.
> >>>>
> >>>
> >>> Thx for the kind words. Actually buildbots is only one way of doing
> this,
> >>> and not the way you find in many big companies. In many companies (see
> >>> adobe as the example) the built binaries are delivered to a central
> >>> signing server, where only very few people have access. The project
> >>> guarantees for the quality of the binary being delivered, please
> remember
> >>> using the buildbot it still no guarantee against malicous code, a
> >> committer
> >>> could easily insert that over time. Connecting buildbot and signing
> would
> >>> mean allowing many people having access to the certificate, which is a
> >> risk
> >>> in itself.
> >>>
> >>> A central signing server has many advantages, but one big disadvantage
> it
> >>> puts more load in infra, something they are very nervours about.
> >>>
> >>> rgds
> >>> jan I.
> >>>
> >>> Regards,
> >>>> Andrea.
>
>
>
>
>
Re: Official code signing certificate
Posted by Mechtilde <oo...@mechtilde.de>.
Hello Jan,
can you give me a short description what we/you need and what are the
problems with apache infrastructure.
I'm not so familar with the apache infrastructure to understand all
things of the thread.
Then I will give this information to people who are familar with
organisation assurance by Cacert.
Thanks
Mechtilde
Am 25.05.2013 15:38, schrieb janI:
> On 25 May 2013 15:31, Mechtilde <oo...@mechtilde.de> wrote:
>
>> Hello,
>>
>> what about an organisation assurance by Cacert.
>>
>> At FOSDEM 2013 there are some discussions with people from cacert.
>>
>> If you need more informations and contacts I will act as an agent.
>>
> If you can get some information, I would like to read it, and pass it on to
> infra.
>
> rgds
> jan I.
>
>
>>
>> Let me know
>>
>> Kind regards
>>
>> Mechtilde
>>
>>
>> Am 25.05.2013 15:22, schrieb janI:
>>> On 25 May 2013 12:04, Andrea Pescetti <pe...@apache.org> wrote:
>>>
>>>> Dave Fisher wrote:
>>>>
>>>>> The main concern that the ASF has with digitally signing with a
>>>>> singular apache.org certificate for the whole foundation is keeping
>>>>> it in strict control. For some this means physical machines. This is
>>>>> a high bar.
>>>>> I wonder if the ASF would allow AOO to experiment with an
>>>>> OpenOffice.org codesigning certificate?
>>>>>
>>>>
>>>> If there is willingness to experiment on this, for sure the OpenOffice
>>>> project would benefit from it. It is clear what the goal is: it would be
>>>> beneficial to our users if the Windows and Mac binaries were signed, to
>>>> avoid potentially confusing security warnings. And it would be very
>> good to
>>>> have it by version 4.0. And the problem is much more with policy (or, in
>>>> general, with security/infra concerns) than technology.
>>>>
>>>
>>> Seen with infra eyes the major problem is to find a working procedure
>> that
>>> are secure, meaning only few people have access to signing, the
>> discussions
>>> there have been very little on politics
>>>
>>>>
>>>> We never thought we would get the wildcard certificate, but hey who
>>>>> knows?
>>>>>
>>>>
>>>> I thought it was hard, but not impossible. But honestly, it also raised
>>>> fewer concerns than a code-signing certificate.
>>>>
>>>> On May 24, 2013, at 2:43 PM, Rob Weir wrote:
>>>>>
>>>>>> And I should mention that pushing the code signing side is
>>>>>> probably premature until we have the build side more solidly
>>>>>> automated.
>>>>>>
>>>>>
>>>> This has been Infra's approach in the current discussion. For those not
>>>> following that list: see http://mail-archives.apache.
>> **org/mod_mbox/www-**
>>>> infrastructure-dev/<
>> http://mail-archives.apache.org/mod_mbox/www-infrastructure-dev/>(you
>> will see the "code signing" thread appearing in most of the recent
>>>> months' archives).
>>>>
>>>> On Fri, May 24, 2013 at 5:01 PM, janI wrote:
>>>>>>>
>>>>>>>> I am sorry I defended our viewpoint, and made this list aware
>>>>>>>> that there are other projects with similar needs. You just
>>>>>>>> managed to kill the messenger, next time this issue is
>>>>>>>> discussed on IRC, I will refer to this thread and keep silent.
>>>>>>>>
>>>>>>>
>>>> No, no need for this. Of course you should discuss options that would be
>>>> beneficial to the OpenOffice project, and it's well-known that you do
>> get
>>>> things done, a lot of them. In this case, the ongoing frustration that
>> you
>>>> see reflected in some messages is due to the fact that the long
>> discussion
>>>> on infra-dev made it clear, so far, that there are infrastructure
>>>> requirements that must be satisfied as a prerequisite for code signing.
>>>>
>>>> So, while code-signing is the ultimate goal, with the current approach
>> we
>>>> would have to get other infrastructure work done before it (namely,
>> improve
>>>> buildbots). Unless we have, or find, a way to work around it to properly
>>>> sign the 4.0 release.
>>>>
>>>
>>> Thx for the kind words. Actually buildbots is only one way of doing this,
>>> and not the way you find in many big companies. In many companies (see
>>> adobe as the example) the built binaries are delivered to a central
>>> signing server, where only very few people have access. The project
>>> guarantees for the quality of the binary being delivered, please remember
>>> using the buildbot it still no guarantee against malicous code, a
>> committer
>>> could easily insert that over time. Connecting buildbot and signing would
>>> mean allowing many people having access to the certificate, which is a
>> risk
>>> in itself.
>>>
>>> A central signing server has many advantages, but one big disadvantage it
>>> puts more load in infra, something they are very nervours about.
>>>
>>> rgds
>>> jan I.
>>>
>>> Regards,
>>>> Andrea.
Re: Official code signing certificate
Posted by janI <ja...@apache.org>.
On 25 May 2013 15:31, Mechtilde <oo...@mechtilde.de> wrote:
> Hello,
>
> what about an organisation assurance by Cacert.
>
> At FOSDEM 2013 there are some discussions with people from cacert.
>
> If you need more informations and contacts I will act as an agent.
>
If you can get some information, I would like to read it, and pass it on to
infra.
rgds
jan I.
>
> Let me know
>
> Kind regards
>
> Mechtilde
>
>
> Am 25.05.2013 15:22, schrieb janI:
> > On 25 May 2013 12:04, Andrea Pescetti <pe...@apache.org> wrote:
> >
> >> Dave Fisher wrote:
> >>
> >>> The main concern that the ASF has with digitally signing with a
> >>> singular apache.org certificate for the whole foundation is keeping
> >>> it in strict control. For some this means physical machines. This is
> >>> a high bar.
> >>> I wonder if the ASF would allow AOO to experiment with an
> >>> OpenOffice.org codesigning certificate?
> >>>
> >>
> >> If there is willingness to experiment on this, for sure the OpenOffice
> >> project would benefit from it. It is clear what the goal is: it would be
> >> beneficial to our users if the Windows and Mac binaries were signed, to
> >> avoid potentially confusing security warnings. And it would be very
> good to
> >> have it by version 4.0. And the problem is much more with policy (or, in
> >> general, with security/infra concerns) than technology.
> >>
> >
> > Seen with infra eyes the major problem is to find a working procedure
> that
> > are secure, meaning only few people have access to signing, the
> discussions
> > there have been very little on politics
> >
> >>
> >> We never thought we would get the wildcard certificate, but hey who
> >>> knows?
> >>>
> >>
> >> I thought it was hard, but not impossible. But honestly, it also raised
> >> fewer concerns than a code-signing certificate.
> >>
> >> On May 24, 2013, at 2:43 PM, Rob Weir wrote:
> >>>
> >>>> And I should mention that pushing the code signing side is
> >>>> probably premature until we have the build side more solidly
> >>>> automated.
> >>>>
> >>>
> >> This has been Infra's approach in the current discussion. For those not
> >> following that list: see http://mail-archives.apache.
> **org/mod_mbox/www-**
> >> infrastructure-dev/<
> http://mail-archives.apache.org/mod_mbox/www-infrastructure-dev/>(you
> will see the "code signing" thread appearing in most of the recent
> >> months' archives).
> >>
> >> On Fri, May 24, 2013 at 5:01 PM, janI wrote:
> >>>>>
> >>>>>> I am sorry I defended our viewpoint, and made this list aware
> >>>>>> that there are other projects with similar needs. You just
> >>>>>> managed to kill the messenger, next time this issue is
> >>>>>> discussed on IRC, I will refer to this thread and keep silent.
> >>>>>>
> >>>>>
> >> No, no need for this. Of course you should discuss options that would be
> >> beneficial to the OpenOffice project, and it's well-known that you do
> get
> >> things done, a lot of them. In this case, the ongoing frustration that
> you
> >> see reflected in some messages is due to the fact that the long
> discussion
> >> on infra-dev made it clear, so far, that there are infrastructure
> >> requirements that must be satisfied as a prerequisite for code signing.
> >>
> >> So, while code-signing is the ultimate goal, with the current approach
> we
> >> would have to get other infrastructure work done before it (namely,
> improve
> >> buildbots). Unless we have, or find, a way to work around it to properly
> >> sign the 4.0 release.
> >>
> >
> > Thx for the kind words. Actually buildbots is only one way of doing this,
> > and not the way you find in many big companies. In many companies (see
> > adobe as the example) the built binaries are delivered to a central
> > signing server, where only very few people have access. The project
> > guarantees for the quality of the binary being delivered, please remember
> > using the buildbot it still no guarantee against malicous code, a
> committer
> > could easily insert that over time. Connecting buildbot and signing would
> > mean allowing many people having access to the certificate, which is a
> risk
> > in itself.
> >
> > A central signing server has many advantages, but one big disadvantage it
> > puts more load in infra, something they are very nervours about.
> >
> > rgds
> > jan I.
> >
> > Regards,
> >> Andrea.
> >>
> >>
> ------------------------------**------------------------------**---------
> >> To unsubscribe, e-mail: dev-unsubscribe@openoffice.**apache.org<
> dev-unsubscribe@openoffice.apache.org>
> >> For additional commands, e-mail: dev-help@openoffice.apache.org
> >>
> >>
> >
>
>
>
Re: Official code signing certificate
Posted by Mechtilde <oo...@mechtilde.de>.
Hello,
what about an organisation assurance by Cacert.
At FOSDEM 2013 there are some discussions with people from cacert.
If you need more informations and contacts I will act as an agent.
Let me know
Kind regards
Mechtilde
Am 25.05.2013 15:22, schrieb janI:
> On 25 May 2013 12:04, Andrea Pescetti <pe...@apache.org> wrote:
>
>> Dave Fisher wrote:
>>
>>> The main concern that the ASF has with digitally signing with a
>>> singular apache.org certificate for the whole foundation is keeping
>>> it in strict control. For some this means physical machines. This is
>>> a high bar.
>>> I wonder if the ASF would allow AOO to experiment with an
>>> OpenOffice.org codesigning certificate?
>>>
>>
>> If there is willingness to experiment on this, for sure the OpenOffice
>> project would benefit from it. It is clear what the goal is: it would be
>> beneficial to our users if the Windows and Mac binaries were signed, to
>> avoid potentially confusing security warnings. And it would be very good to
>> have it by version 4.0. And the problem is much more with policy (or, in
>> general, with security/infra concerns) than technology.
>>
>
> Seen with infra eyes the major problem is to find a working procedure that
> are secure, meaning only few people have access to signing, the discussions
> there have been very little on politics
>
>>
>> We never thought we would get the wildcard certificate, but hey who
>>> knows?
>>>
>>
>> I thought it was hard, but not impossible. But honestly, it also raised
>> fewer concerns than a code-signing certificate.
>>
>> On May 24, 2013, at 2:43 PM, Rob Weir wrote:
>>>
>>>> And I should mention that pushing the code signing side is
>>>> probably premature until we have the build side more solidly
>>>> automated.
>>>>
>>>
>> This has been Infra's approach in the current discussion. For those not
>> following that list: see http://mail-archives.apache.**org/mod_mbox/www-**
>> infrastructure-dev/<http://mail-archives.apache.org/mod_mbox/www-infrastructure-dev/>(you will see the "code signing" thread appearing in most of the recent
>> months' archives).
>>
>> On Fri, May 24, 2013 at 5:01 PM, janI wrote:
>>>>>
>>>>>> I am sorry I defended our viewpoint, and made this list aware
>>>>>> that there are other projects with similar needs. You just
>>>>>> managed to kill the messenger, next time this issue is
>>>>>> discussed on IRC, I will refer to this thread and keep silent.
>>>>>>
>>>>>
>> No, no need for this. Of course you should discuss options that would be
>> beneficial to the OpenOffice project, and it's well-known that you do get
>> things done, a lot of them. In this case, the ongoing frustration that you
>> see reflected in some messages is due to the fact that the long discussion
>> on infra-dev made it clear, so far, that there are infrastructure
>> requirements that must be satisfied as a prerequisite for code signing.
>>
>> So, while code-signing is the ultimate goal, with the current approach we
>> would have to get other infrastructure work done before it (namely, improve
>> buildbots). Unless we have, or find, a way to work around it to properly
>> sign the 4.0 release.
>>
>
> Thx for the kind words. Actually buildbots is only one way of doing this,
> and not the way you find in many big companies. In many companies (see
> adobe as the example) the built binaries are delivered to a central
> signing server, where only very few people have access. The project
> guarantees for the quality of the binary being delivered, please remember
> using the buildbot it still no guarantee against malicous code, a committer
> could easily insert that over time. Connecting buildbot and signing would
> mean allowing many people having access to the certificate, which is a risk
> in itself.
>
> A central signing server has many advantages, but one big disadvantage it
> puts more load in infra, something they are very nervours about.
>
> rgds
> jan I.
>
> Regards,
>> Andrea.
>>
>> ------------------------------**------------------------------**---------
>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.**apache.org<de...@openoffice.apache.org>
>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>
>>
>
Re: Official code signing certificate
Posted by janI <ja...@apache.org>.
On 25 May 2013 12:04, Andrea Pescetti <pe...@apache.org> wrote:
> Dave Fisher wrote:
>
>> The main concern that the ASF has with digitally signing with a
>> singular apache.org certificate for the whole foundation is keeping
>> it in strict control. For some this means physical machines. This is
>> a high bar.
>> I wonder if the ASF would allow AOO to experiment with an
>> OpenOffice.org codesigning certificate?
>>
>
> If there is willingness to experiment on this, for sure the OpenOffice
> project would benefit from it. It is clear what the goal is: it would be
> beneficial to our users if the Windows and Mac binaries were signed, to
> avoid potentially confusing security warnings. And it would be very good to
> have it by version 4.0. And the problem is much more with policy (or, in
> general, with security/infra concerns) than technology.
>
Seen with infra eyes the major problem is to find a working procedure that
are secure, meaning only few people have access to signing, the discussions
there have been very little on politics
>
> We never thought we would get the wildcard certificate, but hey who
>> knows?
>>
>
> I thought it was hard, but not impossible. But honestly, it also raised
> fewer concerns than a code-signing certificate.
>
> On May 24, 2013, at 2:43 PM, Rob Weir wrote:
>>
>>> And I should mention that pushing the code signing side is
>>> probably premature until we have the build side more solidly
>>> automated.
>>>
>>
> This has been Infra's approach in the current discussion. For those not
> following that list: see http://mail-archives.apache.**org/mod_mbox/www-**
> infrastructure-dev/<http://mail-archives.apache.org/mod_mbox/www-infrastructure-dev/>(you will see the "code signing" thread appearing in most of the recent
> months' archives).
>
> On Fri, May 24, 2013 at 5:01 PM, janI wrote:
>>>>
>>>>> I am sorry I defended our viewpoint, and made this list aware
>>>>> that there are other projects with similar needs. You just
>>>>> managed to kill the messenger, next time this issue is
>>>>> discussed on IRC, I will refer to this thread and keep silent.
>>>>>
>>>>
> No, no need for this. Of course you should discuss options that would be
> beneficial to the OpenOffice project, and it's well-known that you do get
> things done, a lot of them. In this case, the ongoing frustration that you
> see reflected in some messages is due to the fact that the long discussion
> on infra-dev made it clear, so far, that there are infrastructure
> requirements that must be satisfied as a prerequisite for code signing.
>
> So, while code-signing is the ultimate goal, with the current approach we
> would have to get other infrastructure work done before it (namely, improve
> buildbots). Unless we have, or find, a way to work around it to properly
> sign the 4.0 release.
>
Thx for the kind words. Actually buildbots is only one way of doing this,
and not the way you find in many big companies. In many companies (see
adobe as the example) the built binaries are delivered to a central
signing server, where only very few people have access. The project
guarantees for the quality of the binary being delivered, please remember
using the buildbot it still no guarantee against malicous code, a committer
could easily insert that over time. Connecting buildbot and signing would
mean allowing many people having access to the certificate, which is a risk
in itself.
A central signing server has many advantages, but one big disadvantage it
puts more load in infra, something they are very nervours about.
rgds
jan I.
Regards,
> Andrea.
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.**apache.org<de...@openoffice.apache.org>
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
>
Re: Official code signing certificate
Posted by Andrea Pescetti <pe...@apache.org>.
Dave Fisher wrote:
> The main concern that the ASF has with digitally signing with a
> singular apache.org certificate for the whole foundation is keeping
> it in strict control. For some this means physical machines. This is
> a high bar.
> I wonder if the ASF would allow AOO to experiment with an
> OpenOffice.org codesigning certificate?
If there is willingness to experiment on this, for sure the OpenOffice
project would benefit from it. It is clear what the goal is: it would be
beneficial to our users if the Windows and Mac binaries were signed, to
avoid potentially confusing security warnings. And it would be very good
to have it by version 4.0. And the problem is much more with policy (or,
in general, with security/infra concerns) than technology.
> We never thought we would get the wildcard certificate, but hey who
> knows?
I thought it was hard, but not impossible. But honestly, it also raised
fewer concerns than a code-signing certificate.
> On May 24, 2013, at 2:43 PM, Rob Weir wrote:
>> And I should mention that pushing the code signing side is
>> probably premature until we have the build side more solidly
>> automated.
This has been Infra's approach in the current discussion. For those not
following that list: see
http://mail-archives.apache.org/mod_mbox/www-infrastructure-dev/ (you
will see the "code signing" thread appearing in most of the recent
months' archives).
>>> On Fri, May 24, 2013 at 5:01 PM, janI wrote:
>>>> I am sorry I defended our viewpoint, and made this list aware
>>>> that there are other projects with similar needs. You just
>>>> managed to kill the messenger, next time this issue is
>>>> discussed on IRC, I will refer to this thread and keep silent.
No, no need for this. Of course you should discuss options that would be
beneficial to the OpenOffice project, and it's well-known that you do
get things done, a lot of them. In this case, the ongoing frustration
that you see reflected in some messages is due to the fact that the long
discussion on infra-dev made it clear, so far, that there are
infrastructure requirements that must be satisfied as a prerequisite for
code signing.
So, while code-signing is the ultimate goal, with the current approach
we would have to get other infrastructure work done before it (namely,
improve buildbots). Unless we have, or find, a way to work around it to
properly sign the 4.0 release.
Regards,
Andrea.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Official code signing certificate
Posted by janI <ja...@apache.org>.
On 25 May 2013 22:02, Rob Weir <ro...@apache.org> wrote:
> On Sat, May 25, 2013 at 3:17 PM, janI <ja...@apache.org> wrote:
> > On 25 May 2013 20:40, Rob Weir <ro...@apache.org> wrote:
> >
> >> On Fri, May 24, 2013 at 6:17 PM, Dave Fisher <da...@comcast.net>
> >> wrote:
> >> > Hi Rob,
> >> >
> >> > This is a very well written summary of the situation with Code
> Signing.
> >> >
> >> > The main concern that the ASF has with digitally signing with a
> singular
> >> apache.org certificate for the whole foundation is keeping it in strict
> >> control. For some this means physical machines. This is a high bar.
> >> >
> >> > I wonder if the ASF would allow AOO to experiment with an
> OpenOffice.org
> >> codesigning certificate?
> >> >
> >>
> >> There are a few basic technological and organizational risks:
> >>
> >> 1) When the ASF signs something, what does it mean for the ASF? Is
> >> there any liability assumed by the ASF, for example, if the
> >> certificate is misused? Due to negligence? What is the standard of
> >> care we must apply to make this risk acceptable?
> >>
> >
> > In my opinion misuse of a certicate (no matter if project or asf wide)
> > would have a huge negative impact on the foundation. We would be in the
> > press very fast being compared with hackers.
> >
> > I know we need the certificate, but it must be done in a way where the
> > foundation is put at a minimal risk.
> >
>
> I think you are missing the point. This is not just a matter of
> limiting risk. The question is whether, as a foundation whether the
> ASF wants to assume any (even limited) liability. What is the ASF
> willing/able to agree to, when acquiring a cert, that is compatible
> with its charitable mission and non-profit status.
>
> In my head ASF already have some form of liability. Without digital
signing the risk of someone changing the release packages are even higher.
Seem from that point of view the usage of codesigning in whatever way is
itself limiting the liability (or risk of bad press/image etc).
> >
> >>
> >> 2) How do we ensure the certificate is used to sign only approved
> releases?
> >>
> >
> > Maybe like many organisations do, the teams (projects) submit their
> release
> > (binary copy) to a central server, where a very small set of people
> handle
> > the signing.
> >
>
> The ASF is not at all like a hierarchical corporation with a central
> build lab. Releases are decentralized. Now certainly one way of
> moving this forward would be to have the ASF change how projects do
> releases, but that is probably the hardest way to move this forward.
>
I did not talk about changing the way projects do releases, but simply an
extra step (like if you want a mac version you have to build on a mac).
>
> > Approved releases is a dangerous word, but could be easily achived by
> only
> > allowing pmc chair to send the release. Please remember that just because
> > it is a an approved release it can contain malious code, some of the most
> > successfull hacks was done at source level.
> >
>
> In theory this is already prevented by verifying SVN logs, which
> record all changes and which is public. Signing doesn't change that
> part of the release equation.
>
It is correct that signing does not change that a single millimeter, but it
seems many believes it does, and I just wanted to point that out. No
release can ever be better than the source behind it.
> >
> >> 3) How to we ensure control of the certificate ?
> >>
> >
> > By not putting it in the hands of every project, but limiting it to a
> > central server. The project should be able to send a package for signing,
> > instead of distributing control with the certificate.
> >
>
> It sounds like you think the code signing is something that is applied
> at the end of the build, on the outermost layer. That is not how it
> works. We need finer-grained signatures, at the individual DLL and
> EXE level, but then also at the MSI and self-installer level. So the
> simplest way is to have the signature applied during the build,
> invoked several times, at each level. Or a more complex script would
> need to be involved to unpack the various layers, sign the artifacts,
> and then reassemble the full packages. In any case it is more than a
> simple service that merely signs a file submitted by the PMC Chair.
> It is likely a per-project script that would need to be executed. And
> that script is in SVN and can be modified by any committer. This
> introduces additional attack vectors.
>
I happen to know who 2 orgs. do it, and believe me their releases is also
not just a simple exe. Both of them have (for each product/project) a
special unpack/pack function together with signing function supplied by
the project. Of course you can also do it at build time that is another
option, which only has the problem that all committers can start a build
and thereby get a signed package.
> >
> >> 4) If control is lost, what is the impact of revoking the certificate?
> >>
> >
> > At the min. very bad marketing. Technically it is easy to revoke the
> > certificate, but all packages that has been signed will remain signed
> > (unless the user actually verify the signing)
> >
>
> In the world we're moving towards, with Windows 8, etc., we should
> expect that revocation lists will be checked. In any case the point
> is that with an ASF-wide cert a revocation would not be limited to a
> single project.
>
you are quite right, we are problaly 5 minutes before midnight, to get code
signing activated.
>
> >
> >> 5) What is the cost, for acquiring certificates and in admin time to
> >> administer this?
> >
> >
> > Admin time can be fairly low, once it is setup, total ASF does not have
> > many releases pr month. The signing proceduere itself can be scripted, so
> > it is merely a matter of activating the process. There will of course be
> > quite an initial hour usage to get it up and running.
> >
> >
> >> Having a single ASF-wide cert makes 5 easier, but makes 4 tougher. If
> >> we ever had to revoke an ASF-wide cert it would impact all signed
> >> modules already distributed by any ASF project. Having a per-project
> >> cert partitions the risk but then can raise costs and complexity. But
> >> personally I think that is the way to go.
> >>
> >
> > I disagree. The risk for the foundation becomes too high. Even with
> project
> > certificates, in the public eye its ASF. To me limiting the number of
> > people who can sign is essential (these people being infra or somebody
> > else).
> >
>
> Having multiple certificates does not mean there are multiple parties
> with control. We could have multiple certs and still have them be
> centrally controlled. In fact that might make the most sense,
> provided the cost could be covered.
>
Sorry I really misunderstood you. Having multiple certs centrally
controlled is better that 1 wildcard cert (of course depending on costs).
To me the key is "centrally controlled".
rgds
jan I.
>
> -Rob
>
> >
> >>
> >> Or, a bolder idea would be to realize that other open source projects
> >> have a similar issue, where code signing is desired, but commercial
> >> CA's are expensive. If there were enough interest I wonder if we
> >> could push for the creation of an open source CA that issued certs
> >> at-cost (or at no cost) to open source projects? Could issue SSL
> >> certs as well. Even broader, do this for all registered non-profits.
> >> In the end we're paying for trust. But we have plenty of trusted
> >> entities in the open source world. So why are we paying real $$$ for
> >> certs?
> >>
> >
> > That is a very interesting idea. FYI the certificates ASF have are to a
> > large degree sponsored, and infra is actually right now in contact with a
> > potential sponsor for a openoffice certificate (is no success within a
> very
> > short period, it will be bought).
> >
> > rgds
> > jan I.
> >
> >>
> >> -Rob
> >>
> >>
> >> > We never thought we would get the wildcard certificate, but hey who
> >> knows?
> >> >
> >> > Regards,
> >> > Dave
> >> >
> >> > On May 24, 2013, at 2:43 PM, Rob Weir wrote:
> >> >
> >> >> And I should mention that pushing the code signing side is probably
> >> >> premature until we have the build side more solidly automated.
> >> >>
> >> >> Every discussion we have had code signing led to the conclusion that
> >> >> if something is signed it must come from a trusted build traceable to
> >> >> an SVN revision. So the pre-req for code signing would be to get the
> >> >> Windows and MacOS builds, in full release form, with all languages,
> >> >> built via buildbots.
> >> >>
> >> >> So moving this forward means moving forward things like:
> >> >>
> >> >> https://issues.apache.org/jira/browse/INFRA-4902
> >> >>
> >> >> Then it would be possible to introduce daily builds signed with a
> >> >> self-signed test certificate. And then, once this is working
> >> >> end-to-end, we would use a real certificate.
> >> >>
> >> >> Code signing is well-understood. It has been part of Windows
> >> >> development for nearly 20 years. The technology is not novel, hard
> to
> >> >> understand or difficult to implement. The main issues are more
> >> >> procedural than technical. ASF projects have a release procedure
> that
> >> >> is decentralized, whereas code signing works most cleanly in a
> >> >> centralized/controlled release environment. That is why the initial
> >> >> focus should be on getting the releases spun directly from the
> >> >> buildbots, traceable to approved source revisions.
> >> >>
> >> >> -Rob
> >> >>
> >> >>
> >> >> On Fri, May 24, 2013 at 5:21 PM, Rob Weir <ro...@apache.org>
> wrote:
> >> >>> On Fri, May 24, 2013 at 5:01 PM, janI <ja...@apache.org> wrote:
> >> >>>> On 24 May 2013 22:30, Juergen Schmidt <jo...@gmail.com>
> wrote:
> >> >>>>
> >> >>>>>
> >> >>>>>
> >> >>>>> Am Freitag, 24. Mai 2013 um 19:50 schrieb janI:
> >> >>>>>
> >> >>>>>> Hi.
> >> >>>>>>
> >> >>>>>> we are not alone in ASF wishing code signing, but we might get
> run
> >> over
> >> >>>>> (as
> >> >>>>>> I did today on IRC) if we do not formulate our requirements very
> >> clearly.
> >> >>>>>>
> >> >>>>>>
> >> >>>>>
> >> >>>>> decisions are made on mailing lists, correct? That is what I
> learned
> >> at
> >> >>>>> Apache, what not happened on a mailing list, is not relevant ;-)
> >> >>>>> Well it seems that infra is always special.
> >> >>>>> I tried several times to discuss it on the infra mailing list and
> I
> >> >>>>> believe I have described very clearly what we need and how it
> works
> >> today
> >> >>>>> for OpenOffice if we would have a cert. I also proposed a solution
> >> that can
> >> >>>>> work from my point of view and I started to collect the info on a
> >> wiki page
> >> >>>>> as suggested.
> >> >>>>> There might be other solutions to do it but I have no in place and
> >> nobody
> >> >>>>> convinced me that my proposed approach can not work.
> >> >>>>> I agree that it's not easy and I simply have no energy to discuss
> >> further
> >> >>>>> at the moment. I have enough other things to do.
> >> >>>>>
> >> >>>>> Juergen
> >> >>>>>>
> >> >>>>>> rgds
> >> >>>>>> jan I.
> >> >>>>>>
> >> >>>>>> ---------- Forwarded message ----------
> >> >>>>>> From: Scott Deboy <sc...@gmail.com>
> >> >>>>>> Date: 24 May 2013 18:59
> >> >>>>>> Subject: Re: Official code signing certificate
> >> >>>>>> To: infrastructure-dev@apache.org
> >> >>>>>>
> >> >>>>>>
> >> >>>>>> Logging Services has a simple requirement:
> >> >>>>>>
> >> >>>>>> Have the Chainsaw build artifacts signed by a Java code signing
> cert
> >> >>>>>> that is signed by a trusted/root CA so the jars can be downloaded
> >> via
> >> >>>>>> WebStart without the user receiving a warning that the signed
> jars
> >> >>>>>> aren't trusted.
> >> >>>>>>
> >> >>>>>> The Chainsaw maven script supports signing jars - infra just
> needs
> >> to
> >> >>>>>> point it to the cert.
> >> >>>>>>
> >> >>>>>> I don't know whether or not an ASF-wide Java code signing cert
> makes
> >> >>>>>> sense or a Logging Services-specific Java code signing cert makes
> >> >>>>>> sense. I don't even know if it is possible to have TLP-specific
> Java
> >> >>>>>> code signing certs. I defer to infra on that decision.
> >> >>>>>>
> >> >>>>>> I believe the code signing service WRowe described will meet our
> >> >>>>>> requirements. Hopefully infra can spend some time looking at the
> >> >>>>>> service and see how it can meet their requirements.
> >> >>>>>>
> >> >>>>>> Logging Services would like to be a guinea pig for the Java code
> >> >>>>>> signing service WRowe described above. If there are additional
> >> >>>>>> details needed by infra, we are happy to provide them.
> >> >>>>>>
> >> >>>>>> Thanks,
> >> >>>>>>
> >> >>>>>> Scott
> >> >>>>>>
> >> >>>>>> On 4/12/13, sebb <se...@gmail.com> wrote:
> >> >>>>>>> You are now in http://wiki.apache.org/general/ContributorsGroup
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>> On 12 April 2013 17:32, William A. Rowe Jr. <
> wrowe@rowe-clan.net>
> >> >>>>> wrote:
> >> >>>>>>>
> >> >>>>>>>> On Fri, 12 Apr 2013 10:47:29 -0500
> >> >>>>>>>> "William A. Rowe Jr." <wr...@rowe-clan.net> wrote:
> >> >>>>>>>>
> >> >>>>>>>>> On Tue, 26 Mar 2013 00:56:06 +0200
> >> >>>>>>>>> Daniel Shahaf <d....@daniel.shahaf.name> wrote:
> >> >>>>>>>>>
> >> >>>>>>>>>> Can you write this all down somewhere? A wiki page maybe
> >> >>>>>>>>>
> >> >>>>>>>>> http://wiki.apache.org/general/ASFCodeSigning
> >> >>>>>>>>
> >> >>>>>>>> Could one of the page editors please grant WilliamARoweJr some
> >> >>>>>>>> karma? I'll document the first-draft approach and the Symantec
> >> >>>>>>>> service-based approach.
> >> >>>>>>>>
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>
> >> >>>>>
> >> >>>> I am truly sorry that I tried to help....with those 2 replies, I
> only
> >> >>>> forwarded a mail for your information, I will for sure forget all
> >> about
> >> >>>> code signing, and leave it to the experts.
> >> >>>>
> >> >>>> During the discussion on IRC, a blog from adobe was thrown in,
> >> showing just
> >> >>>> how complicated it can be for full time security profs. to ensure
> the
> >> >>>> certificate is not misused.
> >> >>>>
> >> >>>> I am sorry I defended our viewpoint, and made this list aware that
> >> there
> >> >>>> are other projects with similar needs. You just managed to kill the
> >> >>>> messenger, next time this issue is discussed on IRC, I will refer
> to
> >> this
> >> >>>> thread and keep silent.
> >> >>>>
> >> >>>
> >> >>> Jan, I'm sure we all appreciate your attempt to "defend our
> >> >>> viewpoint", but you might not be aware that this has been discussed
> >> >>> repeatedly with Infra, since before you were even involved in the
> >> >>> project. If there is any frustration expressed it is not with you.
> >> >>>
> >> >>> The fact that security is hard or that other projects would benefit
> >> >>> from code signing -- none of this is news. That doesn't mean that
> you
> >> >>> were wrong to discuss it. It just means that you did not have the
> >> >>> information and background that Juergen and I have from trying to
> push
> >> >>> this forward over a much longer period of time.
> >> >>>
> >> >>> There is a thread with 93 posts on infra-dev on this topic dating
> back
> >> >>> a year. It probably makes sense to read up on what has been
> discussed
> >> >>> previously before as background information.
> >> >>>
> >> >>> -Rob
> >> >>>
> >> >>>> rgds
> >> >>>> jan I.
> >> >>>>
> >> >>>>>
> >> >>>>>>
> >> >>>>>
> >> >>>>>
> >> >>>>>
> >> >>
> >> >> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> >> >> For additional commands, e-mail: dev-help@openoffice.apache.org
> >> >>
> >> >
> >> >
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> >> > For additional commands, e-mail: dev-help@openoffice.apache.org
> >> >
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> >> For additional commands, e-mail: dev-help@openoffice.apache.org
> >>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
>
Re: Official code signing certificate
Posted by Rob Weir <ro...@apache.org>.
On Sat, May 25, 2013 at 3:17 PM, janI <ja...@apache.org> wrote:
> On 25 May 2013 20:40, Rob Weir <ro...@apache.org> wrote:
>
>> On Fri, May 24, 2013 at 6:17 PM, Dave Fisher <da...@comcast.net>
>> wrote:
>> > Hi Rob,
>> >
>> > This is a very well written summary of the situation with Code Signing.
>> >
>> > The main concern that the ASF has with digitally signing with a singular
>> apache.org certificate for the whole foundation is keeping it in strict
>> control. For some this means physical machines. This is a high bar.
>> >
>> > I wonder if the ASF would allow AOO to experiment with an OpenOffice.org
>> codesigning certificate?
>> >
>>
>> There are a few basic technological and organizational risks:
>>
>> 1) When the ASF signs something, what does it mean for the ASF? Is
>> there any liability assumed by the ASF, for example, if the
>> certificate is misused? Due to negligence? What is the standard of
>> care we must apply to make this risk acceptable?
>>
>
> In my opinion misuse of a certicate (no matter if project or asf wide)
> would have a huge negative impact on the foundation. We would be in the
> press very fast being compared with hackers.
>
> I know we need the certificate, but it must be done in a way where the
> foundation is put at a minimal risk.
>
I think you are missing the point. This is not just a matter of
limiting risk. The question is whether, as a foundation whether the
ASF wants to assume any (even limited) liability. What is the ASF
willing/able to agree to, when acquiring a cert, that is compatible
with its charitable mission and non-profit status.
>
>>
>> 2) How do we ensure the certificate is used to sign only approved releases?
>>
>
> Maybe like many organisations do, the teams (projects) submit their release
> (binary copy) to a central server, where a very small set of people handle
> the signing.
>
The ASF is not at all like a hierarchical corporation with a central
build lab. Releases are decentralized. Now certainly one way of
moving this forward would be to have the ASF change how projects do
releases, but that is probably the hardest way to move this forward.
> Approved releases is a dangerous word, but could be easily achived by only
> allowing pmc chair to send the release. Please remember that just because
> it is a an approved release it can contain malious code, some of the most
> successfull hacks was done at source level.
>
In theory this is already prevented by verifying SVN logs, which
record all changes and which is public. Signing doesn't change that
part of the release equation.
>
>> 3) How to we ensure control of the certificate ?
>>
>
> By not putting it in the hands of every project, but limiting it to a
> central server. The project should be able to send a package for signing,
> instead of distributing control with the certificate.
>
It sounds like you think the code signing is something that is applied
at the end of the build, on the outermost layer. That is not how it
works. We need finer-grained signatures, at the individual DLL and
EXE level, but then also at the MSI and self-installer level. So the
simplest way is to have the signature applied during the build,
invoked several times, at each level. Or a more complex script would
need to be involved to unpack the various layers, sign the artifacts,
and then reassemble the full packages. In any case it is more than a
simple service that merely signs a file submitted by the PMC Chair.
It is likely a per-project script that would need to be executed. And
that script is in SVN and can be modified by any committer. This
introduces additional attack vectors.
>
>> 4) If control is lost, what is the impact of revoking the certificate?
>>
>
> At the min. very bad marketing. Technically it is easy to revoke the
> certificate, but all packages that has been signed will remain signed
> (unless the user actually verify the signing)
>
In the world we're moving towards, with Windows 8, etc., we should
expect that revocation lists will be checked. In any case the point
is that with an ASF-wide cert a revocation would not be limited to a
single project.
>
>> 5) What is the cost, for acquiring certificates and in admin time to
>> administer this?
>
>
> Admin time can be fairly low, once it is setup, total ASF does not have
> many releases pr month. The signing proceduere itself can be scripted, so
> it is merely a matter of activating the process. There will of course be
> quite an initial hour usage to get it up and running.
>
>
>> Having a single ASF-wide cert makes 5 easier, but makes 4 tougher. If
>> we ever had to revoke an ASF-wide cert it would impact all signed
>> modules already distributed by any ASF project. Having a per-project
>> cert partitions the risk but then can raise costs and complexity. But
>> personally I think that is the way to go.
>>
>
> I disagree. The risk for the foundation becomes too high. Even with project
> certificates, in the public eye its ASF. To me limiting the number of
> people who can sign is essential (these people being infra or somebody
> else).
>
Having multiple certificates does not mean there are multiple parties
with control. We could have multiple certs and still have them be
centrally controlled. In fact that might make the most sense,
provided the cost could be covered.
-Rob
>
>>
>> Or, a bolder idea would be to realize that other open source projects
>> have a similar issue, where code signing is desired, but commercial
>> CA's are expensive. If there were enough interest I wonder if we
>> could push for the creation of an open source CA that issued certs
>> at-cost (or at no cost) to open source projects? Could issue SSL
>> certs as well. Even broader, do this for all registered non-profits.
>> In the end we're paying for trust. But we have plenty of trusted
>> entities in the open source world. So why are we paying real $$$ for
>> certs?
>>
>
> That is a very interesting idea. FYI the certificates ASF have are to a
> large degree sponsored, and infra is actually right now in contact with a
> potential sponsor for a openoffice certificate (is no success within a very
> short period, it will be bought).
>
> rgds
> jan I.
>
>>
>> -Rob
>>
>>
>> > We never thought we would get the wildcard certificate, but hey who
>> knows?
>> >
>> > Regards,
>> > Dave
>> >
>> > On May 24, 2013, at 2:43 PM, Rob Weir wrote:
>> >
>> >> And I should mention that pushing the code signing side is probably
>> >> premature until we have the build side more solidly automated.
>> >>
>> >> Every discussion we have had code signing led to the conclusion that
>> >> if something is signed it must come from a trusted build traceable to
>> >> an SVN revision. So the pre-req for code signing would be to get the
>> >> Windows and MacOS builds, in full release form, with all languages,
>> >> built via buildbots.
>> >>
>> >> So moving this forward means moving forward things like:
>> >>
>> >> https://issues.apache.org/jira/browse/INFRA-4902
>> >>
>> >> Then it would be possible to introduce daily builds signed with a
>> >> self-signed test certificate. And then, once this is working
>> >> end-to-end, we would use a real certificate.
>> >>
>> >> Code signing is well-understood. It has been part of Windows
>> >> development for nearly 20 years. The technology is not novel, hard to
>> >> understand or difficult to implement. The main issues are more
>> >> procedural than technical. ASF projects have a release procedure that
>> >> is decentralized, whereas code signing works most cleanly in a
>> >> centralized/controlled release environment. That is why the initial
>> >> focus should be on getting the releases spun directly from the
>> >> buildbots, traceable to approved source revisions.
>> >>
>> >> -Rob
>> >>
>> >>
>> >> On Fri, May 24, 2013 at 5:21 PM, Rob Weir <ro...@apache.org> wrote:
>> >>> On Fri, May 24, 2013 at 5:01 PM, janI <ja...@apache.org> wrote:
>> >>>> On 24 May 2013 22:30, Juergen Schmidt <jo...@gmail.com> wrote:
>> >>>>
>> >>>>>
>> >>>>>
>> >>>>> Am Freitag, 24. Mai 2013 um 19:50 schrieb janI:
>> >>>>>
>> >>>>>> Hi.
>> >>>>>>
>> >>>>>> we are not alone in ASF wishing code signing, but we might get run
>> over
>> >>>>> (as
>> >>>>>> I did today on IRC) if we do not formulate our requirements very
>> clearly.
>> >>>>>>
>> >>>>>>
>> >>>>>
>> >>>>> decisions are made on mailing lists, correct? That is what I learned
>> at
>> >>>>> Apache, what not happened on a mailing list, is not relevant ;-)
>> >>>>> Well it seems that infra is always special.
>> >>>>> I tried several times to discuss it on the infra mailing list and I
>> >>>>> believe I have described very clearly what we need and how it works
>> today
>> >>>>> for OpenOffice if we would have a cert. I also proposed a solution
>> that can
>> >>>>> work from my point of view and I started to collect the info on a
>> wiki page
>> >>>>> as suggested.
>> >>>>> There might be other solutions to do it but I have no in place and
>> nobody
>> >>>>> convinced me that my proposed approach can not work.
>> >>>>> I agree that it's not easy and I simply have no energy to discuss
>> further
>> >>>>> at the moment. I have enough other things to do.
>> >>>>>
>> >>>>> Juergen
>> >>>>>>
>> >>>>>> rgds
>> >>>>>> jan I.
>> >>>>>>
>> >>>>>> ---------- Forwarded message ----------
>> >>>>>> From: Scott Deboy <sc...@gmail.com>
>> >>>>>> Date: 24 May 2013 18:59
>> >>>>>> Subject: Re: Official code signing certificate
>> >>>>>> To: infrastructure-dev@apache.org
>> >>>>>>
>> >>>>>>
>> >>>>>> Logging Services has a simple requirement:
>> >>>>>>
>> >>>>>> Have the Chainsaw build artifacts signed by a Java code signing cert
>> >>>>>> that is signed by a trusted/root CA so the jars can be downloaded
>> via
>> >>>>>> WebStart without the user receiving a warning that the signed jars
>> >>>>>> aren't trusted.
>> >>>>>>
>> >>>>>> The Chainsaw maven script supports signing jars - infra just needs
>> to
>> >>>>>> point it to the cert.
>> >>>>>>
>> >>>>>> I don't know whether or not an ASF-wide Java code signing cert makes
>> >>>>>> sense or a Logging Services-specific Java code signing cert makes
>> >>>>>> sense. I don't even know if it is possible to have TLP-specific Java
>> >>>>>> code signing certs. I defer to infra on that decision.
>> >>>>>>
>> >>>>>> I believe the code signing service WRowe described will meet our
>> >>>>>> requirements. Hopefully infra can spend some time looking at the
>> >>>>>> service and see how it can meet their requirements.
>> >>>>>>
>> >>>>>> Logging Services would like to be a guinea pig for the Java code
>> >>>>>> signing service WRowe described above. If there are additional
>> >>>>>> details needed by infra, we are happy to provide them.
>> >>>>>>
>> >>>>>> Thanks,
>> >>>>>>
>> >>>>>> Scott
>> >>>>>>
>> >>>>>> On 4/12/13, sebb <se...@gmail.com> wrote:
>> >>>>>>> You are now in http://wiki.apache.org/general/ContributorsGroup
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> On 12 April 2013 17:32, William A. Rowe Jr. <wr...@rowe-clan.net>
>> >>>>> wrote:
>> >>>>>>>
>> >>>>>>>> On Fri, 12 Apr 2013 10:47:29 -0500
>> >>>>>>>> "William A. Rowe Jr." <wr...@rowe-clan.net> wrote:
>> >>>>>>>>
>> >>>>>>>>> On Tue, 26 Mar 2013 00:56:06 +0200
>> >>>>>>>>> Daniel Shahaf <d....@daniel.shahaf.name> wrote:
>> >>>>>>>>>
>> >>>>>>>>>> Can you write this all down somewhere? A wiki page maybe
>> >>>>>>>>>
>> >>>>>>>>> http://wiki.apache.org/general/ASFCodeSigning
>> >>>>>>>>
>> >>>>>>>> Could one of the page editors please grant WilliamARoweJr some
>> >>>>>>>> karma? I'll document the first-draft approach and the Symantec
>> >>>>>>>> service-based approach.
>> >>>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>
>> >>>>>
>> >>>> I am truly sorry that I tried to help....with those 2 replies, I only
>> >>>> forwarded a mail for your information, I will for sure forget all
>> about
>> >>>> code signing, and leave it to the experts.
>> >>>>
>> >>>> During the discussion on IRC, a blog from adobe was thrown in,
>> showing just
>> >>>> how complicated it can be for full time security profs. to ensure the
>> >>>> certificate is not misused.
>> >>>>
>> >>>> I am sorry I defended our viewpoint, and made this list aware that
>> there
>> >>>> are other projects with similar needs. You just managed to kill the
>> >>>> messenger, next time this issue is discussed on IRC, I will refer to
>> this
>> >>>> thread and keep silent.
>> >>>>
>> >>>
>> >>> Jan, I'm sure we all appreciate your attempt to "defend our
>> >>> viewpoint", but you might not be aware that this has been discussed
>> >>> repeatedly with Infra, since before you were even involved in the
>> >>> project. If there is any frustration expressed it is not with you.
>> >>>
>> >>> The fact that security is hard or that other projects would benefit
>> >>> from code signing -- none of this is news. That doesn't mean that you
>> >>> were wrong to discuss it. It just means that you did not have the
>> >>> information and background that Juergen and I have from trying to push
>> >>> this forward over a much longer period of time.
>> >>>
>> >>> There is a thread with 93 posts on infra-dev on this topic dating back
>> >>> a year. It probably makes sense to read up on what has been discussed
>> >>> previously before as background information.
>> >>>
>> >>> -Rob
>> >>>
>> >>>> rgds
>> >>>> jan I.
>> >>>>
>> >>>>>
>> >>>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
>> >> For additional commands, e-mail: dev-help@openoffice.apache.org
>> >>
>> >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
>> > For additional commands, e-mail: dev-help@openoffice.apache.org
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Official code signing certificate
Posted by janI <ja...@apache.org>.
On 25 May 2013 20:40, Rob Weir <ro...@apache.org> wrote:
> On Fri, May 24, 2013 at 6:17 PM, Dave Fisher <da...@comcast.net>
> wrote:
> > Hi Rob,
> >
> > This is a very well written summary of the situation with Code Signing.
> >
> > The main concern that the ASF has with digitally signing with a singular
> apache.org certificate for the whole foundation is keeping it in strict
> control. For some this means physical machines. This is a high bar.
> >
> > I wonder if the ASF would allow AOO to experiment with an OpenOffice.org
> codesigning certificate?
> >
>
> There are a few basic technological and organizational risks:
>
> 1) When the ASF signs something, what does it mean for the ASF? Is
> there any liability assumed by the ASF, for example, if the
> certificate is misused? Due to negligence? What is the standard of
> care we must apply to make this risk acceptable?
>
In my opinion misuse of a certicate (no matter if project or asf wide)
would have a huge negative impact on the foundation. We would be in the
press very fast being compared with hackers.
I know we need the certificate, but it must be done in a way where the
foundation is put at a minimal risk.
>
> 2) How do we ensure the certificate is used to sign only approved releases?
>
Maybe like many organisations do, the teams (projects) submit their release
(binary copy) to a central server, where a very small set of people handle
the signing.
Approved releases is a dangerous word, but could be easily achived by only
allowing pmc chair to send the release. Please remember that just because
it is a an approved release it can contain malious code, some of the most
successfull hacks was done at source level.
> 3) How to we ensure control of the certificate ?
>
By not putting it in the hands of every project, but limiting it to a
central server. The project should be able to send a package for signing,
instead of distributing control with the certificate.
> 4) If control is lost, what is the impact of revoking the certificate?
>
At the min. very bad marketing. Technically it is easy to revoke the
certificate, but all packages that has been signed will remain signed
(unless the user actually verify the signing)
> 5) What is the cost, for acquiring certificates and in admin time to
> administer this?
Admin time can be fairly low, once it is setup, total ASF does not have
many releases pr month. The signing proceduere itself can be scripted, so
it is merely a matter of activating the process. There will of course be
quite an initial hour usage to get it up and running.
> Having a single ASF-wide cert makes 5 easier, but makes 4 tougher. If
> we ever had to revoke an ASF-wide cert it would impact all signed
> modules already distributed by any ASF project. Having a per-project
> cert partitions the risk but then can raise costs and complexity. But
> personally I think that is the way to go.
>
I disagree. The risk for the foundation becomes too high. Even with project
certificates, in the public eye its ASF. To me limiting the number of
people who can sign is essential (these people being infra or somebody
else).
>
> Or, a bolder idea would be to realize that other open source projects
> have a similar issue, where code signing is desired, but commercial
> CA's are expensive. If there were enough interest I wonder if we
> could push for the creation of an open source CA that issued certs
> at-cost (or at no cost) to open source projects? Could issue SSL
> certs as well. Even broader, do this for all registered non-profits.
> In the end we're paying for trust. But we have plenty of trusted
> entities in the open source world. So why are we paying real $$$ for
> certs?
>
That is a very interesting idea. FYI the certificates ASF have are to a
large degree sponsored, and infra is actually right now in contact with a
potential sponsor for a openoffice certificate (is no success within a very
short period, it will be bought).
rgds
jan I.
>
> -Rob
>
>
> > We never thought we would get the wildcard certificate, but hey who
> knows?
> >
> > Regards,
> > Dave
> >
> > On May 24, 2013, at 2:43 PM, Rob Weir wrote:
> >
> >> And I should mention that pushing the code signing side is probably
> >> premature until we have the build side more solidly automated.
> >>
> >> Every discussion we have had code signing led to the conclusion that
> >> if something is signed it must come from a trusted build traceable to
> >> an SVN revision. So the pre-req for code signing would be to get the
> >> Windows and MacOS builds, in full release form, with all languages,
> >> built via buildbots.
> >>
> >> So moving this forward means moving forward things like:
> >>
> >> https://issues.apache.org/jira/browse/INFRA-4902
> >>
> >> Then it would be possible to introduce daily builds signed with a
> >> self-signed test certificate. And then, once this is working
> >> end-to-end, we would use a real certificate.
> >>
> >> Code signing is well-understood. It has been part of Windows
> >> development for nearly 20 years. The technology is not novel, hard to
> >> understand or difficult to implement. The main issues are more
> >> procedural than technical. ASF projects have a release procedure that
> >> is decentralized, whereas code signing works most cleanly in a
> >> centralized/controlled release environment. That is why the initial
> >> focus should be on getting the releases spun directly from the
> >> buildbots, traceable to approved source revisions.
> >>
> >> -Rob
> >>
> >>
> >> On Fri, May 24, 2013 at 5:21 PM, Rob Weir <ro...@apache.org> wrote:
> >>> On Fri, May 24, 2013 at 5:01 PM, janI <ja...@apache.org> wrote:
> >>>> On 24 May 2013 22:30, Juergen Schmidt <jo...@gmail.com> wrote:
> >>>>
> >>>>>
> >>>>>
> >>>>> Am Freitag, 24. Mai 2013 um 19:50 schrieb janI:
> >>>>>
> >>>>>> Hi.
> >>>>>>
> >>>>>> we are not alone in ASF wishing code signing, but we might get run
> over
> >>>>> (as
> >>>>>> I did today on IRC) if we do not formulate our requirements very
> clearly.
> >>>>>>
> >>>>>>
> >>>>>
> >>>>> decisions are made on mailing lists, correct? That is what I learned
> at
> >>>>> Apache, what not happened on a mailing list, is not relevant ;-)
> >>>>> Well it seems that infra is always special.
> >>>>> I tried several times to discuss it on the infra mailing list and I
> >>>>> believe I have described very clearly what we need and how it works
> today
> >>>>> for OpenOffice if we would have a cert. I also proposed a solution
> that can
> >>>>> work from my point of view and I started to collect the info on a
> wiki page
> >>>>> as suggested.
> >>>>> There might be other solutions to do it but I have no in place and
> nobody
> >>>>> convinced me that my proposed approach can not work.
> >>>>> I agree that it's not easy and I simply have no energy to discuss
> further
> >>>>> at the moment. I have enough other things to do.
> >>>>>
> >>>>> Juergen
> >>>>>>
> >>>>>> rgds
> >>>>>> jan I.
> >>>>>>
> >>>>>> ---------- Forwarded message ----------
> >>>>>> From: Scott Deboy <sc...@gmail.com>
> >>>>>> Date: 24 May 2013 18:59
> >>>>>> Subject: Re: Official code signing certificate
> >>>>>> To: infrastructure-dev@apache.org
> >>>>>>
> >>>>>>
> >>>>>> Logging Services has a simple requirement:
> >>>>>>
> >>>>>> Have the Chainsaw build artifacts signed by a Java code signing cert
> >>>>>> that is signed by a trusted/root CA so the jars can be downloaded
> via
> >>>>>> WebStart without the user receiving a warning that the signed jars
> >>>>>> aren't trusted.
> >>>>>>
> >>>>>> The Chainsaw maven script supports signing jars - infra just needs
> to
> >>>>>> point it to the cert.
> >>>>>>
> >>>>>> I don't know whether or not an ASF-wide Java code signing cert makes
> >>>>>> sense or a Logging Services-specific Java code signing cert makes
> >>>>>> sense. I don't even know if it is possible to have TLP-specific Java
> >>>>>> code signing certs. I defer to infra on that decision.
> >>>>>>
> >>>>>> I believe the code signing service WRowe described will meet our
> >>>>>> requirements. Hopefully infra can spend some time looking at the
> >>>>>> service and see how it can meet their requirements.
> >>>>>>
> >>>>>> Logging Services would like to be a guinea pig for the Java code
> >>>>>> signing service WRowe described above. If there are additional
> >>>>>> details needed by infra, we are happy to provide them.
> >>>>>>
> >>>>>> Thanks,
> >>>>>>
> >>>>>> Scott
> >>>>>>
> >>>>>> On 4/12/13, sebb <se...@gmail.com> wrote:
> >>>>>>> You are now in http://wiki.apache.org/general/ContributorsGroup
> >>>>>>>
> >>>>>>>
> >>>>>>> On 12 April 2013 17:32, William A. Rowe Jr. <wr...@rowe-clan.net>
> >>>>> wrote:
> >>>>>>>
> >>>>>>>> On Fri, 12 Apr 2013 10:47:29 -0500
> >>>>>>>> "William A. Rowe Jr." <wr...@rowe-clan.net> wrote:
> >>>>>>>>
> >>>>>>>>> On Tue, 26 Mar 2013 00:56:06 +0200
> >>>>>>>>> Daniel Shahaf <d....@daniel.shahaf.name> wrote:
> >>>>>>>>>
> >>>>>>>>>> Can you write this all down somewhere? A wiki page maybe
> >>>>>>>>>
> >>>>>>>>> http://wiki.apache.org/general/ASFCodeSigning
> >>>>>>>>
> >>>>>>>> Could one of the page editors please grant WilliamARoweJr some
> >>>>>>>> karma? I'll document the first-draft approach and the Symantec
> >>>>>>>> service-based approach.
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>> I am truly sorry that I tried to help....with those 2 replies, I only
> >>>> forwarded a mail for your information, I will for sure forget all
> about
> >>>> code signing, and leave it to the experts.
> >>>>
> >>>> During the discussion on IRC, a blog from adobe was thrown in,
> showing just
> >>>> how complicated it can be for full time security profs. to ensure the
> >>>> certificate is not misused.
> >>>>
> >>>> I am sorry I defended our viewpoint, and made this list aware that
> there
> >>>> are other projects with similar needs. You just managed to kill the
> >>>> messenger, next time this issue is discussed on IRC, I will refer to
> this
> >>>> thread and keep silent.
> >>>>
> >>>
> >>> Jan, I'm sure we all appreciate your attempt to "defend our
> >>> viewpoint", but you might not be aware that this has been discussed
> >>> repeatedly with Infra, since before you were even involved in the
> >>> project. If there is any frustration expressed it is not with you.
> >>>
> >>> The fact that security is hard or that other projects would benefit
> >>> from code signing -- none of this is news. That doesn't mean that you
> >>> were wrong to discuss it. It just means that you did not have the
> >>> information and background that Juergen and I have from trying to push
> >>> this forward over a much longer period of time.
> >>>
> >>> There is a thread with 93 posts on infra-dev on this topic dating back
> >>> a year. It probably makes sense to read up on what has been discussed
> >>> previously before as background information.
> >>>
> >>> -Rob
> >>>
> >>>> rgds
> >>>> jan I.
> >>>>
> >>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> >> For additional commands, e-mail: dev-help@openoffice.apache.org
> >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> > For additional commands, e-mail: dev-help@openoffice.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
>
Re: Official code signing certificate
Posted by Rob Weir <ro...@apache.org>.
On Fri, May 24, 2013 at 6:17 PM, Dave Fisher <da...@comcast.net> wrote:
> Hi Rob,
>
> This is a very well written summary of the situation with Code Signing.
>
> The main concern that the ASF has with digitally signing with a singular apache.org certificate for the whole foundation is keeping it in strict control. For some this means physical machines. This is a high bar.
>
> I wonder if the ASF would allow AOO to experiment with an OpenOffice.org codesigning certificate?
>
There are a few basic technological and organizational risks:
1) When the ASF signs something, what does it mean for the ASF? Is
there any liability assumed by the ASF, for example, if the
certificate is misused? Due to negligence? What is the standard of
care we must apply to make this risk acceptable?
2) How do we ensure the certificate is used to sign only approved releases?
3) How to we ensure control of the certificate ?
4) If control is lost, what is the impact of revoking the certificate?
5) What is the cost, for acquiring certificates and in admin time to
administer this?
Having a single ASF-wide cert makes 5 easier, but makes 4 tougher. If
we ever had to revoke an ASF-wide cert it would impact all signed
modules already distributed by any ASF project. Having a per-project
cert partitions the risk but then can raise costs and complexity. But
personally I think that is the way to go.
Or, a bolder idea would be to realize that other open source projects
have a similar issue, where code signing is desired, but commercial
CA's are expensive. If there were enough interest I wonder if we
could push for the creation of an open source CA that issued certs
at-cost (or at no cost) to open source projects? Could issue SSL
certs as well. Even broader, do this for all registered non-profits.
In the end we're paying for trust. But we have plenty of trusted
entities in the open source world. So why are we paying real $$$ for
certs?
-Rob
> We never thought we would get the wildcard certificate, but hey who knows?
>
> Regards,
> Dave
>
> On May 24, 2013, at 2:43 PM, Rob Weir wrote:
>
>> And I should mention that pushing the code signing side is probably
>> premature until we have the build side more solidly automated.
>>
>> Every discussion we have had code signing led to the conclusion that
>> if something is signed it must come from a trusted build traceable to
>> an SVN revision. So the pre-req for code signing would be to get the
>> Windows and MacOS builds, in full release form, with all languages,
>> built via buildbots.
>>
>> So moving this forward means moving forward things like:
>>
>> https://issues.apache.org/jira/browse/INFRA-4902
>>
>> Then it would be possible to introduce daily builds signed with a
>> self-signed test certificate. And then, once this is working
>> end-to-end, we would use a real certificate.
>>
>> Code signing is well-understood. It has been part of Windows
>> development for nearly 20 years. The technology is not novel, hard to
>> understand or difficult to implement. The main issues are more
>> procedural than technical. ASF projects have a release procedure that
>> is decentralized, whereas code signing works most cleanly in a
>> centralized/controlled release environment. That is why the initial
>> focus should be on getting the releases spun directly from the
>> buildbots, traceable to approved source revisions.
>>
>> -Rob
>>
>>
>> On Fri, May 24, 2013 at 5:21 PM, Rob Weir <ro...@apache.org> wrote:
>>> On Fri, May 24, 2013 at 5:01 PM, janI <ja...@apache.org> wrote:
>>>> On 24 May 2013 22:30, Juergen Schmidt <jo...@gmail.com> wrote:
>>>>
>>>>>
>>>>>
>>>>> Am Freitag, 24. Mai 2013 um 19:50 schrieb janI:
>>>>>
>>>>>> Hi.
>>>>>>
>>>>>> we are not alone in ASF wishing code signing, but we might get run over
>>>>> (as
>>>>>> I did today on IRC) if we do not formulate our requirements very clearly.
>>>>>>
>>>>>>
>>>>>
>>>>> decisions are made on mailing lists, correct? That is what I learned at
>>>>> Apache, what not happened on a mailing list, is not relevant ;-)
>>>>> Well it seems that infra is always special.
>>>>> I tried several times to discuss it on the infra mailing list and I
>>>>> believe I have described very clearly what we need and how it works today
>>>>> for OpenOffice if we would have a cert. I also proposed a solution that can
>>>>> work from my point of view and I started to collect the info on a wiki page
>>>>> as suggested.
>>>>> There might be other solutions to do it but I have no in place and nobody
>>>>> convinced me that my proposed approach can not work.
>>>>> I agree that it's not easy and I simply have no energy to discuss further
>>>>> at the moment. I have enough other things to do.
>>>>>
>>>>> Juergen
>>>>>>
>>>>>> rgds
>>>>>> jan I.
>>>>>>
>>>>>> ---------- Forwarded message ----------
>>>>>> From: Scott Deboy <sc...@gmail.com>
>>>>>> Date: 24 May 2013 18:59
>>>>>> Subject: Re: Official code signing certificate
>>>>>> To: infrastructure-dev@apache.org
>>>>>>
>>>>>>
>>>>>> Logging Services has a simple requirement:
>>>>>>
>>>>>> Have the Chainsaw build artifacts signed by a Java code signing cert
>>>>>> that is signed by a trusted/root CA so the jars can be downloaded via
>>>>>> WebStart without the user receiving a warning that the signed jars
>>>>>> aren't trusted.
>>>>>>
>>>>>> The Chainsaw maven script supports signing jars - infra just needs to
>>>>>> point it to the cert.
>>>>>>
>>>>>> I don't know whether or not an ASF-wide Java code signing cert makes
>>>>>> sense or a Logging Services-specific Java code signing cert makes
>>>>>> sense. I don't even know if it is possible to have TLP-specific Java
>>>>>> code signing certs. I defer to infra on that decision.
>>>>>>
>>>>>> I believe the code signing service WRowe described will meet our
>>>>>> requirements. Hopefully infra can spend some time looking at the
>>>>>> service and see how it can meet their requirements.
>>>>>>
>>>>>> Logging Services would like to be a guinea pig for the Java code
>>>>>> signing service WRowe described above. If there are additional
>>>>>> details needed by infra, we are happy to provide them.
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Scott
>>>>>>
>>>>>> On 4/12/13, sebb <se...@gmail.com> wrote:
>>>>>>> You are now in http://wiki.apache.org/general/ContributorsGroup
>>>>>>>
>>>>>>>
>>>>>>> On 12 April 2013 17:32, William A. Rowe Jr. <wr...@rowe-clan.net>
>>>>> wrote:
>>>>>>>
>>>>>>>> On Fri, 12 Apr 2013 10:47:29 -0500
>>>>>>>> "William A. Rowe Jr." <wr...@rowe-clan.net> wrote:
>>>>>>>>
>>>>>>>>> On Tue, 26 Mar 2013 00:56:06 +0200
>>>>>>>>> Daniel Shahaf <d....@daniel.shahaf.name> wrote:
>>>>>>>>>
>>>>>>>>>> Can you write this all down somewhere? A wiki page maybe
>>>>>>>>>
>>>>>>>>> http://wiki.apache.org/general/ASFCodeSigning
>>>>>>>>
>>>>>>>> Could one of the page editors please grant WilliamARoweJr some
>>>>>>>> karma? I'll document the first-draft approach and the Symantec
>>>>>>>> service-based approach.
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>> I am truly sorry that I tried to help....with those 2 replies, I only
>>>> forwarded a mail for your information, I will for sure forget all about
>>>> code signing, and leave it to the experts.
>>>>
>>>> During the discussion on IRC, a blog from adobe was thrown in, showing just
>>>> how complicated it can be for full time security profs. to ensure the
>>>> certificate is not misused.
>>>>
>>>> I am sorry I defended our viewpoint, and made this list aware that there
>>>> are other projects with similar needs. You just managed to kill the
>>>> messenger, next time this issue is discussed on IRC, I will refer to this
>>>> thread and keep silent.
>>>>
>>>
>>> Jan, I'm sure we all appreciate your attempt to "defend our
>>> viewpoint", but you might not be aware that this has been discussed
>>> repeatedly with Infra, since before you were even involved in the
>>> project. If there is any frustration expressed it is not with you.
>>>
>>> The fact that security is hard or that other projects would benefit
>>> from code signing -- none of this is news. That doesn't mean that you
>>> were wrong to discuss it. It just means that you did not have the
>>> information and background that Juergen and I have from trying to push
>>> this forward over a much longer period of time.
>>>
>>> There is a thread with 93 posts on infra-dev on this topic dating back
>>> a year. It probably makes sense to read up on what has been discussed
>>> previously before as background information.
>>>
>>> -Rob
>>>
>>>> rgds
>>>> jan I.
>>>>
>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Official code signing certificate
Posted by Dave Fisher <da...@comcast.net>.
Hi Rob,
This is a very well written summary of the situation with Code Signing.
The main concern that the ASF has with digitally signing with a singular apache.org certificate for the whole foundation is keeping it in strict control. For some this means physical machines. This is a high bar.
I wonder if the ASF would allow AOO to experiment with an OpenOffice.org codesigning certificate?
We never thought we would get the wildcard certificate, but hey who knows?
Regards,
Dave
On May 24, 2013, at 2:43 PM, Rob Weir wrote:
> And I should mention that pushing the code signing side is probably
> premature until we have the build side more solidly automated.
>
> Every discussion we have had code signing led to the conclusion that
> if something is signed it must come from a trusted build traceable to
> an SVN revision. So the pre-req for code signing would be to get the
> Windows and MacOS builds, in full release form, with all languages,
> built via buildbots.
>
> So moving this forward means moving forward things like:
>
> https://issues.apache.org/jira/browse/INFRA-4902
>
> Then it would be possible to introduce daily builds signed with a
> self-signed test certificate. And then, once this is working
> end-to-end, we would use a real certificate.
>
> Code signing is well-understood. It has been part of Windows
> development for nearly 20 years. The technology is not novel, hard to
> understand or difficult to implement. The main issues are more
> procedural than technical. ASF projects have a release procedure that
> is decentralized, whereas code signing works most cleanly in a
> centralized/controlled release environment. That is why the initial
> focus should be on getting the releases spun directly from the
> buildbots, traceable to approved source revisions.
>
> -Rob
>
>
> On Fri, May 24, 2013 at 5:21 PM, Rob Weir <ro...@apache.org> wrote:
>> On Fri, May 24, 2013 at 5:01 PM, janI <ja...@apache.org> wrote:
>>> On 24 May 2013 22:30, Juergen Schmidt <jo...@gmail.com> wrote:
>>>
>>>>
>>>>
>>>> Am Freitag, 24. Mai 2013 um 19:50 schrieb janI:
>>>>
>>>>> Hi.
>>>>>
>>>>> we are not alone in ASF wishing code signing, but we might get run over
>>>> (as
>>>>> I did today on IRC) if we do not formulate our requirements very clearly.
>>>>>
>>>>>
>>>>
>>>> decisions are made on mailing lists, correct? That is what I learned at
>>>> Apache, what not happened on a mailing list, is not relevant ;-)
>>>> Well it seems that infra is always special.
>>>> I tried several times to discuss it on the infra mailing list and I
>>>> believe I have described very clearly what we need and how it works today
>>>> for OpenOffice if we would have a cert. I also proposed a solution that can
>>>> work from my point of view and I started to collect the info on a wiki page
>>>> as suggested.
>>>> There might be other solutions to do it but I have no in place and nobody
>>>> convinced me that my proposed approach can not work.
>>>> I agree that it's not easy and I simply have no energy to discuss further
>>>> at the moment. I have enough other things to do.
>>>>
>>>> Juergen
>>>>>
>>>>> rgds
>>>>> jan I.
>>>>>
>>>>> ---------- Forwarded message ----------
>>>>> From: Scott Deboy <sc...@gmail.com>
>>>>> Date: 24 May 2013 18:59
>>>>> Subject: Re: Official code signing certificate
>>>>> To: infrastructure-dev@apache.org
>>>>>
>>>>>
>>>>> Logging Services has a simple requirement:
>>>>>
>>>>> Have the Chainsaw build artifacts signed by a Java code signing cert
>>>>> that is signed by a trusted/root CA so the jars can be downloaded via
>>>>> WebStart without the user receiving a warning that the signed jars
>>>>> aren't trusted.
>>>>>
>>>>> The Chainsaw maven script supports signing jars - infra just needs to
>>>>> point it to the cert.
>>>>>
>>>>> I don't know whether or not an ASF-wide Java code signing cert makes
>>>>> sense or a Logging Services-specific Java code signing cert makes
>>>>> sense. I don't even know if it is possible to have TLP-specific Java
>>>>> code signing certs. I defer to infra on that decision.
>>>>>
>>>>> I believe the code signing service WRowe described will meet our
>>>>> requirements. Hopefully infra can spend some time looking at the
>>>>> service and see how it can meet their requirements.
>>>>>
>>>>> Logging Services would like to be a guinea pig for the Java code
>>>>> signing service WRowe described above. If there are additional
>>>>> details needed by infra, we are happy to provide them.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Scott
>>>>>
>>>>> On 4/12/13, sebb <se...@gmail.com> wrote:
>>>>>> You are now in http://wiki.apache.org/general/ContributorsGroup
>>>>>>
>>>>>>
>>>>>> On 12 April 2013 17:32, William A. Rowe Jr. <wr...@rowe-clan.net>
>>>> wrote:
>>>>>>
>>>>>>> On Fri, 12 Apr 2013 10:47:29 -0500
>>>>>>> "William A. Rowe Jr." <wr...@rowe-clan.net> wrote:
>>>>>>>
>>>>>>>> On Tue, 26 Mar 2013 00:56:06 +0200
>>>>>>>> Daniel Shahaf <d....@daniel.shahaf.name> wrote:
>>>>>>>>
>>>>>>>>> Can you write this all down somewhere? A wiki page maybe
>>>>>>>>
>>>>>>>> http://wiki.apache.org/general/ASFCodeSigning
>>>>>>>
>>>>>>> Could one of the page editors please grant WilliamARoweJr some
>>>>>>> karma? I'll document the first-draft approach and the Symantec
>>>>>>> service-based approach.
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>> I am truly sorry that I tried to help....with those 2 replies, I only
>>> forwarded a mail for your information, I will for sure forget all about
>>> code signing, and leave it to the experts.
>>>
>>> During the discussion on IRC, a blog from adobe was thrown in, showing just
>>> how complicated it can be for full time security profs. to ensure the
>>> certificate is not misused.
>>>
>>> I am sorry I defended our viewpoint, and made this list aware that there
>>> are other projects with similar needs. You just managed to kill the
>>> messenger, next time this issue is discussed on IRC, I will refer to this
>>> thread and keep silent.
>>>
>>
>> Jan, I'm sure we all appreciate your attempt to "defend our
>> viewpoint", but you might not be aware that this has been discussed
>> repeatedly with Infra, since before you were even involved in the
>> project. If there is any frustration expressed it is not with you.
>>
>> The fact that security is hard or that other projects would benefit
>> from code signing -- none of this is news. That doesn't mean that you
>> were wrong to discuss it. It just means that you did not have the
>> information and background that Juergen and I have from trying to push
>> this forward over a much longer period of time.
>>
>> There is a thread with 93 posts on infra-dev on this topic dating back
>> a year. It probably makes sense to read up on what has been discussed
>> previously before as background information.
>>
>> -Rob
>>
>>> rgds
>>> jan I.
>>>
>>>>
>>>>>
>>>>
>>>>
>>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Official code signing certificate
Posted by Rob Weir <ro...@apache.org>.
And I should mention that pushing the code signing side is probably
premature until we have the build side more solidly automated.
Every discussion we have had code signing led to the conclusion that
if something is signed it must come from a trusted build traceable to
an SVN revision. So the pre-req for code signing would be to get the
Windows and MacOS builds, in full release form, with all languages,
built via buildbots.
So moving this forward means moving forward things like:
https://issues.apache.org/jira/browse/INFRA-4902
Then it would be possible to introduce daily builds signed with a
self-signed test certificate. And then, once this is working
end-to-end, we would use a real certificate.
Code signing is well-understood. It has been part of Windows
development for nearly 20 years. The technology is not novel, hard to
understand or difficult to implement. The main issues are more
procedural than technical. ASF projects have a release procedure that
is decentralized, whereas code signing works most cleanly in a
centralized/controlled release environment. That is why the initial
focus should be on getting the releases spun directly from the
buildbots, traceable to approved source revisions.
-Rob
On Fri, May 24, 2013 at 5:21 PM, Rob Weir <ro...@apache.org> wrote:
> On Fri, May 24, 2013 at 5:01 PM, janI <ja...@apache.org> wrote:
>> On 24 May 2013 22:30, Juergen Schmidt <jo...@gmail.com> wrote:
>>
>>>
>>>
>>> Am Freitag, 24. Mai 2013 um 19:50 schrieb janI:
>>>
>>> > Hi.
>>> >
>>> > we are not alone in ASF wishing code signing, but we might get run over
>>> (as
>>> > I did today on IRC) if we do not formulate our requirements very clearly.
>>> >
>>> >
>>>
>>> decisions are made on mailing lists, correct? That is what I learned at
>>> Apache, what not happened on a mailing list, is not relevant ;-)
>>> Well it seems that infra is always special.
>>> I tried several times to discuss it on the infra mailing list and I
>>> believe I have described very clearly what we need and how it works today
>>> for OpenOffice if we would have a cert. I also proposed a solution that can
>>> work from my point of view and I started to collect the info on a wiki page
>>> as suggested.
>>> There might be other solutions to do it but I have no in place and nobody
>>> convinced me that my proposed approach can not work.
>>> I agree that it's not easy and I simply have no energy to discuss further
>>> at the moment. I have enough other things to do.
>>>
>>> Juergen
>>> >
>>> > rgds
>>> > jan I.
>>> >
>>> > ---------- Forwarded message ----------
>>> > From: Scott Deboy <sc...@gmail.com>
>>> > Date: 24 May 2013 18:59
>>> > Subject: Re: Official code signing certificate
>>> > To: infrastructure-dev@apache.org
>>> >
>>> >
>>> > Logging Services has a simple requirement:
>>> >
>>> > Have the Chainsaw build artifacts signed by a Java code signing cert
>>> > that is signed by a trusted/root CA so the jars can be downloaded via
>>> > WebStart without the user receiving a warning that the signed jars
>>> > aren't trusted.
>>> >
>>> > The Chainsaw maven script supports signing jars - infra just needs to
>>> > point it to the cert.
>>> >
>>> > I don't know whether or not an ASF-wide Java code signing cert makes
>>> > sense or a Logging Services-specific Java code signing cert makes
>>> > sense. I don't even know if it is possible to have TLP-specific Java
>>> > code signing certs. I defer to infra on that decision.
>>> >
>>> > I believe the code signing service WRowe described will meet our
>>> > requirements. Hopefully infra can spend some time looking at the
>>> > service and see how it can meet their requirements.
>>> >
>>> > Logging Services would like to be a guinea pig for the Java code
>>> > signing service WRowe described above. If there are additional
>>> > details needed by infra, we are happy to provide them.
>>> >
>>> > Thanks,
>>> >
>>> > Scott
>>> >
>>> > On 4/12/13, sebb <se...@gmail.com> wrote:
>>> > > You are now in http://wiki.apache.org/general/ContributorsGroup
>>> > >
>>> > >
>>> > > On 12 April 2013 17:32, William A. Rowe Jr. <wr...@rowe-clan.net>
>>> wrote:
>>> > >
>>> > > > On Fri, 12 Apr 2013 10:47:29 -0500
>>> > > > "William A. Rowe Jr." <wr...@rowe-clan.net> wrote:
>>> > > >
>>> > > > > On Tue, 26 Mar 2013 00:56:06 +0200
>>> > > > > Daniel Shahaf <d....@daniel.shahaf.name> wrote:
>>> > > > >
>>> > > > > > Can you write this all down somewhere? A wiki page maybe
>>> > > > >
>>> > > > > http://wiki.apache.org/general/ASFCodeSigning
>>> > > >
>>> > > > Could one of the page editors please grant WilliamARoweJr some
>>> > > > karma? I'll document the first-draft approach and the Symantec
>>> > > > service-based approach.
>>> > > >
>>> > >
>>> > >
>>> >
>>>
>> I am truly sorry that I tried to help....with those 2 replies, I only
>> forwarded a mail for your information, I will for sure forget all about
>> code signing, and leave it to the experts.
>>
>> During the discussion on IRC, a blog from adobe was thrown in, showing just
>> how complicated it can be for full time security profs. to ensure the
>> certificate is not misused.
>>
>> I am sorry I defended our viewpoint, and made this list aware that there
>> are other projects with similar needs. You just managed to kill the
>> messenger, next time this issue is discussed on IRC, I will refer to this
>> thread and keep silent.
>>
>
> Jan, I'm sure we all appreciate your attempt to "defend our
> viewpoint", but you might not be aware that this has been discussed
> repeatedly with Infra, since before you were even involved in the
> project. If there is any frustration expressed it is not with you.
>
> The fact that security is hard or that other projects would benefit
> from code signing -- none of this is news. That doesn't mean that you
> were wrong to discuss it. It just means that you did not have the
> information and background that Juergen and I have from trying to push
> this forward over a much longer period of time.
>
> There is a thread with 93 posts on infra-dev on this topic dating back
> a year. It probably makes sense to read up on what has been discussed
> previously before as background information.
>
> -Rob
>
>> rgds
>> jan I.
>>
>>>
>>> >
>>>
>>>
>>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Official code signing certificate
Posted by Rob Weir <ro...@apache.org>.
On Fri, May 24, 2013 at 5:01 PM, janI <ja...@apache.org> wrote:
> On 24 May 2013 22:30, Juergen Schmidt <jo...@gmail.com> wrote:
>
>>
>>
>> Am Freitag, 24. Mai 2013 um 19:50 schrieb janI:
>>
>> > Hi.
>> >
>> > we are not alone in ASF wishing code signing, but we might get run over
>> (as
>> > I did today on IRC) if we do not formulate our requirements very clearly.
>> >
>> >
>>
>> decisions are made on mailing lists, correct? That is what I learned at
>> Apache, what not happened on a mailing list, is not relevant ;-)
>> Well it seems that infra is always special.
>> I tried several times to discuss it on the infra mailing list and I
>> believe I have described very clearly what we need and how it works today
>> for OpenOffice if we would have a cert. I also proposed a solution that can
>> work from my point of view and I started to collect the info on a wiki page
>> as suggested.
>> There might be other solutions to do it but I have no in place and nobody
>> convinced me that my proposed approach can not work.
>> I agree that it's not easy and I simply have no energy to discuss further
>> at the moment. I have enough other things to do.
>>
>> Juergen
>> >
>> > rgds
>> > jan I.
>> >
>> > ---------- Forwarded message ----------
>> > From: Scott Deboy <sc...@gmail.com>
>> > Date: 24 May 2013 18:59
>> > Subject: Re: Official code signing certificate
>> > To: infrastructure-dev@apache.org
>> >
>> >
>> > Logging Services has a simple requirement:
>> >
>> > Have the Chainsaw build artifacts signed by a Java code signing cert
>> > that is signed by a trusted/root CA so the jars can be downloaded via
>> > WebStart without the user receiving a warning that the signed jars
>> > aren't trusted.
>> >
>> > The Chainsaw maven script supports signing jars - infra just needs to
>> > point it to the cert.
>> >
>> > I don't know whether or not an ASF-wide Java code signing cert makes
>> > sense or a Logging Services-specific Java code signing cert makes
>> > sense. I don't even know if it is possible to have TLP-specific Java
>> > code signing certs. I defer to infra on that decision.
>> >
>> > I believe the code signing service WRowe described will meet our
>> > requirements. Hopefully infra can spend some time looking at the
>> > service and see how it can meet their requirements.
>> >
>> > Logging Services would like to be a guinea pig for the Java code
>> > signing service WRowe described above. If there are additional
>> > details needed by infra, we are happy to provide them.
>> >
>> > Thanks,
>> >
>> > Scott
>> >
>> > On 4/12/13, sebb <se...@gmail.com> wrote:
>> > > You are now in http://wiki.apache.org/general/ContributorsGroup
>> > >
>> > >
>> > > On 12 April 2013 17:32, William A. Rowe Jr. <wr...@rowe-clan.net>
>> wrote:
>> > >
>> > > > On Fri, 12 Apr 2013 10:47:29 -0500
>> > > > "William A. Rowe Jr." <wr...@rowe-clan.net> wrote:
>> > > >
>> > > > > On Tue, 26 Mar 2013 00:56:06 +0200
>> > > > > Daniel Shahaf <d....@daniel.shahaf.name> wrote:
>> > > > >
>> > > > > > Can you write this all down somewhere? A wiki page maybe
>> > > > >
>> > > > > http://wiki.apache.org/general/ASFCodeSigning
>> > > >
>> > > > Could one of the page editors please grant WilliamARoweJr some
>> > > > karma? I'll document the first-draft approach and the Symantec
>> > > > service-based approach.
>> > > >
>> > >
>> > >
>> >
>>
> I am truly sorry that I tried to help....with those 2 replies, I only
> forwarded a mail for your information, I will for sure forget all about
> code signing, and leave it to the experts.
>
> During the discussion on IRC, a blog from adobe was thrown in, showing just
> how complicated it can be for full time security profs. to ensure the
> certificate is not misused.
>
> I am sorry I defended our viewpoint, and made this list aware that there
> are other projects with similar needs. You just managed to kill the
> messenger, next time this issue is discussed on IRC, I will refer to this
> thread and keep silent.
>
Jan, I'm sure we all appreciate your attempt to "defend our
viewpoint", but you might not be aware that this has been discussed
repeatedly with Infra, since before you were even involved in the
project. If there is any frustration expressed it is not with you.
The fact that security is hard or that other projects would benefit
from code signing -- none of this is news. That doesn't mean that you
were wrong to discuss it. It just means that you did not have the
information and background that Juergen and I have from trying to push
this forward over a much longer period of time.
There is a thread with 93 posts on infra-dev on this topic dating back
a year. It probably makes sense to read up on what has been discussed
previously before as background information.
-Rob
> rgds
> jan I.
>
>>
>> >
>>
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Official code signing certificate
Posted by janI <ja...@apache.org>.
On 24 May 2013 22:30, Juergen Schmidt <jo...@gmail.com> wrote:
>
>
> Am Freitag, 24. Mai 2013 um 19:50 schrieb janI:
>
> > Hi.
> >
> > we are not alone in ASF wishing code signing, but we might get run over
> (as
> > I did today on IRC) if we do not formulate our requirements very clearly.
> >
> >
>
> decisions are made on mailing lists, correct? That is what I learned at
> Apache, what not happened on a mailing list, is not relevant ;-)
> Well it seems that infra is always special.
> I tried several times to discuss it on the infra mailing list and I
> believe I have described very clearly what we need and how it works today
> for OpenOffice if we would have a cert. I also proposed a solution that can
> work from my point of view and I started to collect the info on a wiki page
> as suggested.
> There might be other solutions to do it but I have no in place and nobody
> convinced me that my proposed approach can not work.
> I agree that it's not easy and I simply have no energy to discuss further
> at the moment. I have enough other things to do.
>
> Juergen
> >
> > rgds
> > jan I.
> >
> > ---------- Forwarded message ----------
> > From: Scott Deboy <sc...@gmail.com>
> > Date: 24 May 2013 18:59
> > Subject: Re: Official code signing certificate
> > To: infrastructure-dev@apache.org
> >
> >
> > Logging Services has a simple requirement:
> >
> > Have the Chainsaw build artifacts signed by a Java code signing cert
> > that is signed by a trusted/root CA so the jars can be downloaded via
> > WebStart without the user receiving a warning that the signed jars
> > aren't trusted.
> >
> > The Chainsaw maven script supports signing jars - infra just needs to
> > point it to the cert.
> >
> > I don't know whether or not an ASF-wide Java code signing cert makes
> > sense or a Logging Services-specific Java code signing cert makes
> > sense. I don't even know if it is possible to have TLP-specific Java
> > code signing certs. I defer to infra on that decision.
> >
> > I believe the code signing service WRowe described will meet our
> > requirements. Hopefully infra can spend some time looking at the
> > service and see how it can meet their requirements.
> >
> > Logging Services would like to be a guinea pig for the Java code
> > signing service WRowe described above. If there are additional
> > details needed by infra, we are happy to provide them.
> >
> > Thanks,
> >
> > Scott
> >
> > On 4/12/13, sebb <se...@gmail.com> wrote:
> > > You are now in http://wiki.apache.org/general/ContributorsGroup
> > >
> > >
> > > On 12 April 2013 17:32, William A. Rowe Jr. <wr...@rowe-clan.net>
> wrote:
> > >
> > > > On Fri, 12 Apr 2013 10:47:29 -0500
> > > > "William A. Rowe Jr." <wr...@rowe-clan.net> wrote:
> > > >
> > > > > On Tue, 26 Mar 2013 00:56:06 +0200
> > > > > Daniel Shahaf <d....@daniel.shahaf.name> wrote:
> > > > >
> > > > > > Can you write this all down somewhere? A wiki page maybe
> > > > >
> > > > > http://wiki.apache.org/general/ASFCodeSigning
> > > >
> > > > Could one of the page editors please grant WilliamARoweJr some
> > > > karma? I'll document the first-draft approach and the Symantec
> > > > service-based approach.
> > > >
> > >
> > >
> >
>
I am truly sorry that I tried to help....with those 2 replies, I only
forwarded a mail for your information, I will for sure forget all about
code signing, and leave it to the experts.
During the discussion on IRC, a blog from adobe was thrown in, showing just
how complicated it can be for full time security profs. to ensure the
certificate is not misused.
I am sorry I defended our viewpoint, and made this list aware that there
are other projects with similar needs. You just managed to kill the
messenger, next time this issue is discussed on IRC, I will refer to this
thread and keep silent.
rgds
jan I.
>
> >
>
>
>
Re: Official code signing certificate
Posted by Juergen Schmidt <jo...@gmail.com>.
Am Freitag, 24. Mai 2013 um 19:50 schrieb janI:
> Hi.
>
> we are not alone in ASF wishing code signing, but we might get run over (as
> I did today on IRC) if we do not formulate our requirements very clearly.
>
>
decisions are made on mailing lists, correct? That is what I learned at Apache, what not happened on a mailing list, is not relevant ;-)
Well it seems that infra is always special.
I tried several times to discuss it on the infra mailing list and I believe I have described very clearly what we need and how it works today for OpenOffice if we would have a cert. I also proposed a solution that can work from my point of view and I started to collect the info on a wiki page as suggested.
There might be other solutions to do it but I have no in place and nobody convinced me that my proposed approach can not work.
I agree that it's not easy and I simply have no energy to discuss further at the moment. I have enough other things to do.
Juergen
>
> rgds
> jan I.
>
> ---------- Forwarded message ----------
> From: Scott Deboy <sc...@gmail.com>
> Date: 24 May 2013 18:59
> Subject: Re: Official code signing certificate
> To: infrastructure-dev@apache.org
>
>
> Logging Services has a simple requirement:
>
> Have the Chainsaw build artifacts signed by a Java code signing cert
> that is signed by a trusted/root CA so the jars can be downloaded via
> WebStart without the user receiving a warning that the signed jars
> aren't trusted.
>
> The Chainsaw maven script supports signing jars - infra just needs to
> point it to the cert.
>
> I don't know whether or not an ASF-wide Java code signing cert makes
> sense or a Logging Services-specific Java code signing cert makes
> sense. I don't even know if it is possible to have TLP-specific Java
> code signing certs. I defer to infra on that decision.
>
> I believe the code signing service WRowe described will meet our
> requirements. Hopefully infra can spend some time looking at the
> service and see how it can meet their requirements.
>
> Logging Services would like to be a guinea pig for the Java code
> signing service WRowe described above. If there are additional
> details needed by infra, we are happy to provide them.
>
> Thanks,
>
> Scott
>
> On 4/12/13, sebb <se...@gmail.com> wrote:
> > You are now in http://wiki.apache.org/general/ContributorsGroup
> >
> >
> > On 12 April 2013 17:32, William A. Rowe Jr. <wr...@rowe-clan.net> wrote:
> >
> > > On Fri, 12 Apr 2013 10:47:29 -0500
> > > "William A. Rowe Jr." <wr...@rowe-clan.net> wrote:
> > >
> > > > On Tue, 26 Mar 2013 00:56:06 +0200
> > > > Daniel Shahaf <d....@daniel.shahaf.name> wrote:
> > > >
> > > > > Can you write this all down somewhere? A wiki page maybe
> > > >
> > > > http://wiki.apache.org/general/ASFCodeSigning
> > >
> > > Could one of the page editors please grant WilliamARoweJr some
> > > karma? I'll document the first-draft approach and the Symantec
> > > service-based approach.
> > >
> >
> >
>
>
>
Re: Official code signing certificate
Posted by Rob Weir <ro...@apache.org>.
On Fri, May 24, 2013 at 1:50 PM, janI <ja...@apache.org> wrote:
> Hi.
>
> we are not alone in ASF wishing code signing, but we might get run over (as
> I did today on IRC) if we do not formulate our requirements very clearly.
>
Can you give us a better sense of what part of AOO code signing is
unclear to Infra? We've been discussing this for more than a year
now, so I'd be surprised if there are any technological questions
remaining at this point.
-Rob
> rgds
> jan I.
>
> ---------- Forwarded message ----------
> From: Scott Deboy <sc...@gmail.com>
> Date: 24 May 2013 18:59
> Subject: Re: Official code signing certificate
> To: infrastructure-dev@apache.org
>
>
> Logging Services has a simple requirement:
>
> Have the Chainsaw build artifacts signed by a Java code signing cert
> that is signed by a trusted/root CA so the jars can be downloaded via
> WebStart without the user receiving a warning that the signed jars
> aren't trusted.
>
> The Chainsaw maven script supports signing jars - infra just needs to
> point it to the cert.
>
> I don't know whether or not an ASF-wide Java code signing cert makes
> sense or a Logging Services-specific Java code signing cert makes
> sense. I don't even know if it is possible to have TLP-specific Java
> code signing certs. I defer to infra on that decision.
>
> I believe the code signing service WRowe described will meet our
> requirements. Hopefully infra can spend some time looking at the
> service and see how it can meet their requirements.
>
> Logging Services would like to be a guinea pig for the Java code
> signing service WRowe described above. If there are additional
> details needed by infra, we are happy to provide them.
>
> Thanks,
>
> Scott
>
> On 4/12/13, sebb <se...@gmail.com> wrote:
>> You are now in http://wiki.apache.org/general/ContributorsGroup
>>
>>
>> On 12 April 2013 17:32, William A. Rowe Jr. <wr...@rowe-clan.net> wrote:
>>
>>> On Fri, 12 Apr 2013 10:47:29 -0500
>>> "William A. Rowe Jr." <wr...@rowe-clan.net> wrote:
>>>
>>> > On Tue, 26 Mar 2013 00:56:06 +0200
>>> > Daniel Shahaf <d....@daniel.shahaf.name> wrote:
>>> >
>>> > > Can you write this all down somewhere? A wiki page maybe
>>> >
>>> > http://wiki.apache.org/general/ASFCodeSigning
>>>
>>> Could one of the page editors please grant WilliamARoweJr some
>>> karma? I'll document the first-draft approach and the Symantec
>>> service-based approach.
>>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Fwd: Official code signing certificate
Posted by janI <ja...@apache.org>.
Hi.
we are not alone in ASF wishing code signing, but we might get run over (as
I did today on IRC) if we do not formulate our requirements very clearly.
rgds
jan I.
---------- Forwarded message ----------
From: Scott Deboy <sc...@gmail.com>
Date: 24 May 2013 18:59
Subject: Re: Official code signing certificate
To: infrastructure-dev@apache.org
Logging Services has a simple requirement:
Have the Chainsaw build artifacts signed by a Java code signing cert
that is signed by a trusted/root CA so the jars can be downloaded via
WebStart without the user receiving a warning that the signed jars
aren't trusted.
The Chainsaw maven script supports signing jars - infra just needs to
point it to the cert.
I don't know whether or not an ASF-wide Java code signing cert makes
sense or a Logging Services-specific Java code signing cert makes
sense. I don't even know if it is possible to have TLP-specific Java
code signing certs. I defer to infra on that decision.
I believe the code signing service WRowe described will meet our
requirements. Hopefully infra can spend some time looking at the
service and see how it can meet their requirements.
Logging Services would like to be a guinea pig for the Java code
signing service WRowe described above. If there are additional
details needed by infra, we are happy to provide them.
Thanks,
Scott
On 4/12/13, sebb <se...@gmail.com> wrote:
> You are now in http://wiki.apache.org/general/ContributorsGroup
>
>
> On 12 April 2013 17:32, William A. Rowe Jr. <wr...@rowe-clan.net> wrote:
>
>> On Fri, 12 Apr 2013 10:47:29 -0500
>> "William A. Rowe Jr." <wr...@rowe-clan.net> wrote:
>>
>> > On Tue, 26 Mar 2013 00:56:06 +0200
>> > Daniel Shahaf <d....@daniel.shahaf.name> wrote:
>> >
>> > > Can you write this all down somewhere? A wiki page maybe
>> >
>> > http://wiki.apache.org/general/ASFCodeSigning
>>
>> Could one of the page editors please grant WilliamARoweJr some
>> karma? I'll document the first-draft approach and the Symantec
>> service-based approach.
>>
>
Re: Official code signing certificate
Posted by janI <ja...@apache.org>.
On 4 June 2013 22:34, Juergen Schmidt <jo...@gmail.com> wrote:
> Am Dienstag, 4. Juni 2013 um 21:52 schrieb Mark Thomas:
> > On 24/05/2013 17:59, Scott Deboy wrote:
> > > Logging Services has a simple requirement:
> > >
> > > Have the Chainsaw build artifacts signed by a Java code signing cert
> > > that is signed by a trusted/root CA so the jars can be downloaded via
> > > WebStart without the user receiving a warning that the signed jars
> > > aren't trusted.
> > >
> > > The Chainsaw maven script supports signing jars - infra just needs to
> > > point it to the cert.
> > >
> > > I don't know whether or not an ASF-wide Java code signing cert makes
> > > sense or a Logging Services-specific Java code signing cert makes
> > > sense. I don't even know if it is possible to have TLP-specific Java
> > > code signing certs. I defer to infra on that decision.
> > >
> > > I believe the code signing service WRowe described will meet our
> > > requirements. Hopefully infra can spend some time looking at the
> > > service and see how it can meet their requirements.
> > >
> > > Logging Services would like to be a guinea pig for the Java code
> > > signing service WRowe described above. If there are additional
> > > details needed by infra, we are happy to provide them.
> > >
> >
> >
> > OK. That requirement is understood.
> >
> > Code signing is on my TODO list after I have completed the current round
> > of FreeBSD upgrades and after I have a cert arranged for
> > *.openoffice.org. That means it is at least a month before I'll have the
> > time this needs to progress it.
> >
> > My (very) rough plan is to see if Verisign are still willing to offer us
> > the free signing service and then work through how that might work.
> >
> > The keys things for infra are:
> > - minimising the risk that malicious code is signed
> > - having a plan if to handle things if the worst does happen
> > - ensure that the inputs to the signing process have been approved by
> > the PMC signing
> > - figure out what role infra needs to play in the signing process
> >
> > I intend to use Tomcat to test this with as it has JARs and .exe's that
> > can be signed and I have the necessary commit privs to modify the build
> > process if required.
> >
> > If you want to help progress this then reaching out to Bill and
> > re-connecting with Verisign would be a useful thing to do. In an ideal
> > world if you can line things up so I can get what I need (service docs,
> > how to register for the service, how to use the service, etc.) to start
> > testing / investigating this that would be great.
> >
> Hi Mark,
>
> I am still available to provide more info regarding the requirements of
> OpenOffice. As mentioned earlier in a discussion related to code signing,
> we have a multistep signing process in place during the build process and
> when we gave the cert under full control. This has to adapted in a way that
> is appropriate to the new process. I believe the OpenOffice requirements
> are the mist complex ones and O hope we can find a working and what's more
> important secure and save workflow that satisfy all requirements.
>
Knowing both AOO and infra I am sure we can find common ground here.
@mark, I am happy to be you "working force" if you need an extra pair of
hands.
rgds
jan I.
>
> Regards
> Juergen
> >
> > Mark
> >
> > >
> > > Thanks,
> > >
> > > Scott
> > >
> > > On 4/12/13, sebb <se...@gmail.com> wrote:
> > > > You are now in http://wiki.apache.org/general/ContributorsGroup
> > > >
> > > >
> > > > On 12 April 2013 17:32, William A. Rowe Jr. <wr...@rowe-clan.net>
> wrote:
> > > >
> > > > > On Fri, 12 Apr 2013 10:47:29 -0500
> > > > > "William A. Rowe Jr." <wr...@rowe-clan.net> wrote:
> > > > >
> > > > > > On Tue, 26 Mar 2013 00:56:06 +0200
> > > > > > Daniel Shahaf <d....@daniel.shahaf.name> wrote:
> > > > > >
> > > > > > > Can you write this all down somewhere? A wiki page maybe
> > > > > >
> > > > > > http://wiki.apache.org/general/ASFCodeSigning
> > > > >
> > > > > Could one of the page editors please grant WilliamARoweJr some
> > > > > karma? I'll document the first-draft approach and the Symantec
> > > > > service-based approach.
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
> >
>
>
>
Re: Official code signing certificate
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Tue, Jun 4, 2013 at 10:34 PM, Juergen Schmidt <jo...@gmail.com> wrote:
> ...I am still available to provide more info regarding the requirements of OpenOffice...
There's some at http://wiki.apache.org/general/ASFCodeSigning already
(which you added IIUC), would be good to keep that up to date IMO as
other projects might have similar needs.
-Bertrand
Re: Official code signing certificate
Posted by Juergen Schmidt <jo...@gmail.com>.
Am Dienstag, 4. Juni 2013 um 21:52 schrieb Mark Thomas:
> On 24/05/2013 17:59, Scott Deboy wrote:
> > Logging Services has a simple requirement:
> >
> > Have the Chainsaw build artifacts signed by a Java code signing cert
> > that is signed by a trusted/root CA so the jars can be downloaded via
> > WebStart without the user receiving a warning that the signed jars
> > aren't trusted.
> >
> > The Chainsaw maven script supports signing jars - infra just needs to
> > point it to the cert.
> >
> > I don't know whether or not an ASF-wide Java code signing cert makes
> > sense or a Logging Services-specific Java code signing cert makes
> > sense. I don't even know if it is possible to have TLP-specific Java
> > code signing certs. I defer to infra on that decision.
> >
> > I believe the code signing service WRowe described will meet our
> > requirements. Hopefully infra can spend some time looking at the
> > service and see how it can meet their requirements.
> >
> > Logging Services would like to be a guinea pig for the Java code
> > signing service WRowe described above. If there are additional
> > details needed by infra, we are happy to provide them.
> >
>
>
> OK. That requirement is understood.
>
> Code signing is on my TODO list after I have completed the current round
> of FreeBSD upgrades and after I have a cert arranged for
> *.openoffice.org. That means it is at least a month before I'll have the
> time this needs to progress it.
>
> My (very) rough plan is to see if Verisign are still willing to offer us
> the free signing service and then work through how that might work.
>
> The keys things for infra are:
> - minimising the risk that malicious code is signed
> - having a plan if to handle things if the worst does happen
> - ensure that the inputs to the signing process have been approved by
> the PMC signing
> - figure out what role infra needs to play in the signing process
>
> I intend to use Tomcat to test this with as it has JARs and .exe's that
> can be signed and I have the necessary commit privs to modify the build
> process if required.
>
> If you want to help progress this then reaching out to Bill and
> re-connecting with Verisign would be a useful thing to do. In an ideal
> world if you can line things up so I can get what I need (service docs,
> how to register for the service, how to use the service, etc.) to start
> testing / investigating this that would be great.
>
Hi Mark,
I am still available to provide more info regarding the requirements of OpenOffice. As mentioned earlier in a discussion related to code signing, we have a multistep signing process in place during the build process and when we gave the cert under full control. This has to adapted in a way that is appropriate to the new process. I believe the OpenOffice requirements are the mist complex ones and O hope we can find a working and what's more important secure and save workflow that satisfy all requirements.
Regards
Juergen
>
> Mark
>
> >
> > Thanks,
> >
> > Scott
> >
> > On 4/12/13, sebb <se...@gmail.com> wrote:
> > > You are now in http://wiki.apache.org/general/ContributorsGroup
> > >
> > >
> > > On 12 April 2013 17:32, William A. Rowe Jr. <wr...@rowe-clan.net> wrote:
> > >
> > > > On Fri, 12 Apr 2013 10:47:29 -0500
> > > > "William A. Rowe Jr." <wr...@rowe-clan.net> wrote:
> > > >
> > > > > On Tue, 26 Mar 2013 00:56:06 +0200
> > > > > Daniel Shahaf <d....@daniel.shahaf.name> wrote:
> > > > >
> > > > > > Can you write this all down somewhere? A wiki page maybe
> > > > >
> > > > > http://wiki.apache.org/general/ASFCodeSigning
> > > >
> > > > Could one of the page editors please grant WilliamARoweJr some
> > > > karma? I'll document the first-draft approach and the Symantec
> > > > service-based approach.
> > > >
> > >
> > >
> >
> >
>
>
>
Re: Official code signing certificate
Posted by Mark Thomas <ma...@apache.org>.
On 24/05/2013 17:59, Scott Deboy wrote:
> Logging Services has a simple requirement:
>
> Have the Chainsaw build artifacts signed by a Java code signing cert
> that is signed by a trusted/root CA so the jars can be downloaded via
> WebStart without the user receiving a warning that the signed jars
> aren't trusted.
>
> The Chainsaw maven script supports signing jars - infra just needs to
> point it to the cert.
>
> I don't know whether or not an ASF-wide Java code signing cert makes
> sense or a Logging Services-specific Java code signing cert makes
> sense. I don't even know if it is possible to have TLP-specific Java
> code signing certs. I defer to infra on that decision.
>
> I believe the code signing service WRowe described will meet our
> requirements. Hopefully infra can spend some time looking at the
> service and see how it can meet their requirements.
>
> Logging Services would like to be a guinea pig for the Java code
> signing service WRowe described above. If there are additional
> details needed by infra, we are happy to provide them.
OK. That requirement is understood.
Code signing is on my TODO list after I have completed the current round
of FreeBSD upgrades and after I have a cert arranged for
*.openoffice.org. That means it is at least a month before I'll have the
time this needs to progress it.
My (very) rough plan is to see if Verisign are still willing to offer us
the free signing service and then work through how that might work.
The keys things for infra are:
- minimising the risk that malicious code is signed
- having a plan if to handle things if the worst does happen
- ensure that the inputs to the signing process have been approved by
the PMC signing
- figure out what role infra needs to play in the signing process
I intend to use Tomcat to test this with as it has JARs and .exe's that
can be signed and I have the necessary commit privs to modify the build
process if required.
If you want to help progress this then reaching out to Bill and
re-connecting with Verisign would be a useful thing to do. In an ideal
world if you can line things up so I can get what I need (service docs,
how to register for the service, how to use the service, etc.) to start
testing / investigating this that would be great.
Mark
>
> Thanks,
>
> Scott
>
> On 4/12/13, sebb <se...@gmail.com> wrote:
>> You are now in http://wiki.apache.org/general/ContributorsGroup
>>
>>
>> On 12 April 2013 17:32, William A. Rowe Jr. <wr...@rowe-clan.net> wrote:
>>
>>> On Fri, 12 Apr 2013 10:47:29 -0500
>>> "William A. Rowe Jr." <wr...@rowe-clan.net> wrote:
>>>
>>>> On Tue, 26 Mar 2013 00:56:06 +0200
>>>> Daniel Shahaf <d....@daniel.shahaf.name> wrote:
>>>>
>>>>> Can you write this all down somewhere? A wiki page maybe
>>>>
>>>> http://wiki.apache.org/general/ASFCodeSigning
>>>
>>> Could one of the page editors please grant WilliamARoweJr some
>>> karma? I'll document the first-draft approach and the Symantec
>>> service-based approach.
>>>
>>
Re: Official code signing certificate
Posted by Scott Deboy <sc...@gmail.com>.
I was asked to restate the request Logging Services has of Infra:\
Logging Services would like to provide infra with:
- A Chainsaw release candidate vote thread providing a link to the
release candidate build/svn rev
- Chainsaw's maven script supports Java code signing. Infra has to
provide the script with info on the location of the code signing cert
and keys etc.
I don't believe it makes sense for Logging Services to try to describe
the process Infra should be using to get the artifacts signed...we
just need signed artifacts. Infra understands their requirements
around security and workflow and we don't. I personally believe the
service WRowe described may work fine for our simple needs, and I
would hope Infra would look into it.
I would like to request that Infra please tell me if they understand
the requirements I've described and provide a technical solution that
will meet our needs.
Thanks,
Scott
On 5/24/13, Scott Deboy <sc...@gmail.com> wrote:
> Logging Services has a simple requirement:
>
> Have the Chainsaw build artifacts signed by a Java code signing cert
> that is signed by a trusted/root CA so the jars can be downloaded via
> WebStart without the user receiving a warning that the signed jars
> aren't trusted.
>
> The Chainsaw maven script supports signing jars - infra just needs to
> point it to the cert.
>
> I don't know whether or not an ASF-wide Java code signing cert makes
> sense or a Logging Services-specific Java code signing cert makes
> sense. I don't even know if it is possible to have TLP-specific Java
> code signing certs. I defer to infra on that decision.
>
> I believe the code signing service WRowe described will meet our
> requirements. Hopefully infra can spend some time looking at the
> service and see how it can meet their requirements.
>
> Logging Services would like to be a guinea pig for the Java code
> signing service WRowe described above. If there are additional
> details needed by infra, we are happy to provide them.
>
> Thanks,
>
> Scott
>
> On 4/12/13, sebb <se...@gmail.com> wrote:
>> You are now in http://wiki.apache.org/general/ContributorsGroup
>>
>>
>> On 12 April 2013 17:32, William A. Rowe Jr. <wr...@rowe-clan.net> wrote:
>>
>>> On Fri, 12 Apr 2013 10:47:29 -0500
>>> "William A. Rowe Jr." <wr...@rowe-clan.net> wrote:
>>>
>>> > On Tue, 26 Mar 2013 00:56:06 +0200
>>> > Daniel Shahaf <d....@daniel.shahaf.name> wrote:
>>> >
>>> > > Can you write this all down somewhere? A wiki page maybe
>>> >
>>> > http://wiki.apache.org/general/ASFCodeSigning
>>>
>>> Could one of the page editors please grant WilliamARoweJr some
>>> karma? I'll document the first-draft approach and the Symantec
>>> service-based approach.
>>>
>>
>
Re: Official code signing certificate
Posted by Scott Deboy <sc...@gmail.com>.
Logging Services has a simple requirement:
Have the Chainsaw build artifacts signed by a Java code signing cert
that is signed by a trusted/root CA so the jars can be downloaded via
WebStart without the user receiving a warning that the signed jars
aren't trusted.
The Chainsaw maven script supports signing jars - infra just needs to
point it to the cert.
I don't know whether or not an ASF-wide Java code signing cert makes
sense or a Logging Services-specific Java code signing cert makes
sense. I don't even know if it is possible to have TLP-specific Java
code signing certs. I defer to infra on that decision.
I believe the code signing service WRowe described will meet our
requirements. Hopefully infra can spend some time looking at the
service and see how it can meet their requirements.
Logging Services would like to be a guinea pig for the Java code
signing service WRowe described above. If there are additional
details needed by infra, we are happy to provide them.
Thanks,
Scott
On 4/12/13, sebb <se...@gmail.com> wrote:
> You are now in http://wiki.apache.org/general/ContributorsGroup
>
>
> On 12 April 2013 17:32, William A. Rowe Jr. <wr...@rowe-clan.net> wrote:
>
>> On Fri, 12 Apr 2013 10:47:29 -0500
>> "William A. Rowe Jr." <wr...@rowe-clan.net> wrote:
>>
>> > On Tue, 26 Mar 2013 00:56:06 +0200
>> > Daniel Shahaf <d....@daniel.shahaf.name> wrote:
>> >
>> > > Can you write this all down somewhere? A wiki page maybe
>> >
>> > http://wiki.apache.org/general/ASFCodeSigning
>>
>> Could one of the page editors please grant WilliamARoweJr some
>> karma? I'll document the first-draft approach and the Symantec
>> service-based approach.
>>
>
Re: Official code signing certificate
Posted by sebb <se...@gmail.com>.
You are now in http://wiki.apache.org/general/ContributorsGroup
On 12 April 2013 17:32, William A. Rowe Jr. <wr...@rowe-clan.net> wrote:
> On Fri, 12 Apr 2013 10:47:29 -0500
> "William A. Rowe Jr." <wr...@rowe-clan.net> wrote:
>
> > On Tue, 26 Mar 2013 00:56:06 +0200
> > Daniel Shahaf <d....@daniel.shahaf.name> wrote:
> >
> > > Can you write this all down somewhere? A wiki page maybe
> >
> > http://wiki.apache.org/general/ASFCodeSigning
>
> Could one of the page editors please grant WilliamARoweJr some
> karma? I'll document the first-draft approach and the Symantec
> service-based approach.
>
Re: Official code signing certificate
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On Fri, 12 Apr 2013 10:47:29 -0500
"William A. Rowe Jr." <wr...@rowe-clan.net> wrote:
> On Tue, 26 Mar 2013 00:56:06 +0200
> Daniel Shahaf <d....@daniel.shahaf.name> wrote:
>
> > Can you write this all down somewhere? A wiki page maybe
>
> http://wiki.apache.org/general/ASFCodeSigning
Could one of the page editors please grant WilliamARoweJr some
karma? I'll document the first-draft approach and the Symantec
service-based approach.
Re: Official code signing certificate
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On Tue, 26 Mar 2013 00:56:06 +0200
Daniel Shahaf <d....@daniel.shahaf.name> wrote:
> Can you write this all down somewhere? A wiki page maybe, or a *.txt
> file under (a new dir under)
> https://svn.apache.org/repos/infra/infrastructure/trunk/projects/
> (world-readable subtree).
http://wiki.apache.org/general/ASFCodeSigning
Also from the archives, sigh.
Re: Official code signing certificate
Posted by Jürgen Schmidt <jo...@gmail.com>.
On 3/25/13 11:56 PM, Daniel Shahaf wrote:
> Rob Weir wrote on Mon, Mar 25, 2013 at 12:06:13 -0400:
>> On Fri, Mar 22, 2013 at 12:57 PM, Daniel Shahaf <d....@daniel.shahaf.name> wrote:
>>> Rob Weir wrote on Fri, Mar 22, 2013 at 10:44:45 -0400:
>>>> On Thu, Mar 21, 2013 at 6:18 PM, Daniel Shahaf <d....@daniel.shahaf.name> wrote:
>>>>> Rob Weir wrote on Thu, Mar 21, 2013 at 11:35:21 -0400:
>>>>>> On Thu, Mar 21, 2013 at 9:09 AM, Daniel Shahaf <d....@daniel.shahaf.name> wrote:
>>>>>>> For example: does releasing software under a certificate Microsoft
>>>>>>> pre-trusts (or into an app store Apple moderates) subject ASF to an
>>>>>>> indemnification clause towards that company? Does it grant the company
>>>>>>> a license to use our trademarks in advertising? Does it compel ASF to
>>>>>>> offer warranty to end-users?
>>>>>>
>>>>>> I believe that we'd be required to make some sort of assertion that
>>>>>> our code does not contain intentionally malicious software, but I
>>>>>> don't know the details of that statement.
>>>>>>
>>>>>> In any case, if possible, let's focus on the Infra side of this here.
>>>>>> We should separately review the language of any agreements we need to
>>>>>> sign with Legal Affairs and/or the Board.
>>>>>>
>>>>>
>>>>> Technically I don't imagine there's much question here. You guys
>>>>> already have code that builds+signs, the ONLY thing it's missing is a
>>>>> file containing an X509 signing cert signed by somebody whom Windows
>>>>> trusts by default, right? Once we obtain such a file, is there any
>>>>> reason we won't be able to put it on a VM and run your code inside that
>>>>> VM against that file? I expect not, so I'm moving on to the legal
>>>>> sides.
>>>>>
>>>>
>>>> The remaining question would be if we need any safeguards against
>>>> hypothetical compromised committer accounts.
>>>>
>>>> I think we want to avoid something like this:
>>>>
>>>> 1) Someone acquires login credentials for a committer, e.g., they use
>>>> the same password at Apache as they use for some other web service
>>>> that is hacked.
>>>>
>>>> 2) They check-in a backdoor into the code
>>>>
>>>> 3) Before CTR finds the problem the buildbots have built and signed
>>>> the executables and the hacker has downloaded them.
>>>>
>>>> 4) We have malicious code now distributed signed with the Apache certificate.
>>>>
>>>> So from a process view, we might want to have routine builds be signed
>>>> with a placeholder test certificate (essentially self-signed) and this
>>>> test certificate is in SVN. The real signing certificate would only
>>>> be applied on Release Candidates and with additional safeguards.
>>>> Maybe the request needs to come from the PMC Chair or the Release
>>>> Manager? Or some time must elapse between the date of the SVN
>>>> revision and the signing?
>>>>
>>>
>>> How about only signing with the real certificate once three PMC members
>>> PGP-signed the binaries-built-against-the-self-signed-certificate.
>>>
>>
>> I like the idea of having multiple PMC members attest to the RC, by
>> signing or whatever. But we still would need to tie that back to a
>> SVN revision number somehow. In other words, how we do prove the
>> revision number that was used to build the RC?
>>
>
> Can't we just keep the working copy that built the original binaries
> around (for say four weeks) and run 'make' in it again, pointing the
> build to a different certificate?
>
> Maybe we should umount the build tree while the human verification is
> happenning.
>
>> Perhaps the flow is like this:
>>
>> 1) RC built by buildbot and that records the SVN revision.
>>
>> 2) Three PMC members sign the RC
>>
>
> For clarity: PGP-sign.
>
>> 3) Comparison of the MD5 hashes for the signed RC and the buildbot
>> output confirms the revision that was used.
>>
>> 4) Infra then releases the signing cert for use by buildbot automation
>> to rebuild the same revision
>>
>
> Well that works but it has more moving parts: the artifacts need to
> encode the path@rev they were built from and then the build process has
> to extract those. Also the build process uses a new working copy so
> it'll rebuild everything from scratch: that (a) takes longer,
> (b) subjects you to the risk of upgraded system dependencies (libc, gcc,
> etc.) used in the new build.
the baseline of the dedicated build machines should be maintained
carefully. We for example build on special Linux systems to ensure that
our binaries are worked on as many as possible Linux distros.
We in AOO retrieve already the svn revision during the build process and
put this information in the about dialog for reference. And we retrieve
"Last Changed Rev: *******" in our AOO related tree to avoid confusion.
>
> Can you write this all down somewhere? A wiki page maybe, or a *.txt
> file under (a new dir under)
> https://svn.apache.org/repos/infra/infrastructure/trunk/projects/
> (world-readable subtree).
everybody is free to extend additional information on the already
started wiki page http://wiki.apache.org/general/ASFCodeSigning
I don't think we need a further one. By the way this page is not new and
was proposed weeks ago to collect requirements and general information.
One reason why I have restarted the discussion in this thread.
Juergen
>
> Cheers
>
> Daniel
>
>>
>>> I follow the rest of your logic, makes sense.
>>>
>>>> You might think that we'd vote on the RC and only sign it after that.
>>>> But that doesn't work because the signature is applied at multiple
>>>> levels of the packaging. So the individual EXE and DLL's are signed,
>>>> as well as the installer and the outermost archive packaging.
>>>>
>>>> One option would be to vote to approve the RC and then rebuild the
>>>> exact same revision that was approved, with no other changes than
>>>> replacing the test cert with the real signing cert.
>>>>
>>>>> And yes, I do need to at least think of the legal side before I start:
>>>>> if, say, Company X's terms include a use-in-advertising license and VP
>>>>> Brand vetoes that, then there's no point in burning Infra cycles on
>>>>> thinking of how to make it work with Company X.
>>>>>
>>>>
>>>> Dennis gave a link to the Symantec agreement. I don't see any
>>>> trademark or advertising related clause. But we obviously need to
>>>
>>> Oh, thanks. I missed that in his email.
>>>
>>>> make a thorough review. There are other CA's as well who might offer
>>>> different terms.
>>>>
>>>> Regards,
>>>>
>>>> -Rob
>>>>
>>>>>> Regards,
>>>>>>
>>>>>> -Rob
Re: Official code signing certificate
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Rob Weir wrote on Mon, Mar 25, 2013 at 12:06:13 -0400:
> On Fri, Mar 22, 2013 at 12:57 PM, Daniel Shahaf <d....@daniel.shahaf.name> wrote:
> > Rob Weir wrote on Fri, Mar 22, 2013 at 10:44:45 -0400:
> >> On Thu, Mar 21, 2013 at 6:18 PM, Daniel Shahaf <d....@daniel.shahaf.name> wrote:
> >> > Rob Weir wrote on Thu, Mar 21, 2013 at 11:35:21 -0400:
> >> >> On Thu, Mar 21, 2013 at 9:09 AM, Daniel Shahaf <d....@daniel.shahaf.name> wrote:
> >> >> > For example: does releasing software under a certificate Microsoft
> >> >> > pre-trusts (or into an app store Apple moderates) subject ASF to an
> >> >> > indemnification clause towards that company? Does it grant the company
> >> >> > a license to use our trademarks in advertising? Does it compel ASF to
> >> >> > offer warranty to end-users?
> >> >>
> >> >> I believe that we'd be required to make some sort of assertion that
> >> >> our code does not contain intentionally malicious software, but I
> >> >> don't know the details of that statement.
> >> >>
> >> >> In any case, if possible, let's focus on the Infra side of this here.
> >> >> We should separately review the language of any agreements we need to
> >> >> sign with Legal Affairs and/or the Board.
> >> >>
> >> >
> >> > Technically I don't imagine there's much question here. You guys
> >> > already have code that builds+signs, the ONLY thing it's missing is a
> >> > file containing an X509 signing cert signed by somebody whom Windows
> >> > trusts by default, right? Once we obtain such a file, is there any
> >> > reason we won't be able to put it on a VM and run your code inside that
> >> > VM against that file? I expect not, so I'm moving on to the legal
> >> > sides.
> >> >
> >>
> >> The remaining question would be if we need any safeguards against
> >> hypothetical compromised committer accounts.
> >>
> >> I think we want to avoid something like this:
> >>
> >> 1) Someone acquires login credentials for a committer, e.g., they use
> >> the same password at Apache as they use for some other web service
> >> that is hacked.
> >>
> >> 2) They check-in a backdoor into the code
> >>
> >> 3) Before CTR finds the problem the buildbots have built and signed
> >> the executables and the hacker has downloaded them.
> >>
> >> 4) We have malicious code now distributed signed with the Apache certificate.
> >>
> >> So from a process view, we might want to have routine builds be signed
> >> with a placeholder test certificate (essentially self-signed) and this
> >> test certificate is in SVN. The real signing certificate would only
> >> be applied on Release Candidates and with additional safeguards.
> >> Maybe the request needs to come from the PMC Chair or the Release
> >> Manager? Or some time must elapse between the date of the SVN
> >> revision and the signing?
> >>
> >
> > How about only signing with the real certificate once three PMC members
> > PGP-signed the binaries-built-against-the-self-signed-certificate.
> >
>
> I like the idea of having multiple PMC members attest to the RC, by
> signing or whatever. But we still would need to tie that back to a
> SVN revision number somehow. In other words, how we do prove the
> revision number that was used to build the RC?
>
Can't we just keep the working copy that built the original binaries
around (for say four weeks) and run 'make' in it again, pointing the
build to a different certificate?
Maybe we should umount the build tree while the human verification is
happenning.
> Perhaps the flow is like this:
>
> 1) RC built by buildbot and that records the SVN revision.
>
> 2) Three PMC members sign the RC
>
For clarity: PGP-sign.
> 3) Comparison of the MD5 hashes for the signed RC and the buildbot
> output confirms the revision that was used.
>
> 4) Infra then releases the signing cert for use by buildbot automation
> to rebuild the same revision
>
Well that works but it has more moving parts: the artifacts need to
encode the path@rev they were built from and then the build process has
to extract those. Also the build process uses a new working copy so
it'll rebuild everything from scratch: that (a) takes longer,
(b) subjects you to the risk of upgraded system dependencies (libc, gcc,
etc.) used in the new build.
Can you write this all down somewhere? A wiki page maybe, or a *.txt
file under (a new dir under)
https://svn.apache.org/repos/infra/infrastructure/trunk/projects/
(world-readable subtree).
Cheers
Daniel
>
> > I follow the rest of your logic, makes sense.
> >
> >> You might think that we'd vote on the RC and only sign it after that.
> >> But that doesn't work because the signature is applied at multiple
> >> levels of the packaging. So the individual EXE and DLL's are signed,
> >> as well as the installer and the outermost archive packaging.
> >>
> >> One option would be to vote to approve the RC and then rebuild the
> >> exact same revision that was approved, with no other changes than
> >> replacing the test cert with the real signing cert.
> >>
> >> > And yes, I do need to at least think of the legal side before I start:
> >> > if, say, Company X's terms include a use-in-advertising license and VP
> >> > Brand vetoes that, then there's no point in burning Infra cycles on
> >> > thinking of how to make it work with Company X.
> >> >
> >>
> >> Dennis gave a link to the Symantec agreement. I don't see any
> >> trademark or advertising related clause. But we obviously need to
> >
> > Oh, thanks. I missed that in his email.
> >
> >> make a thorough review. There are other CA's as well who might offer
> >> different terms.
> >>
> >> Regards,
> >>
> >> -Rob
> >>
> >> >> Regards,
> >> >>
> >> >> -Rob
Re: Official code signing certificate
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Rob Weir wrote on Mon, Mar 25, 2013 at 12:06:13 -0400:
> On Fri, Mar 22, 2013 at 12:57 PM, Daniel Shahaf <d....@daniel.shahaf.name> wrote:
> > Rob Weir wrote on Fri, Mar 22, 2013 at 10:44:45 -0400:
> >> So from a process view, we might want to have routine builds be signed
> >> with a placeholder test certificate (essentially self-signed) and this
> >> test certificate is in SVN. The real signing certificate would only
> >> be applied on Release Candidates and with additional safeguards.
> >> Maybe the request needs to come from the PMC Chair or the Release
> >> Manager? Or some time must elapse between the date of the SVN
> >> revision and the signing?
> >>
> >
> > How about only signing with the real certificate once three PMC members
> > PGP-signed the binaries-built-against-the-self-signed-certificate.
> >
>
> I like the idea of having multiple PMC members attest to the RC, by
> signing or whatever. But we still would need to tie that back to a
> SVN revision number somehow. In other words, how we do prove the
> revision number that was used to build the RC?
>
> Perhaps the flow is like this:
>
> 1) RC built by buildbot and that records the SVN revision.
>
> 2) Three PMC members sign the RC
>
> 3) Comparison of the MD5 hashes for the signed RC and the buildbot
> output confirms the revision that was used.
>
As an aside, I'd use a stronger hash algorithm than md5 here.
Daniel
> 4) Infra then releases the signing cert for use by buildbot automation
> to rebuild the same revision
Re: Official code signing certificate
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Clint Modien wrote on Mon, Mar 25, 2013 at 16:48:41 -0700:
> Should the key/cert ever be _suspected_ of being compromised and the
> key/cert needs to be changed… it will invalidate the currently signed
> code running on users systems.
>
Well that raises a few more questions.
Should we have just one cert? Or one cert per project, say? If so,
(a) should each project's builds happen as a separate OS user?, (b)
would end-user systems recognise that? (maybe they limit the chain
depth?)
> Some apps may not execute at all, some apps may not be able to update properly.
>
> I'm not sure if it's economical or not… but if the approach is to provide private keys and certs to each project it might be wise for them to also be unique for each project.
>
> That way if a cert/key pair is compromised in one project it doesn't impact other projects.
>
> Perhaps a protocol for simply requesting intial signing certs and a
> private key from infra to be protected by a few members of the PMC?
>
> And infra could then provide a strongly worded wiki page about the
> protection of the certs and keys and the consequences associated with
> compromised keys/certs.
>
I'm not terribly fond of the idea of giving a PMC member a private
signing key in the name of the org. We have enough trouble ensuring
committers keep their SSH key securely...
One option is secret sharing --- a 3-out-of-N signing scheme --- but I'm
not offhand aware of any implementations we can use.
Daniel
> On Mar 25, 2013, at 10:27 AM, Clint Modien <cm...@gmail.com> wrote:
>
> > When I worked on a project for Amazon the binaries were submitted via ssh to the security department along with an md5 file for each binary.
> >
> > Before the project started I was required to produce a step by step document for signing the code. (tools, downloads, setup)
> >
> > After the binaries were checked against their associated md5 hashes, security then simply signed the binaries according to the process outlined in the document.
> >
> > I was told that the cert and private key were kept on a usb stick in a safe and the protocols surrounding the handling of the usb stick were as strict as those used for nuclear launch codes.
> >
> > I feel like the process to sign most code nowadays does not require the cert+key be available during compilation… but I could be wrong.
> >
> > On Mar 25, 2013, at 9:06 AM, Rob Weir <ro...@apache.org> wrote:
> >>
> >> I like the idea of having multiple PMC members attest to the RC, by
> >> signing or whatever. But we still would need to tie that back to a
> >> SVN revision number somehow. In other words, how we do prove the
> >> revision number that was used to build the RC?
> >>
> >> Perhaps the flow is like this:
> >>
> >> 1) RC built by buildbot and that records the SVN revision.
> >>
> >> 2) Three PMC members sign the RC
> >>
> >> 3) Comparison of the MD5 hashes for the signed RC and the buildbot
> >> output confirms the revision that was used.
> >>
> >> 4) Infra then releases the signing cert for use by buildbot automation
> >> to rebuild the same revision
> >>
> >
>
Re: Official code signing certificate
Posted by Juergen Schmidt <jo...@gmail.com>.
Am Montag, 25. März 2013 um 18:27 schrieb Clint Modien:
> When I worked on a project for Amazon the binaries were submitted via ssh to the security department along with an md5 file for each binary.
>
> Before the project started I was required to produce a step by step document for signing the code. (tools, downloads, setup)
>
> After the binaries were checked against their associated md5 hashes, security then simply signed the binaries according to the process outlined in the document.
>
> I was told that the cert and private key were kept on a usb stick in a safe and the protocols surrounding the handling of the usb stick were as strict as those used for nuclear launch codes.
>
> I feel like the process to sign most code nowadays does not require the cert+key be available during compilation… but I could be wrong.
>
it works probably later as well but as pointed out earlier, AOO is huge and complex and the current process is a multistep signing process.
1. dlls, exe etc. are signed
2. these files get packaged and cab files are signed as well
3. self extracting exe is created and also signed
Well I have to double check if I remember all steps correct. But it is close to the steps described above. Accessing the cert during the build process is probably less error prone. Keep in mind we have many packages for different languages.
Important is to find a working and scalable process and for this a dedicated build machine seems to be one possible solution.
Juergen
>
> On Mar 25, 2013, at 9:06 AM, Rob Weir <ro...@apache.org> wrote:
> >
> > I like the idea of having multiple PMC members attest to the RC, by
> > signing or whatever. But we still would need to tie that back to a
> > SVN revision number somehow. In other words, how we do prove the
> > revision number that was used to build the RC?
> >
> > Perhaps the flow is like this:
> >
> > 1) RC built by buildbot and that records the SVN revision.
> >
> > 2) Three PMC members sign the RC
> >
> > 3) Comparison of the MD5 hashes for the signed RC and the buildbot
> > output confirms the revision that was used.
> >
> > 4) Infra then releases the signing cert for use by buildbot automation
> > to rebuild the same revision
> >
>
>
>
Re: Official code signing certificate
Posted by Mark Thomas <ma...@apache.org>.
On 12/04/2013 16:52, William A. Rowe Jr. wrote:
> As Rob is fond of pointing out, there are literally hundreds of
> moving parts in their release (and similarly in the httpd release
> as well - each loadable module must be signed). I've asked and
> been assured that the Symantec service would have a batch/group
> automation-friendly submission process that could make this
> relatively painless.
Bill,
I'd like to make some progress on this.
Given that we have gone around in circles a few times over excatly how
to handle code-signing I'd like to move forward with the Symantec
service and *if* we hit a snag then we can discuss alternative approaches.
I plan to use Tomcat as the first test case primarily since as I am a
Tomcat committer and part of the infra team using Tomcat means I have
the karma to fix stuff as issues arise.
Once we have this working for Tomcat's Windows installer, we can extend
this to other projects / artifact types (e.g. JARs).
In order to move this forward, who do I need to contact at Symantec to
set up whatever accounts etc are required.
Mark
Re: Official code signing certificate
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On Mon, 25 Mar 2013 16:48:41 -0700
Clint Modien <cm...@gmail.com> wrote:
> I'm not sure if it's economical or not… but if the approach is to
> provide private keys and certs to each project it might be wise for
> them to also be unique for each project.
They won't be signed. Authentcode key signing is structured
one-per-org.
> That way if a cert/key pair is compromised in one project it doesn't
> impact other projects.
Couldn't agree more, a moronic design if you asked me.
The Symantec code signing service, however, ties a distinct key
to each signed object in an auditable method.
As Rob is fond of pointing out, there are literally hundreds of
moving parts in their release (and similarly in the httpd release
as well - each loadable module must be signed). I've asked and
been assured that the Symantec service would have a batch/group
automation-friendly submission process that could make this
relatively painless.
When I scoped the first ASF-hosted service, I envisioned then
editing each .rc resource entity in the binaries to associate
them to the pgp key which had submitted them for signing, before
then authenticode-signing the objects. But this still suffers
from exactly the threat you identified above.
RE: Official code signing certificate
Posted by "Dennis E. Hamilton" <de...@acm.org>.
Uh oh, Dave triggered something I should have remembered ...
As far as I can tell, two forced builds with no change to the sources will produce artifacts whose digital signatures will be different if Microsoft compilers and tools are used. It's because of time stamps that are embedded in the artifacts.
That might not be true in building an installer, but it applies to the bits that are to be signed, such as DLLs, EXEs and other components that go into the installer. It may have to be that those portions should not have embedded signatures for the release candidate, and should be externally signed in the usual way as part of locking down the RC. The final authenticated release build can be limited to embedded signing of the those signable components that go into the installer package and building a then-signed installer (MSI or EXE).
- Dennis
PS: Unsigned artifacts are prepared with a zero-filled "hole" of zero bytes that are also included in the signature. The signature details are embedded by insertion into the pre-arranged hole. When the signature is verified, that portion is treated as being the zeroed bytes that it was when the signature-verifying hash was derived. This works great when the artifact is not otherwise altered. But in signing (or not signing) components that are gathered into an installer file, the signature of the installer file itself will be different.
PPS: If there is no requirement to preserve strong identity between RC artifacts and release artifacts, this is not so hard. It will probably be cleaner either way if all of the parts that involve derivation and insertion of signatures are at a repeatable end stage of the full clean-build process.
-----Original Message-----
From: Dave Fisher [mailto:dave2wave@comcast.net]
Sent: Saturday, March 30, 2013 12:15
To: infrastructure-dev@apache.org
Subject: Re: Official code signing certificate
[ ... ]
(2) CI build process. This means that we concentrate on creating reproducible builds with this style of certificate. Does this approach work on the Mac in an analogous way?
[ ... ]
Let's outline the proper process from a high level:
- PMC starts an RC process.
- In the secure environment the Release Manager builds release artifacts signed using the QA signing process used in CI builds.
- The state of the secure environment is preserved.
- The community tests and votes on the QA signed artifacts.
- The release vote passes.
- The state of the secure environment is restored.
- In the secure environment the Release Manager builds release artifacts signed using the officially signed code signing certificate.
- The officially signed artifacts are released.
Some questions about the secure environment.
Must it be a physical environment?
What sign and build steps in the secure environments must be performed by a "Security Officer"?
Regards,
Dave
[ ... ]
Re: Official code signing certificate
Posted by Dave Fisher <da...@comcast.net>.
Hi,
It looks like there needs to be two processes that are identical except for the conditions in which they occur.
On Mar 27, 2013, at 4:19 AM, Sander Temme wrote:
> All,
>
> I have not read this entire thread and will have no time to do so. But I did want to add some comments to this discussion
>
> On Mar 25, 2013, at 11:48 PM, Clint Modien <cm...@gmail.com> wrote:
>
>> Should the key/cert ever be _suspected_ of being compromised and the key/cert needs to be changed… it will invalidate the currently signed code running on users systems.
>
> This is not the case if the binary is time-stamped as well as signed: the Windows OS will trust the signature on a signed, time-stamped binary if the signature was made during the validity period, and before any revocation, of the certificate. See:
>
> http://msdn.microsoft.com/en-gb/library/windows/hardware/gg487309.aspx
>
> for more information. Various components of Windows itself are signed and time-stamped this way to ensure that your operating system does not break as the certificate for the key that signed the binaries expires.
From my experience with codesigning of Assemblies I know you are correct.
>
>> And infra could then provide a strongly worded wiki page about the protection of the certs and keys and the consequences associated with compromised keys/certs.
>
> Unfortunately, it's not that easy. Code signing keys are a weapon, with far-reaching implications in spite of the best intentions. The code signing certificate issued for your key is trusted by millions of PCs, and of great value to malicious actors for that reason alone. There have been multiple cases of malware signed with official keys/certificates, sometimes subverting build servers deep inside vendors' infrastructure. Signed malware is blindly trusted by the operating system that is asked to load it: the capability to get a signature is of more value to said malicious actors than anything else in our infrastructure. In our case, the signing server would be directly on the public Internet, or at best one hop away. Please don't subject our Infrastructure team to the burden of defending this high profile target.
>
> Code signing keys, especially ones that have a real, trusted code signing certificate, should only be used in specialized cryptographic hardware, under physical control of one, preferably multiple authorized persons. This means signing should be done offline, in a signing ceremony during which said authorized persons can verify the integrity of the release before issuing the signature. This process is not unlike what Clint sketches below, except I would not consider a USB stick to be sufficiently secure storage for a code signing key.
(1) Releases signed with the real trusted code signing certificate must be built in a secure environment.
Is it possible to define the requirements for the ultra secure environment?
>
> For Continuous Integration builds, you can create certificates outside the official Windows trust store. This doesn't have to be your own infrastructure: you can have this hosted by Symantec et. al. (for a price no doubt) or perhaps ask someone like CACert.org who already have infrastructure and processes set up. The benefit of this is that anyone can install, run and test signed software by dropping the root certificate into their trust store, but CI builds are not trusted by the PCs used by the public at large. The doc linked above discusses this approach to signing software for QA purposes.
(2) CI build process. This means that we concentrate on creating reproducible builds with this style of certificate. Does this approach work on the Mac in an analogous way?
>
> I'm not saying that you shouldn't sign software, or should't get an officially signed code signing certificate. But be sure to surround the signing keys with the proper process and equipment.
Let's outline the proper process from a high level:
- PMC starts an RC process.
- In the secure environment the Release Manager builds release artifacts signed using the QA signing process used in CI builds.
- The state of the secure environment is preserved.
- The community tests and votes on the QA signed artifacts.
- The release vote passes.
- The state of the secure environment is restored.
- In the secure environment the Release Manager builds release artifacts signed using the officially signed code signing certificate.
- The officially signed artifacts are released.
Some questions about the secure environment.
Must it be a physical environment?
What sign and build steps in the secure environments must be performed by a "Security Officer"?
Regards,
Dave
>
> S.
>
>
>> On Mar 25, 2013, at 10:27 AM, Clint Modien <cm...@gmail.com> wrote:
>>
>>> When I worked on a project for Amazon the binaries were submitted via ssh to the security department along with an md5 file for each binary.
>>>
>>> Before the project started I was required to produce a step by step document for signing the code. (tools, downloads, setup)
>>>
>>> After the binaries were checked against their associated md5 hashes, security then simply signed the binaries according to the process outlined in the document.
>>>
>>> I was told that the cert and private key were kept on a usb stick in a safe and the protocols surrounding the handling of the usb stick were as strict as those used for nuclear launch codes.
>>>
>>> I feel like the process to sign most code nowadays does not require the cert+key be available during compilation… but I could be wrong.
>>>
>>> On Mar 25, 2013, at 9:06 AM, Rob Weir <ro...@apache.org> wrote:
>>>>
>>>> I like the idea of having multiple PMC members attest to the RC, by
>>>> signing or whatever. But we still would need to tie that back to a
>>>> SVN revision number somehow. In other words, how we do prove the
>>>> revision number that was used to build the RC?
>>>>
>>>> Perhaps the flow is like this:
>>>>
>>>> 1) RC built by buildbot and that records the SVN revision.
>>>>
>>>> 2) Three PMC members sign the RC
>>>>
>>>> 3) Comparison of the MD5 hashes for the signed RC and the buildbot
>>>> output confirms the revision that was used.
>>>>
>>>> 4) Infra then releases the signing cert for use by buildbot automation
>>>> to rebuild the same revision
>>>>
>>>
>>
>
>
> --
> sander@temme.net http://www.temme.net/sander/
> PGP FP: FC5A 6FC6 2E25 2DFD 8007 EE23 9BB8 63B0 F51B B88A
>
>
>
Re: Official code signing certificate
Posted by Sander Temme <sa...@temme.net>.
All,
I have not read this entire thread and will have no time to do so. But I did want to add some comments to this discussion
On Mar 25, 2013, at 11:48 PM, Clint Modien <cm...@gmail.com> wrote:
> Should the key/cert ever be _suspected_ of being compromised and the key/cert needs to be changed… it will invalidate the currently signed code running on users systems.
This is not the case if the binary is time-stamped as well as signed: the Windows OS will trust the signature on a signed, time-stamped binary if the signature was made during the validity period, and before any revocation, of the certificate. See:
http://msdn.microsoft.com/en-gb/library/windows/hardware/gg487309.aspx
for more information. Various components of Windows itself are signed and time-stamped this way to ensure that your operating system does not break as the certificate for the key that signed the binaries expires.
> And infra could then provide a strongly worded wiki page about the protection of the certs and keys and the consequences associated with compromised keys/certs.
Unfortunately, it's not that easy. Code signing keys are a weapon, with far-reaching implications in spite of the best intentions. The code signing certificate issued for your key is trusted by millions of PCs, and of great value to malicious actors for that reason alone. There have been multiple cases of malware signed with official keys/certificates, sometimes subverting build servers deep inside vendors' infrastructure. Signed malware is blindly trusted by the operating system that is asked to load it: the capability to get a signature is of more value to said malicious actors than anything else in our infrastructure. In our case, the signing server would be directly on the public Internet, or at best one hop away. Please don't subject our Infrastructure team to the burden of defending this high profile target.
Code signing keys, especially ones that have a real, trusted code signing certificate, should only be used in specialized cryptographic hardware, under physical control of one, preferably multiple authorized persons. This means signing should be done offline, in a signing ceremony during which said authorized persons can verify the integrity of the release before issuing the signature. This process is not unlike what Clint sketches below, except I would not consider a USB stick to be sufficiently secure storage for a code signing key.
For Continuous Integration builds, you can create certificates outside the official Windows trust store. This doesn't have to be your own infrastructure: you can have this hosted by Symantec et. al. (for a price no doubt) or perhaps ask someone like CACert.org who already have infrastructure and processes set up. The benefit of this is that anyone can install, run and test signed software by dropping the root certificate into their trust store, but CI builds are not trusted by the PCs used by the public at large. The doc linked above discusses this approach to signing software for QA purposes.
I'm not saying that you shouldn't sign software, or should't get an officially signed code signing certificate. But be sure to surround the signing keys with the proper process and equipment.
S.
> On Mar 25, 2013, at 10:27 AM, Clint Modien <cm...@gmail.com> wrote:
>
>> When I worked on a project for Amazon the binaries were submitted via ssh to the security department along with an md5 file for each binary.
>>
>> Before the project started I was required to produce a step by step document for signing the code. (tools, downloads, setup)
>>
>> After the binaries were checked against their associated md5 hashes, security then simply signed the binaries according to the process outlined in the document.
>>
>> I was told that the cert and private key were kept on a usb stick in a safe and the protocols surrounding the handling of the usb stick were as strict as those used for nuclear launch codes.
>>
>> I feel like the process to sign most code nowadays does not require the cert+key be available during compilation… but I could be wrong.
>>
>> On Mar 25, 2013, at 9:06 AM, Rob Weir <ro...@apache.org> wrote:
>>>
>>> I like the idea of having multiple PMC members attest to the RC, by
>>> signing or whatever. But we still would need to tie that back to a
>>> SVN revision number somehow. In other words, how we do prove the
>>> revision number that was used to build the RC?
>>>
>>> Perhaps the flow is like this:
>>>
>>> 1) RC built by buildbot and that records the SVN revision.
>>>
>>> 2) Three PMC members sign the RC
>>>
>>> 3) Comparison of the MD5 hashes for the signed RC and the buildbot
>>> output confirms the revision that was used.
>>>
>>> 4) Infra then releases the signing cert for use by buildbot automation
>>> to rebuild the same revision
>>>
>>
>
--
sander@temme.net http://www.temme.net/sander/
PGP FP: FC5A 6FC6 2E25 2DFD 8007 EE23 9BB8 63B0 F51B B88A
Re: Official code signing certificate
Posted by Rob Weir <ro...@apache.org>.
On Mon, Mar 25, 2013 at 7:48 PM, Clint Modien <cm...@gmail.com> wrote:
> Should the key/cert ever be _suspected_ of being compromised and the key/cert needs to be changed… it will invalidate the currently signed code running on users systems.
>
Is this true? I know that the signing is verified at install time,
and that revocations might be checked at that time as well. But I
didn't think that the signing had relevance after installation.
Certainly the outermost signature is no longer relevant, since it is
only used at install time.
> Some apps may not execute at all, some apps may not be able to update properly.
>
> I'm not sure if it's economical or not… but if the approach is to provide private keys and certs to each project it might be wise for them to also be unique for each project.
>
> That way if a cert/key pair is compromised in one project it doesn't impact other projects.
>
Worth considering, IMHO.
-Rob
> Perhaps a protocol for simply requesting intial signing certs and a private key from infra to be protected by a few members of the PMC?
>
> And infra could then provide a strongly worded wiki page about the protection of the certs and keys and the consequences associated with compromised keys/certs.
>
> On Mar 25, 2013, at 10:27 AM, Clint Modien <cm...@gmail.com> wrote:
>
>> When I worked on a project for Amazon the binaries were submitted via ssh to the security department along with an md5 file for each binary.
>>
>> Before the project started I was required to produce a step by step document for signing the code. (tools, downloads, setup)
>>
>> After the binaries were checked against their associated md5 hashes, security then simply signed the binaries according to the process outlined in the document.
>>
>> I was told that the cert and private key were kept on a usb stick in a safe and the protocols surrounding the handling of the usb stick were as strict as those used for nuclear launch codes.
>>
>> I feel like the process to sign most code nowadays does not require the cert+key be available during compilation… but I could be wrong.
>>
>> On Mar 25, 2013, at 9:06 AM, Rob Weir <ro...@apache.org> wrote:
>>>
>>> I like the idea of having multiple PMC members attest to the RC, by
>>> signing or whatever. But we still would need to tie that back to a
>>> SVN revision number somehow. In other words, how we do prove the
>>> revision number that was used to build the RC?
>>>
>>> Perhaps the flow is like this:
>>>
>>> 1) RC built by buildbot and that records the SVN revision.
>>>
>>> 2) Three PMC members sign the RC
>>>
>>> 3) Comparison of the MD5 hashes for the signed RC and the buildbot
>>> output confirms the revision that was used.
>>>
>>> 4) Infra then releases the signing cert for use by buildbot automation
>>> to rebuild the same revision
>>>
>>
>
Re: Official code signing certificate
Posted by Clint Modien <cm...@gmail.com>.
Should the key/cert ever be _suspected_ of being compromised and the key/cert needs to be changed… it will invalidate the currently signed code running on users systems.
Some apps may not execute at all, some apps may not be able to update properly.
I'm not sure if it's economical or not… but if the approach is to provide private keys and certs to each project it might be wise for them to also be unique for each project.
That way if a cert/key pair is compromised in one project it doesn't impact other projects.
Perhaps a protocol for simply requesting intial signing certs and a private key from infra to be protected by a few members of the PMC?
And infra could then provide a strongly worded wiki page about the protection of the certs and keys and the consequences associated with compromised keys/certs.
On Mar 25, 2013, at 10:27 AM, Clint Modien <cm...@gmail.com> wrote:
> When I worked on a project for Amazon the binaries were submitted via ssh to the security department along with an md5 file for each binary.
>
> Before the project started I was required to produce a step by step document for signing the code. (tools, downloads, setup)
>
> After the binaries were checked against their associated md5 hashes, security then simply signed the binaries according to the process outlined in the document.
>
> I was told that the cert and private key were kept on a usb stick in a safe and the protocols surrounding the handling of the usb stick were as strict as those used for nuclear launch codes.
>
> I feel like the process to sign most code nowadays does not require the cert+key be available during compilation… but I could be wrong.
>
> On Mar 25, 2013, at 9:06 AM, Rob Weir <ro...@apache.org> wrote:
>>
>> I like the idea of having multiple PMC members attest to the RC, by
>> signing or whatever. But we still would need to tie that back to a
>> SVN revision number somehow. In other words, how we do prove the
>> revision number that was used to build the RC?
>>
>> Perhaps the flow is like this:
>>
>> 1) RC built by buildbot and that records the SVN revision.
>>
>> 2) Three PMC members sign the RC
>>
>> 3) Comparison of the MD5 hashes for the signed RC and the buildbot
>> output confirms the revision that was used.
>>
>> 4) Infra then releases the signing cert for use by buildbot automation
>> to rebuild the same revision
>>
>
Re: Official code signing certificate
Posted by Clint Modien <cm...@gmail.com>.
When I worked on a project for Amazon the binaries were submitted via ssh to the security department along with an md5 file for each binary.
Before the project started I was required to produce a step by step document for signing the code. (tools, downloads, setup)
After the binaries were checked against their associated md5 hashes, security then simply signed the binaries according to the process outlined in the document.
I was told that the cert and private key were kept on a usb stick in a safe and the protocols surrounding the handling of the usb stick were as strict as those used for nuclear launch codes.
I feel like the process to sign most code nowadays does not require the cert+key be available during compilation… but I could be wrong.
On Mar 25, 2013, at 9:06 AM, Rob Weir <ro...@apache.org> wrote:
>
> I like the idea of having multiple PMC members attest to the RC, by
> signing or whatever. But we still would need to tie that back to a
> SVN revision number somehow. In other words, how we do prove the
> revision number that was used to build the RC?
>
> Perhaps the flow is like this:
>
> 1) RC built by buildbot and that records the SVN revision.
>
> 2) Three PMC members sign the RC
>
> 3) Comparison of the MD5 hashes for the signed RC and the buildbot
> output confirms the revision that was used.
>
> 4) Infra then releases the signing cert for use by buildbot automation
> to rebuild the same revision
>
Re: Official code signing certificate
Posted by Rob Weir <ro...@apache.org>.
On Fri, Mar 22, 2013 at 12:57 PM, Daniel Shahaf <d....@daniel.shahaf.name> wrote:
> Rob Weir wrote on Fri, Mar 22, 2013 at 10:44:45 -0400:
>> On Thu, Mar 21, 2013 at 6:18 PM, Daniel Shahaf <d....@daniel.shahaf.name> wrote:
>> > Rob Weir wrote on Thu, Mar 21, 2013 at 11:35:21 -0400:
>> >> On Thu, Mar 21, 2013 at 9:09 AM, Daniel Shahaf <d....@daniel.shahaf.name> wrote:
>> >> > For example: does releasing software under a certificate Microsoft
>> >> > pre-trusts (or into an app store Apple moderates) subject ASF to an
>> >> > indemnification clause towards that company? Does it grant the company
>> >> > a license to use our trademarks in advertising? Does it compel ASF to
>> >> > offer warranty to end-users?
>> >>
>> >> I believe that we'd be required to make some sort of assertion that
>> >> our code does not contain intentionally malicious software, but I
>> >> don't know the details of that statement.
>> >>
>> >> In any case, if possible, let's focus on the Infra side of this here.
>> >> We should separately review the language of any agreements we need to
>> >> sign with Legal Affairs and/or the Board.
>> >>
>> >
>> > Technically I don't imagine there's much question here. You guys
>> > already have code that builds+signs, the ONLY thing it's missing is a
>> > file containing an X509 signing cert signed by somebody whom Windows
>> > trusts by default, right? Once we obtain such a file, is there any
>> > reason we won't be able to put it on a VM and run your code inside that
>> > VM against that file? I expect not, so I'm moving on to the legal
>> > sides.
>> >
>>
>> The remaining question would be if we need any safeguards against
>> hypothetical compromised committer accounts.
>>
>> I think we want to avoid something like this:
>>
>> 1) Someone acquires login credentials for a committer, e.g., they use
>> the same password at Apache as they use for some other web service
>> that is hacked.
>>
>> 2) They check-in a backdoor into the code
>>
>> 3) Before CTR finds the problem the buildbots have built and signed
>> the executables and the hacker has downloaded them.
>>
>> 4) We have malicious code now distributed signed with the Apache certificate.
>>
>> So from a process view, we might want to have routine builds be signed
>> with a placeholder test certificate (essentially self-signed) and this
>> test certificate is in SVN. The real signing certificate would only
>> be applied on Release Candidates and with additional safeguards.
>> Maybe the request needs to come from the PMC Chair or the Release
>> Manager? Or some time must elapse between the date of the SVN
>> revision and the signing?
>>
>
> How about only signing with the real certificate once three PMC members
> PGP-signed the binaries-built-against-the-self-signed-certificate.
>
I like the idea of having multiple PMC members attest to the RC, by
signing or whatever. But we still would need to tie that back to a
SVN revision number somehow. In other words, how we do prove the
revision number that was used to build the RC?
Perhaps the flow is like this:
1) RC built by buildbot and that records the SVN revision.
2) Three PMC members sign the RC
3) Comparison of the MD5 hashes for the signed RC and the buildbot
output confirms the revision that was used.
4) Infra then releases the signing cert for use by buildbot automation
to rebuild the same revision
> I follow the rest of your logic, makes sense.
>
>> You might think that we'd vote on the RC and only sign it after that.
>> But that doesn't work because the signature is applied at multiple
>> levels of the packaging. So the individual EXE and DLL's are signed,
>> as well as the installer and the outermost archive packaging.
>>
>> One option would be to vote to approve the RC and then rebuild the
>> exact same revision that was approved, with no other changes than
>> replacing the test cert with the real signing cert.
>>
>> > And yes, I do need to at least think of the legal side before I start:
>> > if, say, Company X's terms include a use-in-advertising license and VP
>> > Brand vetoes that, then there's no point in burning Infra cycles on
>> > thinking of how to make it work with Company X.
>> >
>>
>> Dennis gave a link to the Symantec agreement. I don't see any
>> trademark or advertising related clause. But we obviously need to
>
> Oh, thanks. I missed that in his email.
>
>> make a thorough review. There are other CA's as well who might offer
>> different terms.
>>
>> Regards,
>>
>> -Rob
>>
>> >> Regards,
>> >>
>> >> -Rob
Re: Official code signing certificate
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Rob Weir wrote on Fri, Mar 22, 2013 at 10:44:45 -0400:
> On Thu, Mar 21, 2013 at 6:18 PM, Daniel Shahaf <d....@daniel.shahaf.name> wrote:
> > Rob Weir wrote on Thu, Mar 21, 2013 at 11:35:21 -0400:
> >> On Thu, Mar 21, 2013 at 9:09 AM, Daniel Shahaf <d....@daniel.shahaf.name> wrote:
> >> > For example: does releasing software under a certificate Microsoft
> >> > pre-trusts (or into an app store Apple moderates) subject ASF to an
> >> > indemnification clause towards that company? Does it grant the company
> >> > a license to use our trademarks in advertising? Does it compel ASF to
> >> > offer warranty to end-users?
> >>
> >> I believe that we'd be required to make some sort of assertion that
> >> our code does not contain intentionally malicious software, but I
> >> don't know the details of that statement.
> >>
> >> In any case, if possible, let's focus on the Infra side of this here.
> >> We should separately review the language of any agreements we need to
> >> sign with Legal Affairs and/or the Board.
> >>
> >
> > Technically I don't imagine there's much question here. You guys
> > already have code that builds+signs, the ONLY thing it's missing is a
> > file containing an X509 signing cert signed by somebody whom Windows
> > trusts by default, right? Once we obtain such a file, is there any
> > reason we won't be able to put it on a VM and run your code inside that
> > VM against that file? I expect not, so I'm moving on to the legal
> > sides.
> >
>
> The remaining question would be if we need any safeguards against
> hypothetical compromised committer accounts.
>
> I think we want to avoid something like this:
>
> 1) Someone acquires login credentials for a committer, e.g., they use
> the same password at Apache as they use for some other web service
> that is hacked.
>
> 2) They check-in a backdoor into the code
>
> 3) Before CTR finds the problem the buildbots have built and signed
> the executables and the hacker has downloaded them.
>
> 4) We have malicious code now distributed signed with the Apache certificate.
>
> So from a process view, we might want to have routine builds be signed
> with a placeholder test certificate (essentially self-signed) and this
> test certificate is in SVN. The real signing certificate would only
> be applied on Release Candidates and with additional safeguards.
> Maybe the request needs to come from the PMC Chair or the Release
> Manager? Or some time must elapse between the date of the SVN
> revision and the signing?
>
How about only signing with the real certificate once three PMC members
PGP-signed the binaries-built-against-the-self-signed-certificate.
I follow the rest of your logic, makes sense.
> You might think that we'd vote on the RC and only sign it after that.
> But that doesn't work because the signature is applied at multiple
> levels of the packaging. So the individual EXE and DLL's are signed,
> as well as the installer and the outermost archive packaging.
>
> One option would be to vote to approve the RC and then rebuild the
> exact same revision that was approved, with no other changes than
> replacing the test cert with the real signing cert.
>
> > And yes, I do need to at least think of the legal side before I start:
> > if, say, Company X's terms include a use-in-advertising license and VP
> > Brand vetoes that, then there's no point in burning Infra cycles on
> > thinking of how to make it work with Company X.
> >
>
> Dennis gave a link to the Symantec agreement. I don't see any
> trademark or advertising related clause. But we obviously need to
Oh, thanks. I missed that in his email.
> make a thorough review. There are other CA's as well who might offer
> different terms.
>
> Regards,
>
> -Rob
>
> >> Regards,
> >>
> >> -Rob
Re: Official code signing certificate
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On Fri, 22 Mar 2013 10:44:45 -0400
Rob Weir <ro...@apache.org> wrote:
> The remaining question would be if we need any safeguards against
> hypothetical compromised committer accounts.
>
> I think we want to avoid something like this:
>
> 1) Someone acquires login credentials for a committer, e.g., they use
> the same password at Apache as they use for some other web service
> that is hacked.
>
> 2) They check-in a backdoor into the code
>
> 3) Before CTR finds the problem the buildbots have built and signed
> the executables and the hacker has downloaded them.
>
> 4) We have malicious code now distributed signed with the Apache
> certificate.
The solution is for this is to only allow the code signing service
to sign gpg-crypted artifacts. The providence of the code, which
committer submitted it for signing, is recorded.
> You might think that we'd vote on the RC and only sign it after that.
> But that doesn't work because the signature is applied at multiple
> levels of the packaging. So the individual EXE and DLL's are signed,
> as well as the installer and the outermost archive packaging.
It is reasonably straightforward (using Windows, specifically) to;
1. unpack the .msi
2. unpack the embedded diamond-compressed .cab (or .zip/war's)
3. sign .dll and .exe artifacts
4. recompress the .cab (or .zip/war's)
5. repack the .msi with the replacement .cab
That's what I had envisioned several years ago that such a service
would do on the ASF side. Check in a package to the signing service's
svn inbox, the signing service checks in signed packages in return.
Everything is tracked by ASF creds and gpg creds (2 factor).
Symantec also created such a service and later offered it to the ASF
for free. The primary delta between an ASF-created service and the
Symantec code signing service, is that Symantec creates per-package
(or per-binary) certs which *are* individually revocable without ever
needing to revoke the ASF-wide key. The service is commercially some
$20k/yr. It was offered to the ASF for free over a year ago.
The third competing design suggests a way for committers, without
audit, to sign packages themselves using a single-factor auth scheme,
using the ASF-wide cert. This seems really unwise to me.
Again summarizing the archives for your benefit.
Re: Official code signing certificate
Posted by Rob Weir <ro...@apache.org>.
On Thu, Mar 21, 2013 at 6:18 PM, Daniel Shahaf <d....@daniel.shahaf.name> wrote:
> Rob Weir wrote on Thu, Mar 21, 2013 at 11:35:21 -0400:
>> On Thu, Mar 21, 2013 at 9:09 AM, Daniel Shahaf <d....@daniel.shahaf.name> wrote:
>> > For example: does releasing software under a certificate Microsoft
>> > pre-trusts (or into an app store Apple moderates) subject ASF to an
>> > indemnification clause towards that company? Does it grant the company
>> > a license to use our trademarks in advertising? Does it compel ASF to
>> > offer warranty to end-users?
>>
>> I believe that we'd be required to make some sort of assertion that
>> our code does not contain intentionally malicious software, but I
>> don't know the details of that statement.
>>
>> In any case, if possible, let's focus on the Infra side of this here.
>> We should separately review the language of any agreements we need to
>> sign with Legal Affairs and/or the Board.
>>
>
> Technically I don't imagine there's much question here. You guys
> already have code that builds+signs, the ONLY thing it's missing is a
> file containing an X509 signing cert signed by somebody whom Windows
> trusts by default, right? Once we obtain such a file, is there any
> reason we won't be able to put it on a VM and run your code inside that
> VM against that file? I expect not, so I'm moving on to the legal
> sides.
>
The remaining question would be if we need any safeguards against
hypothetical compromised committer accounts.
I think we want to avoid something like this:
1) Someone acquires login credentials for a committer, e.g., they use
the same password at Apache as they use for some other web service
that is hacked.
2) They check-in a backdoor into the code
3) Before CTR finds the problem the buildbots have built and signed
the executables and the hacker has downloaded them.
4) We have malicious code now distributed signed with the Apache certificate.
So from a process view, we might want to have routine builds be signed
with a placeholder test certificate (essentially self-signed) and this
test certificate is in SVN. The real signing certificate would only
be applied on Release Candidates and with additional safeguards.
Maybe the request needs to come from the PMC Chair or the Release
Manager? Or some time must elapse between the date of the SVN
revision and the signing?
You might think that we'd vote on the RC and only sign it after that.
But that doesn't work because the signature is applied at multiple
levels of the packaging. So the individual EXE and DLL's are signed,
as well as the installer and the outermost archive packaging.
One option would be to vote to approve the RC and then rebuild the
exact same revision that was approved, with no other changes than
replacing the test cert with the real signing cert.
> And yes, I do need to at least think of the legal side before I start:
> if, say, Company X's terms include a use-in-advertising license and VP
> Brand vetoes that, then there's no point in burning Infra cycles on
> thinking of how to make it work with Company X.
>
Dennis gave a link to the Symantec agreement. I don't see any
trademark or advertising related clause. But we obviously need to
make a thorough review. There are other CA's as well who might offer
different terms.
Regards,
-Rob
>> Regards,
>>
>> -Rob
Re: Official code signing certificate
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Rob Weir wrote on Thu, Mar 21, 2013 at 11:35:21 -0400:
> On Thu, Mar 21, 2013 at 9:09 AM, Daniel Shahaf <d....@daniel.shahaf.name> wrote:
> > For example: does releasing software under a certificate Microsoft
> > pre-trusts (or into an app store Apple moderates) subject ASF to an
> > indemnification clause towards that company? Does it grant the company
> > a license to use our trademarks in advertising? Does it compel ASF to
> > offer warranty to end-users?
>
> I believe that we'd be required to make some sort of assertion that
> our code does not contain intentionally malicious software, but I
> don't know the details of that statement.
>
> In any case, if possible, let's focus on the Infra side of this here.
> We should separately review the language of any agreements we need to
> sign with Legal Affairs and/or the Board.
>
Technically I don't imagine there's much question here. You guys
already have code that builds+signs, the ONLY thing it's missing is a
file containing an X509 signing cert signed by somebody whom Windows
trusts by default, right? Once we obtain such a file, is there any
reason we won't be able to put it on a VM and run your code inside that
VM against that file? I expect not, so I'm moving on to the legal
sides.
And yes, I do need to at least think of the legal side before I start:
if, say, Company X's terms include a use-in-advertising license and VP
Brand vetoes that, then there's no point in burning Infra cycles on
thinking of how to make it work with Company X.
> Regards,
>
> -Rob
Re: Official code signing certificate
Posted by Rob Weir <ro...@apache.org>.
On Thu, Mar 21, 2013 at 9:09 AM, Daniel Shahaf <d....@daniel.shahaf.name> wrote:
> Jürgen Schmidt wrote on Thu, Mar 21, 2013 at 13:32:40 +0100:
>> On 3/21/13 1:09 PM, Daniel Shahaf wrote:
>> > Jürgen Schmidt wrote on Thu, Mar 21, 2013 at 08:53:29 +0100:
>> >> On 3/20/13 9:37 PM, Daniel Shahaf wrote:
>> >>> So... what kind of certificate is that? How much does it cost, what
>> >>> kind of year to year maintenance it requires, etc.
>> >>
>> >> for windows it is a
>> >> "Code Signing Certificates for Microsoft Authenticode
>> >> Digitally sign 32-bit or 64-bit user-mode (.exe, .cab, .dll, .ocx, .msi,
>> >> .xpi, and .xap files) and kernel-mode software. Provider for Microsoft
>> >> Windows Logo programs."
>> >>
>> >> see [1] and [2]
>> >>
>> >> [1] http://www.symantec.com/verisign/code-signing/microsoft-authenticode
>> >> [2] overview http://www.symantec.com/code-signing
>> >>
>> >> I found a price by Symantec of 499$/year (reduced prices for 2 or 3
>> >> years) but there was already an opportunity that we can find a sponsor,
>> >> potentially a provider of such certificates.
>> >>
>> >
>> > Can you summarise it for me with the marketing stuff stripped please.
>> > Is it "Any company can pay $500 a year to get a signing certificate
>> > which is trusted-by-default (via trusting Symantec) by all Windows
>> > installations"?
>>
>> well money sells and everybody can buy a certificate for whatever
>> reason. I think it is comparable to any other certificates like for
>> domains etc. I don't know but I think the provider of such certificates
>> do some verification before you get or are allowed to buy a certificate.
>> But I don't know for sure.
>>
>
> In SSL certificates the issuer checks your identity (much like most
> people would ask to see your passport before signing your PGP key).
>
>> Important is that today systems like Windows 8 or Apple with their app
>> store require signed applications that can be verified in some automated
>> way to check at least the certificate chain until the root certificate
>> etc. If it can't verified the user get informed with some dialogs to
>> request further approval or acceptance to continue.
>>
>
> You're simply describing how certificates work (basically, we generate
> a secret and then Symantec signs f(secret) and we provide that signature
> to end-users --- who trust Symantec's signing key).
>
>> >
>> > Are there any strings attached here? Would using such a cert grant
>> > any rights to Symantec/Microsoft/Endusers that ASF doesn't currently
>> > grant?
>>
>> I don't understand. If Symantec for example would decide to sponsor such
>> a certificate the ASF would get a certificate with all the related data
>> to ASF. Means as publisher the user would see the ASF somewhere in the
>> verification process if necessary.
>>
>
> What are the differences between your proposal and just
> using PGP detached signatures, other than the latter being a different
> technology and lacking the advantage of a pre-trusted key (Symantec's)
> and of integrated-in-the-OS (or required-by-the-app-store) verification.
>
PGP detached signatures are typically verified by human admins. Code
sigining is typically verified by integrated signature-verification
code in end-user facing tools like browsers, anti-virus software and
operating system shells.
So the technology is different, though there is not really an
interesting cryptographic difference. The important practical
difference is that the tool chain of the people consuming the
OpenOffice binaries expects a particular form of code signing. That
is the recent trend. Most recent versions of Windows and MacOS both
reject, by default, execution of binaries that are not signed.
Reputation-based heuristics in anti-virus also look at code signing as
a hint for trust. None of these technologies look at detached
signatures.
> For example: does releasing software under a certificate Microsoft
> pre-trusts (or into an app store Apple moderates) subject ASF to an
> indemnification clause towards that company? Does it grant the company
> a license to use our trademarks in advertising? Does it compel ASF to
> offer warranty to end-users?
We're not signing any agreement with Microsoft or Apple. We're just
talking about a signing certificate that would be issued by, say,
Symantec, where their root certificate is pre-installed on Windows,
for example. So instead of a "web of trust" like detached signatures,
we're dealing with a hierarchical chain of trust.
I believe that we'd be required to make some sort of assertion that
our code does not contain intentionally malicious software, but I
don't know the details of that statement.
In any case, if possible, let's focus on the Infra side of this here.
We should separately review the language of any agreements we need to
sign with Legal Affairs and/or the Board.
Regards,
-Rob
Re: Official code signing certificate
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
Wasting more breath on archived details...
On Thu, 21 Mar 2013 15:09:24 +0200
Daniel Shahaf <d....@daniel.shahaf.name> wrote:
> In SSL certificates the issuer checks your identity (much like most
> people would ask to see your passport before signing your PGP key).
In code signing SSL certificates, these are granted only to top level
orgs. That means that the ASF will have to prove it is the ASF and
there will be one and only one current cert. Revoking it would mean
every project's release would be on a revoked cert. No small hassle.
> Jürgen Schmidt wrote on Thu, Mar 21, 2013 at 13:32:40 +0100:
>
> > Important is that today systems like Windows 8 or Apple with their
> > app store require signed applications that can be verified in some
> > automated way to check at least the certificate chain until the
> > root certificate etc. If it can't verified the user get informed
> > with some dialogs to request further approval or acceptance to
> > continue.
Very true. This is a system-enforced restriction.
Note that a system service, e.g. httpd, may not be able to walk
a chain of trust during boot-load time, so it relies on the
cert signed by a chain recognizable to the local key store.
> What are the differences between your proposal and just
> using PGP detached signatures, other than the latter being a different
> technology and lacking the advantage of a pre-trusted key (Symantec's)
> and of integrated-in-the-OS (or required-by-the-app-store)
> verification.
The OS doesn't speak PGP. Only code signed with a signed
MS Authenticode cert or Java/JavaScript trusted cert is going
to be recognized by MS Windows/Java/Scripting host.
I am not aware of a ld.so-aware PGP key validation even on linux,
is anyone familiar with the momentum/proposals of signed binaries
under linux?
> For example: does releasing software under a certificate Microsoft
> pre-trusts (or into an app store Apple moderates) subject ASF to an
> indemnification clause towards that company? Does it grant the
> company a license to use our trademarks in advertising? Does it
> compel ASF to offer warranty to end-users?
In the case of a code signing cert for MS/Java/Javascript, not so
far as I'm aware. All of the 'store' policies are more draconian,
of course.
Again, it's all in the archives.
Re: Official code signing certificate
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Jürgen Schmidt wrote on Thu, Mar 21, 2013 at 13:32:40 +0100:
> On 3/21/13 1:09 PM, Daniel Shahaf wrote:
> > Jürgen Schmidt wrote on Thu, Mar 21, 2013 at 08:53:29 +0100:
> >> On 3/20/13 9:37 PM, Daniel Shahaf wrote:
> >>> So... what kind of certificate is that? How much does it cost, what
> >>> kind of year to year maintenance it requires, etc.
> >>
> >> for windows it is a
> >> "Code Signing Certificates for Microsoft Authenticode
> >> Digitally sign 32-bit or 64-bit user-mode (.exe, .cab, .dll, .ocx, .msi,
> >> .xpi, and .xap files) and kernel-mode software. Provider for Microsoft
> >> Windows Logo programs."
> >>
> >> see [1] and [2]
> >>
> >> [1] http://www.symantec.com/verisign/code-signing/microsoft-authenticode
> >> [2] overview http://www.symantec.com/code-signing
> >>
> >> I found a price by Symantec of 499$/year (reduced prices for 2 or 3
> >> years) but there was already an opportunity that we can find a sponsor,
> >> potentially a provider of such certificates.
> >>
> >
> > Can you summarise it for me with the marketing stuff stripped please.
> > Is it "Any company can pay $500 a year to get a signing certificate
> > which is trusted-by-default (via trusting Symantec) by all Windows
> > installations"?
>
> well money sells and everybody can buy a certificate for whatever
> reason. I think it is comparable to any other certificates like for
> domains etc. I don't know but I think the provider of such certificates
> do some verification before you get or are allowed to buy a certificate.
> But I don't know for sure.
>
In SSL certificates the issuer checks your identity (much like most
people would ask to see your passport before signing your PGP key).
> Important is that today systems like Windows 8 or Apple with their app
> store require signed applications that can be verified in some automated
> way to check at least the certificate chain until the root certificate
> etc. If it can't verified the user get informed with some dialogs to
> request further approval or acceptance to continue.
>
You're simply describing how certificates work (basically, we generate
a secret and then Symantec signs f(secret) and we provide that signature
to end-users --- who trust Symantec's signing key).
> >
> > Are there any strings attached here? Would using such a cert grant
> > any rights to Symantec/Microsoft/Endusers that ASF doesn't currently
> > grant?
>
> I don't understand. If Symantec for example would decide to sponsor such
> a certificate the ASF would get a certificate with all the related data
> to ASF. Means as publisher the user would see the ASF somewhere in the
> verification process if necessary.
>
What are the differences between your proposal and just
using PGP detached signatures, other than the latter being a different
technology and lacking the advantage of a pre-trusted key (Symantec's)
and of integrated-in-the-OS (or required-by-the-app-store) verification.
For example: does releasing software under a certificate Microsoft
pre-trusts (or into an app store Apple moderates) subject ASF to an
indemnification clause towards that company? Does it grant the company
a license to use our trademarks in advertising? Does it compel ASF to
offer warranty to end-users?
Re: Official code signing certificate
Posted by Jürgen Schmidt <jo...@gmail.com>.
On 3/21/13 1:09 PM, Daniel Shahaf wrote:
> Jürgen Schmidt wrote on Thu, Mar 21, 2013 at 08:53:29 +0100:
>> On 3/20/13 9:37 PM, Daniel Shahaf wrote:
>>> So... what kind of certificate is that? How much does it cost, what
>>> kind of year to year maintenance it requires, etc.
>>
>> for windows it is a
>> "Code Signing Certificates for Microsoft Authenticode
>> Digitally sign 32-bit or 64-bit user-mode (.exe, .cab, .dll, .ocx, .msi,
>> .xpi, and .xap files) and kernel-mode software. Provider for Microsoft
>> Windows Logo programs."
>>
>> see [1] and [2]
>>
>> [1] http://www.symantec.com/verisign/code-signing/microsoft-authenticode
>> [2] overview http://www.symantec.com/code-signing
>>
>> I found a price by Symantec of 499$/year (reduced prices for 2 or 3
>> years) but there was already an opportunity that we can find a sponsor,
>> potentially a provider of such certificates.
>>
>
> Can you summarise it for me with the marketing stuff stripped please.
> Is it "Any company can pay $500 a year to get a signing certificate
> which is trusted-by-default (via trusting Symantec) by all Windows
> installations"?
well money sells and everybody can buy a certificate for whatever
reason. I think it is comparable to any other certificates like for
domains etc. I don't know but I think the provider of such certificates
do some verification before you get or are allowed to buy a certificate.
But I don't know for sure.
Important is that today systems like Windows 8 or Apple with their app
store require signed applications that can be verified in some automated
way to check at least the certificate chain until the root certificate
etc. If it can't verified the user get informed with some dialogs to
request further approval or acceptance to continue.
>
> Are there any strings attached here? Would using such a cert grant
> any rights to Symantec/Microsoft/Endusers that ASF doesn't currently
> grant?
I don't understand. If Symantec for example would decide to sponsor such
a certificate the ASF would get a certificate with all the related data
to ASF. Means as publisher the user would see the ASF somewhere in the
verification process if necessary.
Juergen
>
>> Juergen
>>
>>>
>>> Jürgen Schmidt wrote on Wed, Mar 20, 2013 at 10:28:23 +0100:
>>>> Hi,
>>>>
>>>> I reused this existing thread to restart the discussion about official
>>>> code signing. In case of AOO we are moving towards our next major
>>>> release AOO 4.0 which is planned for end if June. With over 40 million
>>>> downloads in less than 1 year and most of them for Windows this topic is
>>>> still very important for the project to provide the best user experience
>>>> and the necessary trust in the product on modern Windows Systems like
>>>> Windows 8.
>>>>
>>>> On http://wiki.apache.org/general/ASFCodeSigning#preview I started to
>>>> collect requirements and describe also the existing solution in AOO
>>>> today and how it can be used in a more general approach.
>>>>
>>>> The proposal is only one example but I think a practical one when I take
>>>> all the security concerns into account. But of course it probably
>>>> requires interaction with the trusted paid staff members.
>>>>
>>>> I hope we can move this important topic forward and can find a
>>>> satisfying solution for all ASF projects who need code signing.
>>>>
>>>> Juergen
>>>>
>>>>
>>>>
>>>>
>>
Re: Official code signing certificate
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Jürgen Schmidt wrote on Thu, Mar 21, 2013 at 08:53:29 +0100:
> On 3/20/13 9:37 PM, Daniel Shahaf wrote:
> > So... what kind of certificate is that? How much does it cost, what
> > kind of year to year maintenance it requires, etc.
>
> for windows it is a
> "Code Signing Certificates for Microsoft Authenticode
> Digitally sign 32-bit or 64-bit user-mode (.exe, .cab, .dll, .ocx, .msi,
> .xpi, and .xap files) and kernel-mode software. Provider for Microsoft
> Windows Logo programs."
>
> see [1] and [2]
>
> [1] http://www.symantec.com/verisign/code-signing/microsoft-authenticode
> [2] overview http://www.symantec.com/code-signing
>
> I found a price by Symantec of 499$/year (reduced prices for 2 or 3
> years) but there was already an opportunity that we can find a sponsor,
> potentially a provider of such certificates.
>
Can you summarise it for me with the marketing stuff stripped please.
Is it "Any company can pay $500 a year to get a signing certificate
which is trusted-by-default (via trusting Symantec) by all Windows
installations"?
Are there any strings attached here? Would using such a cert grant
any rights to Symantec/Microsoft/Endusers that ASF doesn't currently
grant?
> Juergen
>
> >
> > Jürgen Schmidt wrote on Wed, Mar 20, 2013 at 10:28:23 +0100:
> >> Hi,
> >>
> >> I reused this existing thread to restart the discussion about official
> >> code signing. In case of AOO we are moving towards our next major
> >> release AOO 4.0 which is planned for end if June. With over 40 million
> >> downloads in less than 1 year and most of them for Windows this topic is
> >> still very important for the project to provide the best user experience
> >> and the necessary trust in the product on modern Windows Systems like
> >> Windows 8.
> >>
> >> On http://wiki.apache.org/general/ASFCodeSigning#preview I started to
> >> collect requirements and describe also the existing solution in AOO
> >> today and how it can be used in a more general approach.
> >>
> >> The proposal is only one example but I think a practical one when I take
> >> all the security concerns into account. But of course it probably
> >> requires interaction with the trusted paid staff members.
> >>
> >> I hope we can move this important topic forward and can find a
> >> satisfying solution for all ASF projects who need code signing.
> >>
> >> Juergen
> >>
> >>
> >>
> >>
>
Re: Official code signing certificate
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On Thu, 21 Mar 2013 08:53:29 +0100
Jürgen Schmidt <jo...@gmail.com> wrote:
> On 3/20/13 9:37 PM, Daniel Shahaf wrote:
> >
> > - the script uses as input a certificate that only root@ has access
> > to
> >
> > - root@ runs the script (against a specific tag and revision in
> > svn) and publishes the results
>
> that is one way to handle it and from a security perspective the most
> secure one. But I would root describe to only a very small group of
> people with root access on the dedicated machine. This really depends
> on what infra prefers and other options can be also possible.
If this were a project cert or whatever, your 'small group' solution
might be feasible. The cert *IS* ASF-wide, that is at least 10+
projects with 10+ individuals. Root/Admin-only script is the only
feasible solution. That is unless you want specific objects to be
signed by their own key, a solution offered to us, for free, by
Symantec's code signing service that we've chosen to ignore.
What is built, then? A release tarball? An svn tag? Can it be
patched or modified? How is it tracked which package is signed
by which RM?
As an ASF-wide credential, having the core infra team as the sole
possessors of that key seems prudent.
> > So... what kind of certificate is that? How much does it cost, what
> > kind of year to year maintenance it requires, etc.
>
> for windows it is a
> "Code Signing Certificates for Microsoft Authenticode
> Digitally sign 32-bit or 64-bit user-mode
> (.exe, .cab, .dll, .ocx, .msi, .xpi, and .xap files) and kernel-mode
> software. Provider for Microsoft Windows Logo programs."
>
> see [1] and [2]
>
> [1]
> http://www.symantec.com/verisign/code-signing/microsoft-authenticode
> [2] overview http://www.symantec.com/code-signing
>
> I found a price by Symantec of 499$/year (reduced prices for 2 or 3
> years) but there was already an opportunity that we can find a
> sponsor, potentially a provider of such certificates.
Sigh <wasting even more breath>... it's free. See the archives.
Re: Official code signing certificate
Posted by Jürgen Schmidt <jo...@gmail.com>.
On 3/20/13 9:37 PM, Daniel Shahaf wrote:
> So, basically:
>
> - project maintains a build script
> (does checkout, build, and prepares end-user-facing package; doesn't
> run unit/regression tests)
running unit/regression tests is not directly related to this. But it's
definitely a goal for AOO to run the automated tests with any build in
the future.
>
> - the script uses as input a certificate that only root@ has access to
>
> - root@ runs the script (against a specific tag and revision in svn) and
> publishes the results
that is one way to handle it and from a security perspective the most
secure one. But I would root describe to only a very small group of
people with root access on the dedicated machine. This really depends on
what infra prefers and other options can be also possible.
>
> So... what kind of certificate is that? How much does it cost, what
> kind of year to year maintenance it requires, etc.
for windows it is a
"Code Signing Certificates for Microsoft Authenticode
Digitally sign 32-bit or 64-bit user-mode (.exe, .cab, .dll, .ocx, .msi,
.xpi, and .xap files) and kernel-mode software. Provider for Microsoft
Windows Logo programs."
see [1] and [2]
[1] http://www.symantec.com/verisign/code-signing/microsoft-authenticode
[2] overview http://www.symantec.com/code-signing
I found a price by Symantec of 499$/year (reduced prices for 2 or 3
years) but there was already an opportunity that we can find a sponsor,
potentially a provider of such certificates.
Juergen
>
> Jürgen Schmidt wrote on Wed, Mar 20, 2013 at 10:28:23 +0100:
>> Hi,
>>
>> I reused this existing thread to restart the discussion about official
>> code signing. In case of AOO we are moving towards our next major
>> release AOO 4.0 which is planned for end if June. With over 40 million
>> downloads in less than 1 year and most of them for Windows this topic is
>> still very important for the project to provide the best user experience
>> and the necessary trust in the product on modern Windows Systems like
>> Windows 8.
>>
>> On http://wiki.apache.org/general/ASFCodeSigning#preview I started to
>> collect requirements and describe also the existing solution in AOO
>> today and how it can be used in a more general approach.
>>
>> The proposal is only one example but I think a practical one when I take
>> all the security concerns into account. But of course it probably
>> requires interaction with the trusted paid staff members.
>>
>> I hope we can move this important topic forward and can find a
>> satisfying solution for all ASF projects who need code signing.
>>
>> Juergen
>>
>>
>>
>>
Re: Official code signing certificate
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
So, basically:
- project maintains a build script
(does checkout, build, and prepares end-user-facing package; doesn't
run unit/regression tests)
- the script uses as input a certificate that only root@ has access to
- root@ runs the script (against a specific tag and revision in svn) and
publishes the results
So... what kind of certificate is that? How much does it cost, what
kind of year to year maintenance it requires, etc.
Jürgen Schmidt wrote on Wed, Mar 20, 2013 at 10:28:23 +0100:
> Hi,
>
> I reused this existing thread to restart the discussion about official
> code signing. In case of AOO we are moving towards our next major
> release AOO 4.0 which is planned for end if June. With over 40 million
> downloads in less than 1 year and most of them for Windows this topic is
> still very important for the project to provide the best user experience
> and the necessary trust in the product on modern Windows Systems like
> Windows 8.
>
> On http://wiki.apache.org/general/ASFCodeSigning#preview I started to
> collect requirements and describe also the existing solution in AOO
> today and how it can be used in a more general approach.
>
> The proposal is only one example but I think a practical one when I take
> all the security concerns into account. But of course it probably
> requires interaction with the trusted paid staff members.
>
> I hope we can move this important topic forward and can find a
> satisfying solution for all ASF projects who need code signing.
>
> Juergen
>
>
>
>
Re: Official code signing certificate
Posted by Jürgen Schmidt <jo...@gmail.com>.
Hi,
I reused this existing thread to restart the discussion about official
code signing. In case of AOO we are moving towards our next major
release AOO 4.0 which is planned for end if June. With over 40 million
downloads in less than 1 year and most of them for Windows this topic is
still very important for the project to provide the best user experience
and the necessary trust in the product on modern Windows Systems like
Windows 8.
On http://wiki.apache.org/general/ASFCodeSigning#preview I started to
collect requirements and describe also the existing solution in AOO
today and how it can be used in a more general approach.
The proposal is only one example but I think a practical one when I take
all the security concerns into account. But of course it probably
requires interaction with the trusted paid staff members.
I hope we can move this important topic forward and can find a
satisfying solution for all ASF projects who need code signing.
Juergen