I'd be happy either way.
On 14 May 2015 20:00, "Justin Bertram" <jbert...@apache.com> wrote:
> > why don't we just add a flag --secure or something similar and document
> it.
>
> I'm fine with a flag, but I'd advocate using --unsecure and having a
> secure configuration by default. Then it's up to the user to decide which
> they want.
>
>
> Justin
>
> ----- Original Message -----
> From: "Andy Taylor" <andy.tayl...@gmail.com>
> To: dev@activemq.apache.org
> Sent: Thursday, May 14, 2015 1:18:15 PM
> Subject: Re: [VOTE] Apache Artemis 1.0.0 (RC2)
>
> If its not 100% air tight then there are still vulnerabilities. I think
> something useful out of the box is better.
>
> Since the user now has to create an instance befote tunning tbw broker,
> why don't we just add a flag --secure or something similar and document it.
> Then it's up to the user to decide which they want.
> On 14 May 2015 19:08, "Justin Bertram" <jbert...@apache.com> wrote:
>
> > > 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.
> >
> > "Production" systems are not the only systems on which security is
> > important. Consider a casual user who starts the broker just to play
> > around with it and then forgets to turn it off. Now that unsuspecting
> user
> > has an additional attack vector on their machine. Oftentimes black-hats
> > will compromise a "lesser" (i.e. non production) system in order to get
> to
> > the real target.
> >
> > I'm not trying to be some kind of security alarmist or saying our
> > distribution has to be 100% air-tight. All I'm saying is that the
> default
> > configuration should be conservative from a security/access
> stand-point. I
> > don't think it's acceptable that if I start the broker then anybody who
> can
> > connect to my machine remotely now has the ability to start filling up my
> > disk with messages. If the consensus is to bind to public network
> > interfaces by default then we should likewise modify the configuration to
> > be read-only by default at the very least.
> >
> >
> > Justin
> >
> > ----- Original Message -----
> > From: "Andy Taylor" <andy.tayl...@gmail.com>
> > To: dev@activemq.apache.org
> > Sent: Thursday, May 14, 2015 12:21:24 PM
> > Subject: Re: [VOTE] Apache Artemis 1.0.0 (RC2)
> >
> > 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
> > >>>
> > >>
> >
>
