You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@qpid.apache.org by Adel Boutros <Ad...@live.com> on 2017/03/29 19:17:23 UTC
[Java Broker - 6.0.4] Dojo toolkit dependency
Hello,
While our legal team was reviewing the Broker's packaged dependencies and their licenses, they had some questions regarding Dojo toolkit materials which I hope you can help me with:
* Could you please list all cryptographic means contained in the dojo materials used?
* Could you please describe:
1) the purpose(s) for which the dojo materials use these cryptographic means
2) whether these means will be accessible to end users
* Why is this dependency needed and could we omit it from distribution?
Regards,
Adel
Re: [Java Broker - 6.0.4] Dojo toolkit dependency
Posted by Adel Boutros <Ad...@live.com>.
Thank you Keith for the valuable information.
Indeed, we have developed a Java API to manage the Broker via REST (Using Sprint Rest Template). However for now, we have been using unsecured channels for it.
Regards,
Adel
________________________________
From: Keith W <ke...@gmail.com>
Sent: Thursday, March 30, 2017 10:22:28 AM
To: users@qpid.apache.org
Subject: Re: [Java Broker - 6.0.4] Dojo toolkit dependency
On 30 March 2017 at 08:49, Adel Boutros <Ad...@live.com> wrote:
> Thank you Rob,
>
>
> Actually, we were wondering about the "dojo-1.10.3-distribution.zip" available under the lib directory of the downloaded broker zip. So from your answers, you only use it in the web console.
>
>
Yes - this is correct. It is used only by the web management console.
> One last question, what happens if we delete this dependency? Could we still contact the broker via REST using SSL/SASL to manage queues, exchanges, etc?
You'll see 404 errors if you attempt to use the Web Management Console
but no harm is caused.
The REST API, the Broker's ability to offer TLS (aka. SSL) and to
offer SASL based authentication are all unaffected.
Incidentally, if you are making programmatic use of the REST API, we
recommend that you make use of preemptive authentication over a secure
channel (that is. present an Authorization: header on your programatic
HTTP request). The will give you a simpler application which makes
fewer network interactions. You can do this from the command line
using cURL (https://curl.haxx.se/docs/manpage.html#-u)
>
>
> Regards,
>
> Adel
>
> ________________________________
> From: Rob Godfrey <ro...@gmail.com>
> Sent: Wednesday, March 29, 2017 11:38:30 PM
> To: users@qpid.apache.org
> Subject: Re: [Java Broker - 6.0.4] Dojo toolkit dependency
>
> Are you talking dojo itself, or the fact that the http-management plugin
> also notes that it "This bundles portions of crypto-js, which is under the
> MIT licence".
>
> The only "cryptographic functions" used within the web console are those
> necessary to implement the necessary SASL authentication mechanisms. In
> particular SHA-1, SHA-256 (and for historical reasons MD5) hashing. There
> is no encryption used within the console (other than TLS through the
> standard browser mechanism). The use of crypto-js code was because dojo
> didn't have an implementation of the necessary HMAC mechanisms for SHA-1 /
> SHA-256 if I remember correctly. (See https://tools.ietf.org/html/rfc5802
> and https://tools.ietf.org/html/rfc7677 for details of the SCRAM-SHA* SASL
> mechanisms).
>
> Hope this helps,
> Rob
>
>
>
> On 29 March 2017 at 21:17, Adel Boutros <Ad...@live.com> wrote:
>
>> Hello,
>>
>>
>> While our legal team was reviewing the Broker's packaged dependencies and
>> their licenses, they had some questions regarding Dojo toolkit materials
>> which I hope you can help me with:
>>
>>
>> * Could you please list all cryptographic means contained in the dojo
>> materials used?
>>
>>
>> * Could you please describe:
>>
>> 1) the purpose(s) for which the dojo materials use these cryptographic
>> means
>>
>> 2) whether these means will be accessible to end users
>>
>>
>> * Why is this dependency needed and could we omit it from distribution?
>>
>>
>> Regards,
>>
>> Adel
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: [Java Broker - 6.0.4] Dojo toolkit dependency
Posted by Keith W <ke...@gmail.com>.
On 30 March 2017 at 08:49, Adel Boutros <Ad...@live.com> wrote:
> Thank you Rob,
>
>
> Actually, we were wondering about the "dojo-1.10.3-distribution.zip" available under the lib directory of the downloaded broker zip. So from your answers, you only use it in the web console.
>
>
Yes - this is correct. It is used only by the web management console.
> One last question, what happens if we delete this dependency? Could we still contact the broker via REST using SSL/SASL to manage queues, exchanges, etc?
You'll see 404 errors if you attempt to use the Web Management Console
but no harm is caused.
The REST API, the Broker's ability to offer TLS (aka. SSL) and to
offer SASL based authentication are all unaffected.
Incidentally, if you are making programmatic use of the REST API, we
recommend that you make use of preemptive authentication over a secure
channel (that is. present an Authorization: header on your programatic
HTTP request). The will give you a simpler application which makes
fewer network interactions. You can do this from the command line
using cURL (https://curl.haxx.se/docs/manpage.html#-u)
>
>
> Regards,
>
> Adel
>
> ________________________________
> From: Rob Godfrey <ro...@gmail.com>
> Sent: Wednesday, March 29, 2017 11:38:30 PM
> To: users@qpid.apache.org
> Subject: Re: [Java Broker - 6.0.4] Dojo toolkit dependency
>
> Are you talking dojo itself, or the fact that the http-management plugin
> also notes that it "This bundles portions of crypto-js, which is under the
> MIT licence".
>
> The only "cryptographic functions" used within the web console are those
> necessary to implement the necessary SASL authentication mechanisms. In
> particular SHA-1, SHA-256 (and for historical reasons MD5) hashing. There
> is no encryption used within the console (other than TLS through the
> standard browser mechanism). The use of crypto-js code was because dojo
> didn't have an implementation of the necessary HMAC mechanisms for SHA-1 /
> SHA-256 if I remember correctly. (See https://tools.ietf.org/html/rfc5802
> and https://tools.ietf.org/html/rfc7677 for details of the SCRAM-SHA* SASL
> mechanisms).
>
> Hope this helps,
> Rob
>
>
>
> On 29 March 2017 at 21:17, Adel Boutros <Ad...@live.com> wrote:
>
>> Hello,
>>
>>
>> While our legal team was reviewing the Broker's packaged dependencies and
>> their licenses, they had some questions regarding Dojo toolkit materials
>> which I hope you can help me with:
>>
>>
>> * Could you please list all cryptographic means contained in the dojo
>> materials used?
>>
>>
>> * Could you please describe:
>>
>> 1) the purpose(s) for which the dojo materials use these cryptographic
>> means
>>
>> 2) whether these means will be accessible to end users
>>
>>
>> * Why is this dependency needed and could we omit it from distribution?
>>
>>
>> Regards,
>>
>> Adel
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: [Java Broker - 6.0.4] Dojo toolkit dependency
Posted by Adel Boutros <Ad...@live.com>.
Thank you Rob,
Actually, we were wondering about the "dojo-1.10.3-distribution.zip" available under the lib directory of the downloaded broker zip. So from your answers, you only use it in the web console.
One last question, what happens if we delete this dependency? Could we still contact the broker via REST using SSL/SASL to manage queues, exchanges, etc?
Regards,
Adel
________________________________
From: Rob Godfrey <ro...@gmail.com>
Sent: Wednesday, March 29, 2017 11:38:30 PM
To: users@qpid.apache.org
Subject: Re: [Java Broker - 6.0.4] Dojo toolkit dependency
Are you talking dojo itself, or the fact that the http-management plugin
also notes that it "This bundles portions of crypto-js, which is under the
MIT licence".
The only "cryptographic functions" used within the web console are those
necessary to implement the necessary SASL authentication mechanisms. In
particular SHA-1, SHA-256 (and for historical reasons MD5) hashing. There
is no encryption used within the console (other than TLS through the
standard browser mechanism). The use of crypto-js code was because dojo
didn't have an implementation of the necessary HMAC mechanisms for SHA-1 /
SHA-256 if I remember correctly. (See https://tools.ietf.org/html/rfc5802
and https://tools.ietf.org/html/rfc7677 for details of the SCRAM-SHA* SASL
mechanisms).
Hope this helps,
Rob
On 29 March 2017 at 21:17, Adel Boutros <Ad...@live.com> wrote:
> Hello,
>
>
> While our legal team was reviewing the Broker's packaged dependencies and
> their licenses, they had some questions regarding Dojo toolkit materials
> which I hope you can help me with:
>
>
> * Could you please list all cryptographic means contained in the dojo
> materials used?
>
>
> * Could you please describe:
>
> 1) the purpose(s) for which the dojo materials use these cryptographic
> means
>
> 2) whether these means will be accessible to end users
>
>
> * Why is this dependency needed and could we omit it from distribution?
>
>
> Regards,
>
> Adel
>
Re: [Java Broker - 6.0.4] Dojo toolkit dependency
Posted by Rob Godfrey <ro...@gmail.com>.
Are you talking dojo itself, or the fact that the http-management plugin
also notes that it "This bundles portions of crypto-js, which is under the
MIT licence".
The only "cryptographic functions" used within the web console are those
necessary to implement the necessary SASL authentication mechanisms. In
particular SHA-1, SHA-256 (and for historical reasons MD5) hashing. There
is no encryption used within the console (other than TLS through the
standard browser mechanism). The use of crypto-js code was because dojo
didn't have an implementation of the necessary HMAC mechanisms for SHA-1 /
SHA-256 if I remember correctly. (See https://tools.ietf.org/html/rfc5802
and https://tools.ietf.org/html/rfc7677 for details of the SCRAM-SHA* SASL
mechanisms).
Hope this helps,
Rob
On 29 March 2017 at 21:17, Adel Boutros <Ad...@live.com> wrote:
> Hello,
>
>
> While our legal team was reviewing the Broker's packaged dependencies and
> their licenses, they had some questions regarding Dojo toolkit materials
> which I hope you can help me with:
>
>
> * Could you please list all cryptographic means contained in the dojo
> materials used?
>
>
> * Could you please describe:
>
> 1) the purpose(s) for which the dojo materials use these cryptographic
> means
>
> 2) whether these means will be accessible to end users
>
>
> * Why is this dependency needed and could we omit it from distribution?
>
>
> Regards,
>
> Adel
>