Re: [Signing] New component for code signing

[Benedikt Ritter]

Hello Mark,

+1 In my opinion this is exactly what Commons should be doing.

Regards,
Benedikt

Mark Thomas  schrieb am Di., 23. Jan. 2018 um 07:34 Uhr:

> All,
>
> As you may know, the ASF has been using a code signing service for a
> number of years provided by Symantec. We use it to sign Commons Daemon
> Windows binaries.
>
> The code signing service has a web based GUI and a SOAP based API.
> Tomcat has written an Ant task to use the SOAP API and Sling has taken
> this used and used it as the basis for a Maven plug-in.
>
> Currently, the Ant task is hosted within the Tomcat codebase and the
> Maven plug-in within Sling. Both communities would like to move this to
> a better home where it can more easily be re-used by other Apache
> projects and other organisations using Symantec's code signing service.
>
> After some thought and discussion, we (Robert Munteanu and I) would like
> to propose this code signing component as a new component at Commons.
> Our reasons for this are as follows:
>
> - The code is written in Java
> - It is a relatively small component
> - It is a utility likely to be of interest to multiple Apache projects
> - If it is going to be re-used across multiple projects, it needs to be
>   formally released and that requires a PMC
>
> If accepted the plan would be:
> - commit the original Tomcat code for the Ant task
> - refactor it to allow re-use of code common to the Ant task and Maven
>   plug-in
> - add the Maven plug-in
> - release it as a single JAR that provided both the Ant task and the
>   Maven plug-in
> - Ongoing review and maintenance (there are a couple of areas that could
>   benefit from some improvement)
>
> Thoughts? Comments?
>
> Mark
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [RNG][All] Benign incompatibility (?)

[Gilles]

Ping?

More opinions, please (to avoid rehashing the issue at
vote time).

Thanks,
Gilles

On Mon, 15 Jan 2018 22:14:03 +0100, Gilles wrote:

On Mon, 15 Jan 2018 09:49:44 -0700, Gary Gregory wrote:

Hi All,

There are some many ways this can create jar hell now and in the 
future
that I would not want to risk it. Binary compatibility is something 
we
should strive for IMO. If this change is _that_ important, then it's 
2.0
time. Otherwise, don't break application stacks. Especially since 
Commons
components tend to live at the bottom of such stacks. I see plenty 
of
stacks out there for example, that include _both_ [lang] and 
[lang3], and

that is _fine_.


The point is that no correct application can be broken by this 
change.

Rather the contrary, with the prospective v1.1, failure will happen
at compile time (for incorrect application code that would have tried
to call base class methods), while v1.0 will happily compile (and 
then

raise a NPE).
Furthermore, in both cases, correct usage (i.e. calling the "sample"
method) will work the same, and as expected; no JAR hell whatsoever.

The incompatible change is actually an improvement from a application
developer's POV.

Gilles



Gary

On Mon, Jan 15, 2018 at 5:13 AM, Gilles 


wrote:


Hi.

Please have a look at this issue on JIRA:
  https://issues.apache.org/jira/browse/RNG-46
and confirm that a release won't be blocked by the
current "clirr" report.

Thanks,
Gilles



-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [RNG][All] Benign incompatibility (?)

[Oliver Heger]

Am 24.01.2018 um 14:29 schrieb Gilles:
> Ping?
> 
> More opinions, please (to avoid rehashing the issue at
> vote time).
> 
> Thanks,
> Gilles
> 
> On Mon, 15 Jan 2018 22:14:03 +0100, Gilles wrote:
>> On Mon, 15 Jan 2018 09:49:44 -0700, Gary Gregory wrote:
>>> Hi All,
>>>
>>> There are some many ways this can create jar hell now and in the future
>>> that I would not want to risk it. Binary compatibility is something we
>>> should strive for IMO. If this change is _that_ important, then it's 2.0
>>> time. Otherwise, don't break application stacks. Especially since
>>> Commons
>>> components tend to live at the bottom of such stacks. I see plenty of
>>> stacks out there for example, that include _both_ [lang] and [lang3],
>>> and
>>> that is _fine_.
>>
>> The point is that no correct application can be broken by this change.
>> Rather the contrary, with the prospective v1.1, failure will happen
>> at compile time (for incorrect application code that would have tried
>> to call base class methods), while v1.0 will happily compile (and then
>> raise a NPE).
>> Furthermore, in both cases, correct usage (i.e. calling the "sample"
>> method) will work the same, and as expected; no JAR hell whatsoever.
>>
>> The incompatible change is actually an improvement from a application
>> developer's POV.

A Clirr violation would be fine with me if it is addressed in the
release notes, and the probability of creating a jar hell scenario is
rather low.

Oliver


>>
>> Gilles
>>
>>>
>>> Gary
>>>
>>> On Mon, Jan 15, 2018 at 5:13 AM, Gilles 
>>> wrote:
>>>
 Hi.

 Please have a look at this issue on JIRA:
   https://issues.apache.org/jira/browse/RNG-46
 and confirm that a release won't be blocked by the
 current "clirr" report.

 Thanks,
 Gilles
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
> 

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [Signing] New component for code signing

[Gary Gregory]

+1

Gary

On Wed, Jan 24, 2018 at 1:35 AM, Benedikt Ritter  wrote:

> Hello Mark,
>
> +1 In my opinion this is exactly what Commons should be doing.
>
> Regards,
> Benedikt
>
> Mark Thomas  schrieb am Di., 23. Jan. 2018 um 07:34 Uhr:
>
> > All,
> >
> > As you may know, the ASF has been using a code signing service for a
> > number of years provided by Symantec. We use it to sign Commons Daemon
> > Windows binaries.
> >
> > The code signing service has a web based GUI and a SOAP based API.
> > Tomcat has written an Ant task to use the SOAP API and Sling has taken
> > this used and used it as the basis for a Maven plug-in.
> >
> > Currently, the Ant task is hosted within the Tomcat codebase and the
> > Maven plug-in within Sling. Both communities would like to move this to
> > a better home where it can more easily be re-used by other Apache
> > projects and other organisations using Symantec's code signing service.
> >
> > After some thought and discussion, we (Robert Munteanu and I) would like
> > to propose this code signing component as a new component at Commons.
> > Our reasons for this are as follows:
> >
> > - The code is written in Java
> > - It is a relatively small component
> > - It is a utility likely to be of interest to multiple Apache projects
> > - If it is going to be re-used across multiple projects, it needs to be
> >   formally released and that requires a PMC
> >
> > If accepted the plan would be:
> > - commit the original Tomcat code for the Ant task
> > - refactor it to allow re-use of code common to the Ant task and Maven
> >   plug-in
> > - add the Maven plug-in
> > - release it as a single JAR that provided both the Ant task and the
> >   Maven plug-in
> > - Ongoing review and maintenance (there are a couple of areas that could
> >   benefit from some improvement)
> >
> > Thoughts? Comments?
> >
> > Mark
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> >
>

Re: [Signing] New component for code signing

[Bernd Eckenfels]

+1  - and I would expect we also see a Server-side component.

BTW: Eclipse also has some infrastructure for this (we use a modified Version 
with a PHP backend on-prem)

http://git.eclipse.org/c/cbi/org.eclipse.cbi.git/tree/maven-plugins/README.md

Gruss
Bernd
-- 
http://bernd.eckenfels.net

Von: Gary Gregory
Gesendet: Mittwoch, 24. Januar 2018 22:05
An: Commons Developers List
Betreff: Re: [Signing] New component for code signing

+1

Gary

On Wed, Jan 24, 2018 at 1:35 AM, Benedikt Ritter  wrote:

> Hello Mark,
>
> +1 In my opinion this is exactly what Commons should be doing.
>
> Regards,
> Benedikt
>
> Mark Thomas  schrieb am Di., 23. Jan. 2018 um 07:34 Uhr:
>
> > All,
> >
> > As you may know, the ASF has been using a code signing service for a
> > number of years provided by Symantec. We use it to sign Commons Daemon
> > Windows binaries.
> >
> > The code signing service has a web based GUI and a SOAP based API.
> > Tomcat has written an Ant task to use the SOAP API and Sling has taken
> > this used and used it as the basis for a Maven plug-in.
> >
> > Currently, the Ant task is hosted within the Tomcat codebase and the
> > Maven plug-in within Sling. Both communities would like to move this to
> > a better home where it can more easily be re-used by other Apache
> > projects and other organisations using Symantec's code signing service.
> >
> > After some thought and discussion, we (Robert Munteanu and I) would like
> > to propose this code signing component as a new component at Commons.
> > Our reasons for this are as follows:
> >
> > - The code is written in Java
> > - It is a relatively small component
> > - It is a utility likely to be of interest to multiple Apache projects
> > - If it is going to be re-used across multiple projects, it needs to be
> >   formally released and that requires a PMC
> >
> > If accepted the plan would be:
> > - commit the original Tomcat code for the Ant task
> > - refactor it to allow re-use of code common to the Ant task and Maven
> >   plug-in
> > - add the Maven plug-in
> > - release it as a single JAR that provided both the Ant task and the
> >   Maven plug-in
> > - Ongoing review and maintenance (there are a couple of areas that could
> >   benefit from some improvement)
> >
> > Thoughts? Comments?
> >
> > Mark
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> >
>

Re: [Signing] New component for code signing

[Hasan Diwan]

+1

On 22 January 2018 at 22:33, Mark Thomas  wrote:

> All,
>
> As you may know, the ASF has been using a code signing service for a
> number of years provided by Symantec. We use it to sign Commons Daemon
> Windows binaries.
>
> The code signing service has a web based GUI and a SOAP based API.
> Tomcat has written an Ant task to use the SOAP API and Sling has taken
> this used and used it as the basis for a Maven plug-in.
>
> Currently, the Ant task is hosted within the Tomcat codebase and the
> Maven plug-in within Sling. Both communities would like to move this to
> a better home where it can more easily be re-used by other Apache
> projects and other organisations using Symantec's code signing service.
>
> After some thought and discussion, we (Robert Munteanu and I) would like
> to propose this code signing component as a new component at Commons.
> Our reasons for this are as follows:
>
> - The code is written in Java
> - It is a relatively small component
> - It is a utility likely to be of interest to multiple Apache projects
> - If it is going to be re-used across multiple projects, it needs to be
>   formally released and that requires a PMC
>
> If accepted the plan would be:
> - commit the original Tomcat code for the Ant task
> - refactor it to allow re-use of code common to the Ant task and Maven
>   plug-in
> - add the Maven plug-in
> - release it as a single JAR that provided both the Ant task and the
>   Maven plug-in
> - Ongoing review and maintenance (there are a couple of areas that could
>   benefit from some improvement)
>
> Thoughts? Comments?
>
> Mark
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>


-- 
OpenPGP:
https://sks-keyservers.net/pks/lookup?op=get&search=0xFEBAD7FFD041BBA1
If you wish to request my time, please do so using
http://bit.ly/hd1ScheduleRequest.
Si vous voudrais faire connnaisance, allez a
http://bit.ly/hd1ScheduleRequest.

Sent
from my mobile device
Envoye de mon portable

Re: [Signing] New component for code signing

[Matt Sicker]

+1 (non-binding)

I'd find such a plugin useful for Apache Chainsaw in the future. Any other
Java GUI apps at Apache could benefit as well.

On 24 January 2018 at 17:19, Hasan Diwan  wrote:

> +1
>
> On 22 January 2018 at 22:33, Mark Thomas  wrote:
>
> > All,
> >
> > As you may know, the ASF has been using a code signing service for a
> > number of years provided by Symantec. We use it to sign Commons Daemon
> > Windows binaries.
> >
> > The code signing service has a web based GUI and a SOAP based API.
> > Tomcat has written an Ant task to use the SOAP API and Sling has taken
> > this used and used it as the basis for a Maven plug-in.
> >
> > Currently, the Ant task is hosted within the Tomcat codebase and the
> > Maven plug-in within Sling. Both communities would like to move this to
> > a better home where it can more easily be re-used by other Apache
> > projects and other organisations using Symantec's code signing service.
> >
> > After some thought and discussion, we (Robert Munteanu and I) would like
> > to propose this code signing component as a new component at Commons.
> > Our reasons for this are as follows:
> >
> > - The code is written in Java
> > - It is a relatively small component
> > - It is a utility likely to be of interest to multiple Apache projects
> > - If it is going to be re-used across multiple projects, it needs to be
> >   formally released and that requires a PMC
> >
> > If accepted the plan would be:
> > - commit the original Tomcat code for the Ant task
> > - refactor it to allow re-use of code common to the Ant task and Maven
> >   plug-in
> > - add the Maven plug-in
> > - release it as a single JAR that provided both the Ant task and the
> >   Maven plug-in
> > - Ongoing review and maintenance (there are a couple of areas that could
> >   benefit from some improvement)
> >
> > Thoughts? Comments?
> >
> > Mark
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> >
>
>
> --
> OpenPGP:
> https://sks-keyservers.net/pks/lookup?op=get&search=0xFEBAD7FFD041BBA1
> If you wish to request my time, please do so using
> http://bit.ly/hd1ScheduleRequest.
> Si vous voudrais faire connnaisance, allez a
> http://bit.ly/hd1ScheduleRequest.
>
>  >Sent
> from my mobile device
> Envoye de mon portable
>



-- 
Matt Sicker 

Re: [Signing] New component for code signing

[Rob Tompkins]

+1

> On Jan 24, 2018, at 4:05 PM, Gary Gregory  wrote:
> 
> +1
> 
> Gary
> 
>> On Wed, Jan 24, 2018 at 1:35 AM, Benedikt Ritter  wrote:
>> 
>> Hello Mark,
>> 
>> +1 In my opinion this is exactly what Commons should be doing.
>> 
>> Regards,
>> Benedikt
>> 
>> Mark Thomas  schrieb am Di., 23. Jan. 2018 um 07:34 Uhr:
>> 
>>> All,
>>> 
>>> As you may know, the ASF has been using a code signing service for a
>>> number of years provided by Symantec. We use it to sign Commons Daemon
>>> Windows binaries.
>>> 
>>> The code signing service has a web based GUI and a SOAP based API.
>>> Tomcat has written an Ant task to use the SOAP API and Sling has taken
>>> this used and used it as the basis for a Maven plug-in.
>>> 
>>> Currently, the Ant task is hosted within the Tomcat codebase and the
>>> Maven plug-in within Sling. Both communities would like to move this to
>>> a better home where it can more easily be re-used by other Apache
>>> projects and other organisations using Symantec's code signing service.
>>> 
>>> After some thought and discussion, we (Robert Munteanu and I) would like
>>> to propose this code signing component as a new component at Commons.
>>> Our reasons for this are as follows:
>>> 
>>> - The code is written in Java
>>> - It is a relatively small component
>>> - It is a utility likely to be of interest to multiple Apache projects
>>> - If it is going to be re-used across multiple projects, it needs to be
>>>  formally released and that requires a PMC
>>> 
>>> If accepted the plan would be:
>>> - commit the original Tomcat code for the Ant task
>>> - refactor it to allow re-use of code common to the Ant task and Maven
>>>  plug-in
>>> - add the Maven plug-in
>>> - release it as a single JAR that provided both the Ant task and the
>>>  Maven plug-in
>>> - Ongoing review and maintenance (there are a couple of areas that could
>>>  benefit from some improvement)
>>> 
>>> Thoughts? Comments?
>>> 
>>> Mark
>>> 
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>> 
>>> 
>> 

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org