Details

    • Type: New Feature New Feature
    • Status: Waiting for Infra
    • Priority: Major Major
    • Resolution: Unresolved
    • Fix Version/s: None
    • Component/s: None
    • 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.

        Activity

        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
        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
        Tony Stevenson added a comment -
        Transitioning to waiting for Infra
        Show
        Tony Stevenson added a comment - Transitioning to waiting for Infra
        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.
        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.
        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
        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
        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 -
        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 -
        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
        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 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
        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
        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
        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.
        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 -
        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
        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 -
        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
        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
        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
        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
        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
        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.
        Hide
        #asfinfra IRC Bot added a comment -
        <pctony> Ack. When we get to a wider rollout we will keep you in mind. Thanks.
        Show
        #asfinfra IRC Bot added a comment - <pctony> Ack. When we get to a wider rollout we will keep you in mind. Thanks.

          People

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

            Dates

            • Created:
              Updated:

              Development