openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From janI <j...@apache.org>
Subject Re: Official code signing certificate
Date Sat, 25 May 2013 19:17:11 GMT
On 25 May 2013 20:40, Rob Weir <robweir@apache.org> wrote:

> On Fri, May 24, 2013 at 6:17 PM, Dave Fisher <dave2wave@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 <robweir@apache.org> wrote:
> >>> On Fri, May 24, 2013 at 5:01 PM, janI <jani@apache.org> wrote:
> >>>> On 24 May 2013 22:30, Juergen Schmidt <jogischmidt@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 <scott.deboy@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 <sebbaz@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." <wrowe@rowe-clan.net> wrote:
> >>>>>>>>
> >>>>>>>>> On Tue, 26 Mar 2013 00:56:06 +0200
> >>>>>>>>> Daniel Shahaf <d.s@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
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message