Community
Participate
Working Groups
What is the reason for the signing certificates to not be made available on the build machine? I understand that someone could start signing his own artifacts with the EF certificates, but do we believe that eclipse committers would actually do that? We do trust ppl to not do random stuffs in the SCM, could not we trust them to not steal the signing key?
Is this a bug? You've already asked the question on the mailing list. Why use two channels simultaneously? Please pick one and I'll answer on it.
> We do trust ppl to not do random stuffs in the SCM, could not we trust them to > not steal the signing key? As long as laptops can be stolen, lost or left unattended, private keys and saved passwords can be accessed by malware, improper sharing, unsecured backups or by other means, then I will not be capable of trusting with 100% assurance that the person currently logging in to one of my systems is the person I have granted access to. Consider how hard would it be to write an Eclipse plugin that contains a backdoor that leaks information to a third party? The UDC code is a great place to start, and the Marketplace repo is a great distribution medium. Nothing personal. It's not *you* I don't trust, it's who can be impersonating you. If an intruder accesses the SCM, damage will be obvious: we'll know which account was compromised, and the code changes will be visible to all that sync up. We can restore from backups if need be. The likelyhood of bad code being incorporated into a release build is low. If the private signing key is compromised, it will be difficult to isolate which account was used to leak it. Damage will not be immediately visible, until we stumble upon malware that is digitally signed by the Eclipse Foundation. Do I trust that Hudson doesn't contain backdoors? All the Hudson plugins too? The java containers it is run on? It is impossible for us to be 100% secure in every aspect. But in terms of signing, I believe the current setup is reasonably functional while limiting the most obvious exposures and risks.
If we put security issues aside, there's the issue of computational resources that are needed to sign. At Eclipse, signing also involves the jarprocessor, which makes signing a CPU- and disk-intensive operation. By having control over the signing queue, I can direct signing to specific servers and hard disk arrays which have the resources to sign, minimizing the impact of signing on other services such as Bugzilla or CVS.
Yep, I really think you should be guarding the signing keys with your life. If the signing key gets out in the wild, it invalidates the signature of *every* piece of software that was ever signed with that key. I.e., for every past Eclipse release that used that key, you can no longer establish authenticity. The central control point also enables you to log and audit what was signed, when it was signed, who requested it, etc. I don't know if this is done today but that would be a valuable safeguard.
Pascal, is there a specific reason why the signing key must be available? The current setup is similar to a process involving a HSM. Typically, the key is located inside such a device and the device does the encryption/signing.
> Yep, I really think you should be guarding the signing keys with your life. The only things I will guard with my life are the lives of my children. In the Eclipse world, aside from diligently guarding the signing keys, I invest even greater efforts in guarding the Linux kernel we use. Since the vast majority of root vulnerabilities are exploitable by local accounts, you can certainly understand my contention with committer access to SSH shells. This is the stuff that keeps me up at night. But I do assume that those committers blessed with shell access guard their keys/laptops/backups as diligently as I do the kernel. Regardless, this specific conversation is one best enjoyed over beverages in a southern US state during the month of March.
As I'm sure you agree, I'll close this as WONTFIX.
The important aspect here isn't so much having the key available, but rather making it easier to sign from the build process running on hudson. Perhaps, if I rephrase the request, it will be more acceptable... What if there was a shell script available in a set location on all hudson nodes. The script can be invoked to perform signing. The script must be blocking to be useful. The actual implementation of this script is immaterial. It can ship zip to the appropriate location, invoke existing script, wait and then ship the result back, etc. Raising the severity of this as the current situation makes signing highly impractical for many projects.
(In reply to comment #5) > Pascal, is there a specific reason why the signing key must be available? The > current setup is similar to a process involving a HSM. Typically, the key is > located inside such a device and the device does the encryption/signing. HSM? High School Musical? :) The problem is one of ease of setting up builds. Sure everybody does it right now but it ends up being a major source of pain (in comparison of the other must do), frustration and probably sleepless nights. If we provided an executable that signed individual jars and could be used as a jar signer (and thus hides the keys) then the signing could just be done in process with the build. As for the cost, there is surely a heavy cost impaired in the current signing process (esp around disk) but this is because we are creating additional work with having to handle those big zips of jars. I'm pretty sure that doing the signing in-line with the build would actually be much less disk intensive since we would not have to handle those big zips. I'm also ready to bet that it would reduce the overall build times (no more creation of the zip, and tweaking of the p2 repo after the fact) but would also help small build to not be stuck behind big ones. Finally on the security concerns. I think if a laptop was being stolen today, nothing would prevent anyone to get some random code to be signed. I could commit code to the project, run the build, undo my changes (clear the CVS history from the server, after all I have ssh access), and leave the place clean.
(re-opening since I think I undid this from Konstantin)
According to the comments on cross-project-issues-dev, hudson user is already able to invoke the signing script, so there are no security implication from this request... The current situation seems to be that every project writes and maintains their own "copy, sign, wait, copy back" routine, which seems rather silly. Let's have a common shell script for doing this available at a set location on Hudson nodes. Here is one possible implementation to use as the base for this: http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.releng.eclipsebuilder/buildAll.xml?revision=1.381&view=markup See signMasterFeature target.
Removing webmaster as the assignee, since this is something you don't need us to implement.
Why shouldn't it be the responsibility of emo/webmaster to provide and maintain a _usable_ signing infrastructure on emo-provided build hardware? The current infrastructure is ridiculously difficult to use, so I don't accept the implication that it isn't emo/webmaster responsibility to bring it to the point where it is usable.
> Why shouldn't it be the responsibility of emo/webmaster to provide and maintain > a _usable_ signing infrastructure on emo-provided build hardware? The current signing infrastructure is usable, since there are bundles being signed daily, and in an automated fashion. > The current situation seems to be that every project writes and maintains their > own "copy, sign, wait, copy back" routine, which seems rather silly. Let's have > a common shell script for doing this available at a set location on Hudson > nodes. I agree -- it is completely silly for projects to be doing the same thing. Hence this is an opportunity for release engineers to break down the silos and share their common tools, perhaps even placing them in "/shared", so that all can take advantage of them. Feel free to reassign this to me if you insist on doing so, but do know that it will go to the bottom list of my to-do list since a) your claims of signing being "unusable" are absolutely false, and b) there are (apparently) no shortage of tools available for you to use.
That is a terrible attitude to be taking. I guess you are suggesting it isn't reasonable to expect that membership dues paid by everyone be put into improving shared instrastructure. You known, when a user files a bug on software that I maintain saying it lacks usability in a particular area, I don't tell them there is no problem as Bob and Sue have figured out how to work around the issues. I don't tell them to solve it themselves. I look to see if there is a way to improve the usability.
I find it very unfortunate that you draw such a conclusion. Your interpretation of my words is that I do not want to help you. What I am saying is that I cannot foresee addressing this in the near future, and although you are more than welcome to wait for me to address this, if you can use an available workaround, and perhaps even help out other fellow committers in the process, that is certainly an alternative. I am all for improving the shared infrastructure for committers. So I am assigning this back to EMO IT. But I am being honest and realistic with you by setting this to a low-priority enhancement.
I don't see how I could have interpreted your comments any differently. You are saying that you don't believe there is a problem to be solved and if we insist there is a problem, you will put it at the very bottom of your to-do list. Your own words. Why all this resistance and stalling? This is probably like 10 minutes of work for someone like you skilled in shell scripts, ssh, sftp, etc. I don't have the necessary skills to do it in a reasonable amount of time and that's the point. The committers are in it to build Eclipse software, not to mess with the infrastructure.
Konstantin, Another approach would be to ask for help from other people who are also interested in this issue and work on a solution together. Saying something will just take 10 minutes is a hard sell when the webmasters have hundreds of other bugs that "just take ten minutes". The webmasters are not release engineers that write build scripts, they support the eclipse.org infrastructure. Denis' point is that many teams successfully sign their builds every day is true. Could it be improved? Sure. But is works for many people. Improving it takes time and effort, and there are many other priorities. A good start would be for you to take of one the existing signing scripts from a project and make it more generic. If you are unwilling to invest any time in trying to craft a solution, it's hard to convince other people to fix things for you :-)
I am not asking EMO IT to write my project's build for me. EMO IT provides a signing service. It is part of the infrastructure that projects are required to use. It is very difficult to use, especially for projects without dedicated releng people (most projects). The request is to make it easier to use. Can usability issues in currently-provided infrastructure be worked around? Clearly. Can the community step up and do this on our own? Perhaps. Hasn't happened yet. My contention is that the community shouldn't be asked to help create and maintain adequate infrastructure. I see it as the job of the EMO to provide 1st rate infrastructure so that project teams can focus on delivering Eclipse software.
Since I needed to implement signing anyway, I went ahead and implemented it in a stand-alone manner. Right now, this script is in CVS for Sapphire project where it has been tested, but as I've stated already, I don't believe this belongs in a project's build system. This should be part of the infrastructure for any build to call as necessary. Please publish the two files that I will attach in a folder that's accessible from any eclipse.org build server. These files will need to be backed up together with the rest of server configuration and ideally should be source controlled somewhere... Instructions for use are in sign.xml file. As part of publishing, please replace ###sign-hudson.xml## token in the instructions with full path to wherever this script is going to be located.
Created attachment 186563 [details] sign.xml
Created attachment 186564 [details] sign-local.xml
I have also opened Bug 334032 to separately track the performance or scheduling problem with the signing service that prevents signing jar at a time to be a viable solution.
I was able to integrate signing and pack200 with the Mylyn Tycho build using a combination of ant and a shell script similar to Konstantin's approach. For anyone interested here is the pom and scripts: http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.mylyn/org.eclipse.mylyn.releng/main-site/pom.xml?view=markup&root=Mylyn_Project http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.mylyn/org.eclipse.mylyn.releng/pack-and-sign/?root=Mylyn_Project
We've created a web-based signing service which will be much more friendly for Hudson/Maven/Tycho. Please see the docs on the wiki for details on how to invoke it: http://wiki.eclipse.org/IT_Infrastructure_Doc#Sign_my_plugins.2FZIP_files.3F
