Details

    • Type: New Feature New Feature
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Fix Version/s: Oct 2014
    • Component/s: Other/Misc
    • Labels:
      None

      Description

      The Logging Services project provides a WebStart-deployed Swing application, Chainsaw. To deploy Chainsaw via WebStart and take advantage of all of its features, the jars that are downloaded must be signed by a code signing certificate which has been signed by a trusted root CA.

      It would seem to me it would make sense to have this code signing certificate and associated keys managed by the ASF and not be a project-specific certificate, so other projects could take advantage of the same resources. If you feel it makes more sense to get Logging Services its own code signing certificate that is managed by the PMC, I'm fine with that as well - I would just like the issue to be resolved.

      I assume if this resource were an ASF-wide resource, the keys and certificate would be managed by infra. If so, I'm not sure what workflow infra would like to use - maybe a jira issue with release candidate jars and pgp info, and signed jars could be added back to the same jira? We don't release often, so just let us know what you would like.

      Our needs are relatively simple, and I understand others may have more complex needs. PMC members or the RM could manage self-signed certificates and 'get by', but I would rather have an official code signing cert provided by ASF itself.

        Issue Links

          Activity

          Mark Thomas made changes -
          Comment [ I have install swftool but pdf2swf missing in usr/local/bin. that's why i am getting pdf2swf error . how to install pdf2swf library.? when i run ./configure ,in my log i show error like disabling pdf2swf . kindly help me how to insall pdf2swf library
          ]
          Gavin made changes -
          Fix Version/s Oct 2014 [ 12328828 ]
          Gavin made changes -
          Fix Version/s Sep 2014 [ 12328827 ]
          Gavin made changes -
          Fix Version/s Sep 2014 [ 12328827 ]
          Martin Desruisseaux made changes -
          Link This issue is depended upon by SIS-181 [ SIS-181 ]
          Mark Thomas made changes -
          Status Waiting for Infra [ 10011 ] Closed [ 6 ]
          Resolution Fixed [ 1 ]
          Show
          Mark Thomas added a comment - See for more information https://blogs.apache.org/infra/entry/code_signing_service_now_available
          Mark Thomas made changes -
          Comment [ Hi Sebastian
          openmeetings 3.0.3 mssql bug

          CREATE TABLE om_user_right (user_id BIGINT, right VARCHAR(20))

          righte not use wituot [right] in sql

          please fix it
          tanx ]
          Gavin made changes -
          Component/s Other/Misc [ 12317109 ]
          Hide
          Mark Thomas added a comment -
          [~desruisseaux] We'll be using Symantec's code signing service. The (very) short verison is each PMC that wants to sign stuff will be configured in the service then each RM will be given an account to enable them to sign stuff as the PMC (RM's for multiple PMCs will get multiple accounts). Each signing event (a group of one or more files that are signed at the same time) uses a unique signing key so we can revoke an individual signing event if we need to. We are close to getting the live service up and running. Rather more complete docs than the above summary will be provided once it is ready for PMCs to use.
          Show
          Mark Thomas added a comment - [~desruisseaux] We'll be using Symantec's code signing service. The (very) short verison is each PMC that wants to sign stuff will be configured in the service then each RM will be given an account to enable them to sign stuff as the PMC (RM's for multiple PMCs will get multiple accounts). Each signing event (a group of one or more files that are signed at the same time) uses a unique signing key so we can revoke an individual signing event if we need to. We are close to getting the live service up and running. Rather more complete docs than the above summary will be provided once it is ready for PMCs to use.
          Hide
          Martin Desruisseaux added a comment -
          +1 (SIS), but I wonder which key would be used? Would release managers continue to sign the JAR themselves, or would the Apache foundation provides a build machine dedicated to releases which would apply an Apache signature on the build results?
          Show
          Martin Desruisseaux added a comment - +1 (SIS), but I wonder which key would be used? Would release managers continue to sign the JAR themselves, or would the Apache foundation provides a build machine dedicated to releases which would apply an Apache signature on the build results?
          Hide
          Imesh Gunaratne added a comment -
          +1 (Stratos)
          Show
          Imesh Gunaratne added a comment - +1 (Stratos)
          Hide
          Arvind Prabhakar added a comment -
          +1 (Sqoop, Flume)
          Show
          Arvind Prabhakar added a comment - +1 (Sqoop, Flume)
          Hide
          Mark Thomas added a comment -
          +1 (Commons)
          Show
          Mark Thomas added a comment - +1 (Commons)
          Hide
          Mark Thomas added a comment -
          @Rob Walker I don't understand the point you are trying to make. No-one is suggesting that the private keys used for code signing would be public in any way.
          Show
          Mark Thomas added a comment - @Rob Walker I don't understand the point you are trying to make. No-one is suggesting that the private keys used for code signing would be public in any way.
          Hide
          Marshall Schor added a comment -
          +1 (UIMA)
          Show
          Marshall Schor added a comment - +1 (UIMA)
          Hide
          Robert Munteanu added a comment -
          +1 (Sling)
          Show
          Robert Munteanu added a comment - +1 (Sling)
          Hide
          Sandro Martini added a comment -
          +1 (Pivot)
          Show
          Sandro Martini added a comment - +1 (Pivot)
          Hide
          Rob Walker added a comment -
          I hate to be a voice of doom here - but there seems to me to be an inherent problem with code signing certs for open source projects.

          The whole point of code signing is "trust" - someone receiving an app that has been signed needs trust in the publisher and the CA issuing the cert. If the keys needed to use the cert are in any way public and known beyond the publisher, then it allows unscrupulous people to sign malicious code. Or at least that is my understanding anyhow!

          We have commercial code signing certs for just the scenario described here - signing a WebStart launchable variant of our app. The keys to those certs are locked down and only accessible by the release phase of our build process.

          There is an option we have seen with Felix that you actually only need to sign the immediate launcher Jars. Once Felix's own classloaders kick in, the code is considered trusted and can run. That in itself is something of a security hole though that could allow an attacker to use a secured launcher with untrusted JARs. As a result, we actually sign all our jars and perform further inline cert checks to prevent this.

          Just a thought - others more experienced in this area my know of better options and alternatives
          Show
          Rob Walker added a comment - I hate to be a voice of doom here - but there seems to me to be an inherent problem with code signing certs for open source projects. The whole point of code signing is "trust" - someone receiving an app that has been signed needs trust in the publisher and the CA issuing the cert. If the keys needed to use the cert are in any way public and known beyond the publisher, then it allows unscrupulous people to sign malicious code. Or at least that is my understanding anyhow! We have commercial code signing certs for just the scenario described here - signing a WebStart launchable variant of our app. The keys to those certs are locked down and only accessible by the release phase of our build process. There is an option we have seen with Felix that you actually only need to sign the immediate launcher Jars. Once Felix's own classloaders kick in, the code is considered trusted and can run. That in itself is something of a security hole though that could allow an attacker to use a secured launcher with untrusted JARs. As a result, we actually sign all our jars and perform further inline cert checks to prevent this. Just a thought - others more experienced in this area my know of better options and alternatives
          Hide
          Joan Touzet added a comment -
          +1 (CouchDB)
          Show
          Joan Touzet added a comment - +1 (CouchDB)
          Hide
          Matt Sicker added a comment -
          +1 (Log4j2)
          Show
          Matt Sicker added a comment - +1 (Log4j2)
          Hide
          John Kinsella added a comment -
          +1 (CloudStack)
          Show
          John Kinsella added a comment - +1 (CloudStack)
          Hide
          SebastianWagner added a comment - - edited
          +1 (OpenMeetings)
          Show
          SebastianWagner added a comment - - edited +1 (OpenMeetings)
          Hide
          jan iversen added a comment -
          David just asked projects to reigster their interest, AOO have a big interest in digital signing (as can be seen in my participation).
          Show
          jan iversen added a comment - David just asked projects to reigster their interest, AOO have a big interest in digital signing (as can be seen in my participation).
          Hide
          Matt Sicker added a comment -
          The maven-antrun-plugin makes porting the Ant task rather trivial at first. Making a proper Maven plugin, however, could take longer. ;)
          Show
          Matt Sicker added a comment - The maven-antrun-plugin makes porting the Ant task rather trivial at first. Making a proper Maven plugin, however, could take longer. ;)
          Hide
          Mark Thomas added a comment -
          Symantec have been explicitly pinged for the cost information for VP Infra to review. We are now waiting for their response...
          Show
          Mark Thomas added a comment - Symantec have been explicitly pinged for the cost information for VP Infra to review. We are now waiting for their response...
          Hide
          Mark Thomas added a comment -
          I can confirm that we can integrate the code signing with our build processes. I have done this with a custom Ant task. Projects that use other build technologies (e.g. Maven) should find it fairly simple to write an equivalent plug-in.

          The next steps are to get cost details from Symantec for the VP Infra to review. If those are approved I will go ahead and start getting the production service set up. Initially I will be doing this for the Apache Commons (for the Commons Daemon binaries) and Apache Tomcat (for the Tomcat Windows installer) PMCs. I want to make sure that the signing certificates are set up the way we want them before rolling this out to other interested PMCs.

          While all that admin is being done, I plan to clean up and document my hacked up custom Ant task and put it somewhere where other projects can make use of it.
          Show
          Mark Thomas added a comment - I can confirm that we can integrate the code signing with our build processes. I have done this with a custom Ant task. Projects that use other build technologies (e.g. Maven) should find it fairly simple to write an equivalent plug-in. The next steps are to get cost details from Symantec for the VP Infra to review. If those are approved I will go ahead and start getting the production service set up. Initially I will be doing this for the Apache Commons (for the Commons Daemon binaries) and Apache Tomcat (for the Tomcat Windows installer) PMCs. I want to make sure that the signing certificates are set up the way we want them before rolling this out to other interested PMCs. While all that admin is being done, I plan to clean up and document my hacked up custom Ant task and put it somewhere where other projects can make use of it.
          Hide
          BBS Technik added a comment -


          Hello Maxim,
          this looks like a little bit of light at the end of the tunnel. The java code signing problem with the screen sharing app is a real show stopper for a lot of the normal users.
          Have you an idea, when om can participate on the apache certificates?
           
          Thanks a lot for your and all the teams hard work on om.
          Best regards
           
          Ed
           
           

          Gesendet: Donnerstag, 26. Juni 2014 um 16:06 Uhr
          Von: "Maxim Solodovnik (JIRA)" <jira@apache.org>
          An: dormitilla@gmx.de
          Betreff: [jira] [Comment Edited] (INFRA-3991) Request for code signing certificate
          [ https://issues.apache.org/jira/browse/INFRA-3991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14044675#comment-14044675 ]

          Maxim Solodovnik edited comment on INFRA-3991 at 6/26/14 2:05 PM:
          ------------------------------------------------------------------

          Thanks for the update
          would it be somehow integrated with ant/maven builds?


          was (Author: solomax):
          Thanks for the update would it be somehow integrated with ant/maven builds?




          --
          This message was sent by Atlassian JIRA
          (v6.2#6252)
          Show
          BBS Technik added a comment - Hello Maxim, this looks like a little bit of light at the end of the tunnel. The java code signing problem with the screen sharing app is a real show stopper for a lot of the normal users. Have you an idea, when om can participate on the apache certificates?   Thanks a lot for your and all the teams hard work on om. Best regards   Ed     Gesendet: Donnerstag, 26. Juni 2014 um 16:06 Uhr Von: "Maxim Solodovnik (JIRA)" < jira@apache.org > An:  dormitilla@gmx.de Betreff: [jira] [Comment Edited] ( INFRA-3991 ) Request for code signing certificate [ https://issues.apache.org/jira/browse/INFRA-3991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14044675#comment-14044675 ] Maxim Solodovnik edited comment on INFRA-3991 at 6/26/14 2:05 PM: ------------------------------------------------------------------ Thanks for the update would it be somehow integrated with ant/maven builds? was (Author: solomax): Thanks for the update would it be somehow integrated with ant/maven builds? -- This message was sent by Atlassian JIRA (v6.2#6252)
          Hide
          Maxim Solodovnik added a comment - - edited
          Thanks for the update
          would it be somehow integrated with ant/maven builds?
          Show
          Maxim Solodovnik added a comment - - edited Thanks for the update would it be somehow integrated with ant/maven builds?
          Hide
          Mark Thomas added a comment -
          I been somewhat distracted with other work for a while but have been able to come back to this this week and hope to reach a resolution fairly shortly.

          The Web based UI looks to meet our needs. Ideally, some customisation will be required so it uses ASF terminology but in the worst case we can provide documentation to deal with that.

          We will need to work with Symantec on exactly how they are going to validate new accounts. For release managers, we want it to be as simple as you have an @apache.org address, you can have a user account. The PMC process may require some manual infra steps but given the number of PMCs that should be manageable.

          I am currently looking at the SOAP API to ensure that we can integrate it with our build processes (we don't want signing to have to be a manual process). I have a basic client created for testing and a stubbed out custom Ant Task in the Tomcat build process for signing. As soon as I get some credentials for the SOAP API I'll start bringing these two bits together.
          Show
          Mark Thomas added a comment - I been somewhat distracted with other work for a while but have been able to come back to this this week and hope to reach a resolution fairly shortly. The Web based UI looks to meet our needs. Ideally, some customisation will be required so it uses ASF terminology but in the worst case we can provide documentation to deal with that. We will need to work with Symantec on exactly how they are going to validate new accounts. For release managers, we want it to be as simple as you have an @apache.org address, you can have a user account. The PMC process may require some manual infra steps but given the number of PMCs that should be manageable. I am currently looking at the SOAP API to ensure that we can integrate it with our build processes (we don't want signing to have to be a manual process). I have a basic client created for testing and a stubbed out custom Ant Task in the Tomcat build process for signing. As soon as I get some credentials for the SOAP API I'll start bringing these two bits together.
          Robert Munteanu made changes -
          Link This issue relates to SLING-3098 [ SLING-3098 ]
          Hide
          Robert Munteanu added a comment -
          The Apache Sling project is also interested, as we would like to sign the Eclipse plug-ins that we produce.
          Show
          Robert Munteanu added a comment - The Apache Sling project is also interested, as we would like to sign the Eclipse plug-ins that we produce.
          Hide
          Peter Dähn added a comment -
          Hallo,

          ich habe bis einschließlich 27.04.2014 frei. Die E-Mail wird nicht weitergeleitet.

          Anfragen bezüglich OpenOLAT/OpenMeetings bitte an lms-admin@vcrp.de.

          Viele Grüße
          Peter Dähn
          Show
          Peter Dähn added a comment - Hallo, ich habe bis einschließlich 27.04.2014 frei. Die E-Mail wird nicht weitergeleitet. Anfragen bezüglich OpenOLAT/OpenMeetings bitte an lms-admin@vcrp.de . Viele Grüße Peter Dähn
          Sandro Martini made changes -
          Link This issue relates to PIVOT-920 [ PIVOT-920 ]
          Hide
          Sandro Martini added a comment -
          Hi all (just for Info) even Pivot has the same problem, in all Tutorials / DEmos published in the web site (some unsigned, some signed).
          Show
          Sandro Martini added a comment - Hi all (just for Info) even Pivot has the same problem, in all Tutorials / DEmos published in the web site (some unsigned, some signed).
          Matt Sicker made changes -
          Link This issue blocks LOG4J2-588 [ LOG4J2-588 ]
          Hide
          #asfinfra Bot added a comment -
          <pctony> Ack. When we get to a wider rollout we will keep you in mind. Thanks.
          Show
          #asfinfra Bot added a comment - <pctony> Ack. When we get to a wider rollout we will keep you in mind. Thanks.
          Hide
          SebastianWagner added a comment -
          Apache OpenMeetings also has a WebStart application and would be interested in getting a cert sign from a trusted root auth.
          Show
          SebastianWagner added a comment - Apache OpenMeetings also has a WebStart application and would be interested in getting a cert sign from a trusted root auth.
          Gavin made changes -
          Status Reopened [ 4 ] Waiting for Infra [ 10011 ]
          Hide
          jan iversen added a comment -
          Getting it to work for AOO looks as if it might take a bit longer (not due to technical issues), so I suggest a slightly different path.

          Let Tomcat iron out the basic process, with feedback from AOO, then open it for projects that can use the "tomcat method" unchanged. AOO start implementation in parallel or just after tomcat, and once finished, the service will be opened up for all projects.

          This is just a suggestion, Mark heads the project and layout the path to follow.
          Show
          jan iversen added a comment - Getting it to work for AOO looks as if it might take a bit longer (not due to technical issues), so I suggest a slightly different path. Let Tomcat iron out the basic process, with feedback from AOO, then open it for projects that can use the "tomcat method" unchanged. AOO start implementation in parallel or just after tomcat, and once finished, the service will be opened up for all projects. This is just a suggestion, Mark heads the project and layout the path to follow.
          Hide
          Alex O'Ree added a comment -
          The jUDDI project has a web based applet that also needs to be signed. We would certainly use the service too.
          Show
          Alex O'Ree added a comment - The jUDDI project has a web based applet that also needs to be signed. We would certainly use the service too.
          Hide
          Scott Deboy added a comment -
          Chainsaw's requirements are very straightforward, and the lessons learned from Tomcat should apply directly to the needs of Logging Services. Would like Logging Services to be able to use this service with Chainsaw after Tomcat works out the kinks. I don't believe there are any additional issues OpenOffice will discover that the would be applicable to Logging Services.
          Show
          Scott Deboy added a comment - Chainsaw's requirements are very straightforward, and the lessons learned from Tomcat should apply directly to the needs of Logging Services. Would like Logging Services to be able to use this service with Chainsaw after Tomcat works out the kinks. I don't believe there are any additional issues OpenOffice will discover that the would be applicable to Logging Services.
          Hide
          Mark Thomas added a comment -
          The conversation went very well. No show-stoppers were identified. We intend to go ahead with a trial. Tomcat will be first to iron out the basic process followed by OpenOffice on the basis if we can get it to work for AOO, it should work for any ASF project. If the trial is successful, the service will be opened up to any other interested project.
          Show
          Mark Thomas added a comment - The conversation went very well. No show-stoppers were identified. We intend to go ahead with a trial. Tomcat will be first to iron out the basic process followed by OpenOffice on the basis if we can get it to work for AOO, it should work for any ASF project. If the trial is successful, the service will be opened up to any other interested project.
          Hide
          Mark Thomas added a comment -
          OK. I'll propose one of the following:
          Tuesday, December 10, noon-2 pm Pacific
          Friday, December 13, 7-9 am Pacific
          Friday, December 13, 11-1 pm Pacific
          Show
          Mark Thomas added a comment - OK. I'll propose one of the following: Tuesday, December 10, noon-2 pm Pacific Friday, December 13, 7-9 am Pacific Friday, December 13, 11-1 pm Pacific
          Hide
          jan iversen added a comment -
          Being in spain I have +9 hours, so please end time no later than 2pm pacific.

           I will represent AOO, and can any day, with the above time restriction.

          rgds
          jan I.
          Show
          jan iversen added a comment - Being in spain I have +9 hours, so please end time no later than 2pm pacific.  I will represent AOO, and can any day, with the above time restriction. rgds jan I.
          Hide
          Mark Thomas added a comment -
          Symantec have given us some options for the WebEx. I've been a little slow adding these so I'm going to ignore the ones for next week. The WebEx is expected to last 2 hours. That leaves:

          Monday, December 9, 8-12 noon Pacific
          Tuesday, December 10, 11-2 pm Pacific
          Wednesday, December 11, 9-12 noon Pacific
          Friday, December 13, 7-9 am Pacific
          Friday, December 13, 10-1 pm Pacific

          Of those times, I can do the following:
          Tuesday, December 10, noon-2 pm Pacific
          Friday, December 13, 7-9 am Pacific
          Friday, December 13, 11-1 pm Pacific
          Show
          Mark Thomas added a comment - Symantec have given us some options for the WebEx. I've been a little slow adding these so I'm going to ignore the ones for next week. The WebEx is expected to last 2 hours. That leaves: Monday, December 9, 8-12 noon Pacific Tuesday, December 10, 11-2 pm Pacific Wednesday, December 11, 9-12 noon Pacific Friday, December 13, 7-9 am Pacific Friday, December 13, 10-1 pm Pacific Of those times, I can do the following: Tuesday, December 10, noon-2 pm Pacific Friday, December 13, 7-9 am Pacific Friday, December 13, 11-1 pm Pacific
          Hide
          Mark Thomas added a comment - - edited
          Short version: This still looks like it could be made to work for us.

          Infra would be the "Service Provider".

          PMCs would be "Software Publishers". The PMC would decide the criteria for adding users to their publisher. The only mandatory requirement would be that they must be an ASF committer with an ASF e-mail address.

          Thoughts (to follow-up on in the WebEx):
          - My assumption is that the releases would have to be signed prior to the PMC's release vote. I don't have a problem with that. If the release fails, we just revoke the signature (which we can do on a case by case basis).
          - The personal information that users should have to provide in order to get an account should be the bare minimum, ideally none. i.e. just their ASF e-mail address and proving that they have access to that address.
          - Need to figure out how manual vs. automated to make account management. Infra manually create/remove PMC accounts on request and PMCs manually create/remove release managers looks to be scalable.
          - I'd like to see more clarity on how fine-grained the security permissions are.
          Show
          Mark Thomas added a comment - - edited Short version: This still looks like it could be made to work for us. Infra would be the "Service Provider". PMCs would be "Software Publishers". The PMC would decide the criteria for adding users to their publisher. The only mandatory requirement would be that they must be an ASF committer with an ASF e-mail address. Thoughts (to follow-up on in the WebEx): - My assumption is that the releases would have to be signed prior to the PMC's release vote. I don't have a problem with that. If the release fails, we just revoke the signature (which we can do on a case by case basis). - The personal information that users should have to provide in order to get an account should be the bare minimum, ideally none. i.e. just their ASF e-mail address and proving that they have access to that address. - Need to figure out how manual vs. automated to make account management. Infra manually create/remove PMC accounts on request and PMCs manually create/remove release managers looks to be scalable. - I'd like to see more clarity on how fine-grained the security permissions are.
          Hide
          Mark Thomas added a comment - - edited
          We now have an NDA in place with Symantec and they have provided some documentation on the service. The next steps are for use to review this documentation. After that, Symantec will arrange a "deep-dive" WebEx where we can explore the details of how this would work.

          The documentation is in the private foundation repo under Correspondence/Symantec

          If anyone doesn't have access to that area, ping me directly and I'll send you the files.

          I'd like to get at least one representative from Logging, OpenOffice, Tomcat and Infra to review these docs and to attend the WebEx. I'm happy to cover Tomcat and Infra although the more the merrier. I'll add my review notes shortly.

          I'm going to suggest a WebEx with Symantec for early December.
          Show
          Mark Thomas added a comment - - edited We now have an NDA in place with Symantec and they have provided some documentation on the service. The next steps are for use to review this documentation. After that, Symantec will arrange a "deep-dive" WebEx where we can explore the details of how this would work. The documentation is in the private foundation repo under Correspondence/Symantec If anyone doesn't have access to that area, ping me directly and I'll send you the files. I'd like to get at least one representative from Logging, OpenOffice, Tomcat and Infra to review these docs and to attend the WebEx. I'm happy to cover Tomcat and Infra although the more the merrier. I'll add my review notes shortly. I'm going to suggest a WebEx with Symantec for early December.
          Mark Thomas made changes -
          Assignee Tony Stevenson [ pctony ] Mark Thomas [ markt ]
          Hide
          Mark Thomas added a comment -
          As a infrastructure volunteer the tasks I choose to work on are selected based on how much time I have, how interested I am in the topic and whether it involves cleaning up a mess I am somehow responsible for. Code signing falls under the category of something I am interested in but it is not a high priority for me so it gets progressed as and when I have the time.

          Back in June I provided an explicit example of how folks could help - reaching out to Bill Rowe and reconnecting with Verisign (now Symantec). No one did. Hence progress stalled again.

          Back in August I reached out to Bill and got the necessary details. Still no-one volunteered to make contact with Symantec.

          This week I have found some time and have been in touch with Symantec. I've had a good conversation with them and we have an outline of a way forward. There are still a lot of details to iron out but at this stage I am hopeful we'll come up with a solution that works for at least 80% of our use cases.

          In terms of helping (to address Christian's question) there is nothing to do immediately. However, I am likely to be asking for a few interested PMCs (Tomcat, AOO, Logging) to review some materials in the next few weeks. Constructive feedback on those materials and possibly joining a conference call are areas where help will be appreciated. If I think of anything else that could help progress this, I'll mention it here.
          Show
          Mark Thomas added a comment - As a infrastructure volunteer the tasks I choose to work on are selected based on how much time I have, how interested I am in the topic and whether it involves cleaning up a mess I am somehow responsible for. Code signing falls under the category of something I am interested in but it is not a high priority for me so it gets progressed as and when I have the time. Back in June I provided an explicit example of how folks could help - reaching out to Bill Rowe and reconnecting with Verisign (now Symantec). No one did. Hence progress stalled again. Back in August I reached out to Bill and got the necessary details. Still no-one volunteered to make contact with Symantec. This week I have found some time and have been in touch with Symantec. I've had a good conversation with them and we have an outline of a way forward. There are still a lot of details to iron out but at this stage I am hopeful we'll come up with a solution that works for at least 80% of our use cases. In terms of helping (to address Christian's question) there is nothing to do immediately. However, I am likely to be asking for a few interested PMCs (Tomcat, AOO, Logging) to review some materials in the next few weeks. Constructive feedback on those materials and possibly joining a conference call are areas where help will be appreciated. If I think of anything else that could help progress this, I'll mention it here.
          Hide
          Christian Grobmeier added a comment -
          Ulrich: please be aware that Chainsaw doesn't necessary address "expert users". There are plenty of people to whom I spoke which were not Java expert but need Chainsaw for their daily work. For these people we would like to provide a great user experience. We currently work hard to move Apache Logging into a better light these days and of course a certificate would help here. As I understood Apache OpenOffice is also in need of such a certificate and their product is not aiming at expert users too.

          Upayavira: if there is anything we can do to help with this issue, we gladly do it. From this issue I could not understand what I can do to help. Sometimes we just need some help from the Infra team as they can tell us if it can work, how it works and if we can help with anything. This is one of these cases.
          Show
          Christian Grobmeier added a comment - Ulrich: please be aware that Chainsaw doesn't necessary address "expert users". There are plenty of people to whom I spoke which were not Java expert but need Chainsaw for their daily work. For these people we would like to provide a great user experience. We currently work hard to move Apache Logging into a better light these days and of course a certificate would help here. As I understood Apache OpenOffice is also in need of such a certificate and their product is not aiming at expert users too. Upayavira: if there is anything we can do to help with this issue, we gladly do it. From this issue I could not understand what I can do to help. Sometimes we just need some help from the Infra team as they can tell us if it can work, how it works and if we can help with anything. This is one of these cases.
          Hide
          Scott Deboy added a comment -
          I have provided input on Chainsaw's needs on the related Infra mailing list thread entitled 'Official code signing certificate'. Chainsaw provides a straightforward Java build with support in the build script for code signing.

          The responsibility for defining the process should lie with Infra, with input from the PMCs who need to use the service (assuming Infra is signing binaries), as Infra must be able to audit and control the conditions under which the binaries were produced, as stated by Sam Ruby in that mailing list thread.

          A few additional details from the related Infra mailing list thread:

          In June of 2012, Tony offered to review WRowe's suggestion of using Symantec's Code Signing service. Tony never followed up on the thread. I'm not sure if he ever reviewed the service.

          I was again hopeful when Mark Thomas offered to try out the Symantec service as well, asking for contact information. That was in August of this year, and that's the last comment on that thread.

          Show
          Scott Deboy added a comment - I have provided input on Chainsaw's needs on the related Infra mailing list thread entitled 'Official code signing certificate'. Chainsaw provides a straightforward Java build with support in the build script for code signing. The responsibility for defining the process should lie with Infra, with input from the PMCs who need to use the service (assuming Infra is signing binaries), as Infra must be able to audit and control the conditions under which the binaries were produced, as stated by Sam Ruby in that mailing list thread. A few additional details from the related Infra mailing list thread: In June of 2012, Tony offered to review WRowe's suggestion of using Symantec's Code Signing service. Tony never followed up on the thread. I'm not sure if he ever reviewed the service. I was again hopeful when Mark Thomas offered to try out the Symantec service as well, asking for contact information. That was in August of this year, and that's the last comment on that thread.
          Hide
          Upayavira added a comment -
          Scott,

          Flaming to me is speaking in ways that are likely to raise the heat in a discussion. Implying as you do that infra has been ignoring this issue for "over two years" is likely to do precisely that, whether you intend it or not.

          Clearly code signing is a complex issue, that has become larger than the resources available to each person who has attempted to take it on. The best any of us can do is attempt to understand those issues, and offer whatever support and help we can, rather than adding a form of criticism that is more likely to reduce enthusiasm for an already difficult task.

          Are you in a position to help move this issue forwards?
          Show
          Upayavira added a comment - Scott, Flaming to me is speaking in ways that are likely to raise the heat in a discussion. Implying as you do that infra has been ignoring this issue for "over two years" is likely to do precisely that, whether you intend it or not. Clearly code signing is a complex issue, that has become larger than the resources available to each person who has attempted to take it on. The best any of us can do is attempt to understand those issues, and offer whatever support and help we can, rather than adding a form of criticism that is more likely to reduce enthusiasm for an already difficult task. Are you in a position to help move this issue forwards?
          Hide
          Scott Deboy added a comment -
          I'm not flaming. I'm working to remind everyone that this is an important issue that has been ignored by Infra for over two years.

          I also want to clarify that you are incorrect in saying these are expert users. They are developers, of all shapes and sizes, and I can guarantee a number of the Chainsaw users simply aren't familiar with adjusting Java security/certificate trust settings. Inaction would be forcing them to figure out something they otherwise
          not have to.

          Bottom line: I reopened this issue precisely because the code signing Infra mailing list topic and the Wiki topic have had zero updates in the last six months.

          That's no longer acceptable, and I hope that by reopening this issue and pointing out the negative impact this is about to have on users will cause Infra to take the steps needed to prevent that.
          Show
          Scott Deboy added a comment - I'm not flaming. I'm working to remind everyone that this is an important issue that has been ignored by Infra for over two years. I also want to clarify that you are incorrect in saying these are expert users. They are developers, of all shapes and sizes, and I can guarantee a number of the Chainsaw users simply aren't familiar with adjusting Java security/certificate trust settings. Inaction would be forcing them to figure out something they otherwise not have to. Bottom line: I reopened this issue precisely because the code signing Infra mailing list topic and the Wiki topic have had zero updates in the last six months. That's no longer acceptable, and I hope that by reopening this issue and pointing out the negative impact this is about to have on users will cause Infra to take the steps needed to prevent that.
          Hide
          Ulrich Stärk added a comment -
          Instead of flaming here I suggest you go through the infra list archives on the issue of code signing and contribute something constructive there.

          And yes, I say it is acceptable for expert users to change their security settings until a permanent solution is available. You are targeting developers and IMO they can be expected to turn a little knob in order to run our software. Different story for end users.

          Uli
          Show
          Ulrich Stärk added a comment - Instead of flaming here I suggest you go through the infra list archives on the issue of code signing and contribute something constructive there. And yes, I say it is acceptable for expert users to change their security settings until a permanent solution is available. You are targeting developers and IMO they can be expected to turn a little knob in order to run our software. Different story for end users. Uli
          Hide
          Scott Deboy added a comment -
          Of course users can change the 'default', but by definition this means unless they take action, something that previously worked will no longer work. While this may be acceptable to Infra, and to you, this absolutely makes using Chainsaw more difficult for people who just want to try it out.

          Do we really want Apache applications to not run by 'default' on a system (or even warn users that certs are self-signed?)

          I hope you aren't suggesting it would be acceptable for Infra to continue to do nothing on this issue, or that it would be acceptable for users, who previously ran the application, to now have to figure out how to change cert signing permissions in order to run it, all because of Infra's inaction? That's absolutely not acceptable.
          Show
          Scott Deboy added a comment - Of course users can change the 'default', but by definition this means unless they take action, something that previously worked will no longer work. While this may be acceptable to Infra, and to you, this absolutely makes using Chainsaw more difficult for people who just want to try it out. Do we really want Apache applications to not run by 'default' on a system (or even warn users that certs are self-signed?) I hope you aren't suggesting it would be acceptable for Infra to continue to do nothing on this issue, or that it would be acceptable for users, who previously ran the application, to now have to figure out how to change cert signing permissions in order to run it, all because of Infra's inaction? That's absolutely not acceptable.
          Hide
          Ulrich Stärk added a comment -
          Scott, your information is wrong. Self-signed Webstarts will still run. What is going to be changed is that self-signed Applets and Web Starts will be blocked *by default* but this can be changed in the user's preferences. IMHO we can expect developers using our software to make that change. So yes, it is sub-optimal that we still don't have code-signing in place (for various reasons) but the upcoming Java update is not going to be a show-stopper.

          Uli
          Show
          Ulrich Stärk added a comment - Scott, your information is wrong. Self-signed Webstarts will still run. What is going to be changed is that self-signed Applets and Web Starts will be blocked *by default* but this can be changed in the user's preferences. IMHO we can expect developers using our software to make that change. So yes, it is sub-optimal that we still don't have code-signing in place (for various reasons) but the upcoming Java update is not going to be a show-stopper. Uli
          Scott Deboy made changes -
          Resolution Won't Fix [ 2 ]
          Status Closed [ 6 ] Reopened [ 4 ]
          Hide
          Scott Deboy added a comment - - edited
          Regarding the Java code signing cert…I thought if Infra didn't get things taken care of by the time we needed it, I would just self-sign the WebStart application…but it turns out Java 7u51 will disallow self-signed certs for WebStart-based apps - see https://blogs.oracle.com/java-platform-group/entry/new_security_requirements_for_rias

          This is now a time-sensitive issue…Java 7U51 will be out January 14..
          Show
          Scott Deboy added a comment - - edited Regarding the Java code signing cert…I thought if Infra didn't get things taken care of by the time we needed it, I would just self-sign the WebStart application…but it turns out Java 7u51 will disallow self-signed certs for WebStart-based apps - see https://blogs.oracle.com/java-platform-group/entry/new_security_requirements_for_rias This is now a time-sensitive issue…Java 7U51 will be out January 14..
          Hide
          Bertrand Delacretaz added a comment -
          See also http://wiki.apache.org/general/ASFCodeSigning which has a related discussion.
          Show
          Bertrand Delacretaz added a comment - See also http://wiki.apache.org/general/ASFCodeSigning which has a related discussion.
          Greg Stein made changes -
          Link This issue is blocked by LEGAL-174 [ LEGAL-174 ]
          Greg Stein made changes -
          Link This issue is blocked by LEGAL-174 [ LEGAL-174 ]
          Tony Stevenson made changes -
          Status Waiting for Infra [ 10011 ] Closed [ 6 ]
          Assignee Tony Stevenson [ pctony ]
          Resolution Won't Fix [ 2 ]
          Hide
          Tony Stevenson added a comment -
          Closing wont fix, for now. If you come up with a design that we can review and implement please feel free to open a new ticket with details.
          Show
          Tony Stevenson added a comment - Closing wont fix, for now. If you come up with a design that we can review and implement please feel free to open a new ticket with details.
          Tony Stevenson made changes -
          Status Open [ 1 ] Waiting for Infra [ 10011 ]
          Hide
          Tony Stevenson added a comment -
          Transitioning to waiting for Infra
          Show
          Tony Stevenson added a comment - Transitioning to waiting for Infra
          Tony Stevenson made changes -
          Field Original Value New Value
          Workflow jira [ 12636363 ] INFRA Workflow [ 12712242 ]
          Hide
          Sam Ruby added a comment -
          > maybe a jira issue with release candidate jars and pgp info, and signed jars could be added back to the same jira?

          I don't think that's going to be workable. If we are going to have a "official code signing cert provided by ASF itself. ", we need to be able to certify that the results are among other things, trojan and virus free. Not too difficult for source artifacts, but a bit more involved for binary artifacts.

          This will require a secure build infrastructure which is -- at a minimum -- fully audit-able by the infrastructure team. More likely it will require a secure build infrastructure which is /run/ by the infrastructure team.

          When the aoo ppmc requested something similar, the infrastructure team ask the aoo ppmc to do the work of designing how such would work. Once there are concrete plans, the infrastructure team can review them and decide what next steps (if any) are to be taken.
          Show
          Sam Ruby added a comment - > maybe a jira issue with release candidate jars and pgp info, and signed jars could be added back to the same jira? I don't think that's going to be workable. If we are going to have a "official code signing cert provided by ASF itself. ", we need to be able to certify that the results are among other things, trojan and virus free. Not too difficult for source artifacts, but a bit more involved for binary artifacts. This will require a secure build infrastructure which is -- at a minimum -- fully audit-able by the infrastructure team. More likely it will require a secure build infrastructure which is /run/ by the infrastructure team. When the aoo ppmc requested something similar, the infrastructure team ask the aoo ppmc to do the work of designing how such would work. Once there are concrete plans, the infrastructure team can review them and decide what next steps (if any) are to be taken.
          Hide
          Scott Deboy added a comment -
          I understand there are other groups also interested in support for code signing (OpenOffice for example).

          Conversations are happening on infrastructure-dev, but it would be great to have a response or status tracked in Jira. Mind using this issue for that?

          Thanks
          Show
          Scott Deboy added a comment - I understand there are other groups also interested in support for code signing (OpenOffice for example). Conversations are happening on infrastructure-dev, but it would be great to have a response or status tracked in Jira. Mind using this issue for that? Thanks
          Scott Deboy created issue -

            People

            • Assignee:
              Mark Thomas
              Reporter:
              Scott Deboy
            • Votes:
              9 Vote for this issue
              Watchers:
              32 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development