BTW now that we generate the instance configuration, we could create
fully secure configurations by default. For example we could generate
a broker with SSL enabled using a generated self signed cert. We
could also create a default admin users with a generated password etc.
On Thu, May 14, 2015 at 1:21 PM, Andy Taylor <andy.tayl...@gmail.com> wrote:
> On 14/05/15 17:11, Justin Bertram wrote:
>>>
>>> However, it is doubtful this is the way any broker will ever be run for
>>> real.
>>
>>
>> Yes, of course.
>>
>> As I see it, the default configuration is for users (mostly developers)
>> who want to start up a broker quickly, run a few examples, look at the
>> console, etc. All that would typically be done locally since that is the
>> simplest, fastest use-case. To move beyond that use-case (e.g. to one with
>> remote clients) hopefully the user would have reviewed a bit of the
>> documentation and come to understand more of how the broker works, the
>> importance of security, etc.
>>
>> I don't think it's common for users to unzip the broker and deploy to
>> production with no changes. IMO, the broker configuration is typically
>> tailored for the application and environment. Binding the network transports
>> to the proper interface is just part of that process.
>
> The security issue is a valid argument, but like you say if its not common
> for users to unzip and deploy into production then its actually a moot
> point.
>
> There are arguments to and for it but personally im happy to open the broker
> up to remote clients. Maybe we just improve the management functionality(and
> write) and only allow local clients for admin stuff.
>
>>
>>
>>> It's like having a web server start up without the ability to server web
>>> pages by default.
>>
>>
>> If the web server was 100% read-only then I'd probably be find with it
>> binding to a public interface by default. However, if there was any way for
>> remote users to impact my machine through that server (beyond a DOS attack)
>> then I would want the server to bind to localhost by default or be secured
>> with e.g. a username/password. That just seems like common sense to me.
>>
>> In short, I think we should take a pretty conservative approach with our
>> user's security. I think binding the server to 0.0.0.0 (i.e. all network
>> interfaces) by default with the current configuration is too liberal. If we
>> were to bind to 0.0.0.0 by default I'd want to either remove the default
>> user account altogether or change it so that the default user could only
>> consume messages (i.e. couldn't produce messages, create queues, or perform
>> management operations).
>>
>>
>> Justin
>>
>> ----- Original Message -----
>> From: "Jim Gomes" <e.se...@gmail.com>
>> To: "ActiveMQ Dev" <dev@activemq.apache.org>
>> Sent: Thursday, May 14, 2015 10:28:15 AM
>> Subject: Re: [VOTE] Apache Artemis 1.0.0 (RC2)
>>
>> If it was done on purpose for security reasons, that's cool. However, it
>> is
>> doubtful this is the way any broker will ever be run for real. The whole
>> purpose of a broker is to integrate disparate systems. It's like having a
>> web server start up without the ability to server web pages by default.
>> Kind of silly.
>>
>> Anyway, I will log the bug with the NMS clients, and I do think the
>> release
>> should be held up because of this problem. It's a show-stopper for NMS
>> clients. Here's the server exception being thrown:
>>
>> ERROR [org.apache.activemq.artemis.core.server] error decoding:
>> java.lang.IllegalStateException: Cannot handle command: ConsumerControl
>> {commandId = 0, responseRequired = false, consumerId =
>> ID:testmachine-58728-635671869132994591-1:0:44:1, close = false, stop =
>> false, start = false, flush = false, prefetch = 32766, destination =
>> topic://UnitTest.Status}
>> at
>>
>> org.apache.activemq.artemis.core.protocol.openwire.OpenWireProtocolManager.handleCommand(OpenWireProtocolManager.java:236)
>> [artemis-openwire-protocol-1.0.0.jar:1.0.0]
>> at
>>
>> org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection.bufferReceived(OpenWireConnection.java:315)
>> [artemis-openwire-protocol-1.0.0.jar:1.0.0]
>> at
>>
>> org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl$DelegatingBufferHandler.bufferReceived(RemotingServiceImpl.java:694)
>> [artemis-server-1.0.0.jar:1.0.0]
>> at
>>
>> org.apache.activemq.artemis.core.remoting.impl.netty.ActiveMQChannelHandler.channelRead(ActiveMQChannelHandler.java:73)
>> [artemis-core-client-1.0.0.jar:1.0.0]
>> at
>>
>> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:332)
>> [netty-all-4.0.20.Final.jar:4.0.20.Final]
>> at
>>
>> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:318)
>> [netty-all-4.0.20.Final.jar:4.0.20.Final]
>> at
>>
>> io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:787)
>> [netty-all-4.0.20.Final.jar:4.0.20.Final]
>> at
>>
>> io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:125)
>> [netty-all-4.0.20.Final.jar:4.0.20.Final]
>> at
>>
>> io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:507)
>> [netty-all-4.0.20.Final.jar:4.0.20.Final]
>> at
>>
>> io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:464)
>> [netty-all-4.0.20.Final.jar:4.0.20.Final]
>> at
>>
>> io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:378)
>> [netty-all-4.0.20.Final.jar:4.0.20.Final]
>> at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:350)
>> [netty-all-4.0.20.Final.jar:4.0.20.Final]
>> at
>>
>> io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:116)
>> [netty-all-4.0.20.Final.jar:4.0.20.Final]
>> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_20]
>>
>>
>>
>> On Thu, May 14, 2015 at 8:20 AM, Justin Bertram <jbert...@apache.com>
>> wrote:
>>
>>> IMO the broker correctly binds to localhost only and does not, by
>>> default,
>>> allow connections from remote machines. This is a simple security/sanity
>>> measure to prevent access to default (i.e. unsecured) instances.
>>>
>>> The merit of this configuration is obviously up for debate, but it's
>>> worth
>>> noting it was done on purpose.
>>>
>>>
>>> Justin
>>>
>>> ----- Original Message -----
>>> From: "Jim Gomes" <e.se...@gmail.com>
>>> To: "ActiveMQ Dev" <dev@activemq.apache.org>
>>> Sent: Thursday, May 14, 2015 10:05:55 AM
>>> Subject: Re: [VOTE] Apache Artemis 1.0.0 (RC2)
>>>
>>> -1
>>>
>>> Two reasons:
>>>
>>> 1. The default configuration of localhost for the broker does not allow
>>> connections from off-machine. For some reason, socket connections are
>>> refused from non-local clients. I had to change the broker.xml config to
>>> use the machine's actual IP address, and then non-local clients could
>>> connect.
>>> 2. The basic NMS OpenWire client fails to connect at all. It is getting
>>> unknown response IDs from the broker. I don't think the OpenWire protocol
>>> is being negotiated correctly. I am running with the latest NMS trunk
>>> version (1.8.0).
>>>
>>>
>>> On Wed, May 13, 2015 at 10:12 AM, Martyn Taylor <mtay...@redhat.com>
>>> wrote:
>>>
>>>> Hello all.
>>>>
>>>> I've cut a second release candidate of Apache Artemis 1.0.0 addressing
>>>
>>> the
>>>>
>>>> initial RC feedback from community members.
>>>>
>>>> This is a first release of the Artemis project with protocol support for
>>>> AMQP, STOMP, CORE, HORNETQ and OPENWIRE.
>>>>
>>>> The release notes can be found here:
>>>>
>>>>
>>>
>>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920&version=12328953
>>>>
>>>>
>>>> The binary distributions can be found here:
>>>>
>>>>
>>>
>>> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/org/apache/activemq/apache-artemis/1.0.0/
>>>>
>>>>
>>>> The source archives can be found here:
>>>>
>>>>
>>>
>>> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/org/apache/activemq/apache-artemis/1.0.0/
>>>>
>>>>
>>>> The Maven repository is here:
>>>>
>>>
>>> https://repository.apache.org/content/repositories/orgapacheactivemq-1051/
>>>>
>>>>
>>>> The source tag:
>>>>
>>>>
>>>
>>> https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;a=tag;h=refs/tags/1.0.0
>>>>
>>>>
>>>> The project website for that version has been staged to:
>>>> http://people.apache.org/~martyntaylor/
>>>>
>>>> The vote will remain open for 72 hours.
>>>>
>>>> [ ] +1 approve the release as Apache Artemis 1.0.0
>>>> [ ] +0 no opinion
>>>> [ ] -1 disapprove (and reason why)
>>>>
>>>> Here's my (non-binding) +1
>>>>
>>>> Regards
>>>> Martyn
>>>>
>>>
>
--
Hiram Chirino
Engineering | Red Hat, Inc.
hchir...@redhat.com | fusesource.com | redhat.com
skype: hiramchirino | twitter: @hiramchirino
