On 25 May 2013 22:02, Rob Weir <[email protected]> wrote: > On Sat, May 25, 2013 at 3:17 PM, janI <[email protected]> wrote: > > On 25 May 2013 20:40, Rob Weir <[email protected]> wrote: > > > >> On Fri, May 24, 2013 at 6:17 PM, Dave Fisher <[email protected]> > >> 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 <[email protected]> > wrote: > >> >>> On Fri, May 24, 2013 at 5:01 PM, janI <[email protected]> wrote: > >> >>>> On 24 May 2013 22:30, Juergen Schmidt <[email protected]> > 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 <[email protected]> > >> >>>>>> Date: 24 May 2013 18:59 > >> >>>>>> Subject: Re: Official code signing certificate > >> >>>>>> To: [email protected] > >> >>>>>> > >> >>>>>> > >> >>>>>> 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 <[email protected]> wrote: > >> >>>>>>> You are now in http://wiki.apache.org/general/ContributorsGroup > >> >>>>>>> > >> >>>>>>> > >> >>>>>>> On 12 April 2013 17:32, William A. Rowe Jr. < > [email protected]> > >> >>>>> wrote: > >> >>>>>>> > >> >>>>>>>> On Fri, 12 Apr 2013 10:47:29 -0500 > >> >>>>>>>> "William A. Rowe Jr." <[email protected]> wrote: > >> >>>>>>>> > >> >>>>>>>>> On Tue, 26 Mar 2013 00:56:06 +0200 > >> >>>>>>>>> Daniel Shahaf <[email protected]> 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: [email protected] > >> >> For additional commands, e-mail: [email protected] > >> >> > >> > > >> > > >> > --------------------------------------------------------------------- > >> > To unsubscribe, e-mail: [email protected] > >> > For additional commands, e-mail: [email protected] > >> > > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [email protected] > >> For additional commands, e-mail: [email protected] > >> > >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
