PyPi packages: qpid-tools and qpid-python (both are now 1.36.0-1)

2017-07-26 Thread Irina Boverman 
Updated to include missing .bat files.
--
Regards, Irina.

Re: Dispatch Router questions

2017-07-26 Thread Ted Ross 
On Fri, Jul 21, 2017 at 7:12 PM, Dan Langford  wrote:

> On Thu, Jul 20, 2017 at 9:58 AM Ted Ross  wrote:
>
> > On Wed, Jul 19, 2017 at 7:36 PM, Dan Langford 
> > wrote:
> >
> > > > - Can I configure QDR to autoLink in and out ANY/ALL addresses?
> > > No.  There is no way currently for QDR to know what queues are present
> on
> > > its connected brokers.  It would not be difficult to write a program to
> > > synchronize autolinks to existing queues.
> >
>
> You are right it wouldn't be that difficult. Also with artemis I can turn
> on autocreation of queues and then then use QDR as the spot to manage what
> queues can exist. Not bad. What about synchronizing autoLink config across
> routers in a QDR network? are messages to the $management queue broadcast
> throughout the cluster? i could always resend the necessary messages
> through the _topo address namespace to get it to the other routers.
>
>
> > > > - Artemis doesn't support vhosts. Can I configure connections to
> > vhost:Foo
> > > > address:bar actually be address:Foo.bar when the message goes back to
> > the
> > > > broker?
> > > Yes.  There is a multi-tenancy feature for listeners that does exactly
> > what
> > > you are asking for.  If you add the attribute "multiTenant: yes" to the
> > > configuration of a listener in the qdrouterd.conf file, clients
> connected
> > > via that listener will have their addresses annotated as vhost/addr in
> > the
> > > router.
> >
>
> ok this is going to be perfect.  i am starting to feel more comfortable
> with everything in this config file
>
> > > - Can I configure QDR to pass auth through to the broker and let the
> > broker
> > > > decide is the user is authenticated and authorized? Inversely can I
> > > > configure QDR to be the only determinate of auth?
> > > Presently, QDR expects to be the sole determiner of authentic identity.
>
> > There is an open request to add a SASL proxy that might be used to allow
> > > the broker to do authentication on behalf of the router, but that
> hasn't
> > > made it into master yet.
> >
>
> this is one part that has me a little stuck. QDR is the sole determiner of
> auth identity. but QDR delegates to a cyrus sasl config right? and cyrus
> sasl has some local DB options or sql or ldap or it can delegate to
> kerberos or pam and i am just starting to feel a little lost in all my auth
> option because its been a long time since i have been through all that. i
> will figure it out well enough. i kind of wish there was a way i could send
> a message in through $management to add a new user/pass to the sasldb but
> ill figure something out.
>
> also, in regards to auth where is it that i specify what users have access
> to what addresses? it looks like that might be in the config in
> vhost>groups but then i see a policy area of the config. ill start in the
> vhost>groups area and see how far i get
>
>
> > > > I think depending on what I learn on these topics I will likely have
> > more
> > > > questions. Thank you to anybody who is able to give me a lead or
> point
> > me
> > > > to a config that may serve as an example. I really do appreciate it.
> > > Please don't hesitate to ask more questions or point out where there is
> > > lack of documentation.  We appreciate it as well.
> >
>
> so i had another question come up in my research today. i have a single F5
> BIG IP VIP that sits in front of all my VMs that are across two different
> geographic locations. due to the two locations i want, well, two of
> everything in a way that i can use all the resources at my disposal but
> still function if one location goes offline. So here are (R)outers and
> (B)rokers in locations (a) and (b)
>
> in order for me to be able to produce messages into Ba and Bb i found that
> each one of my Routers needed a connection to each one of my Brokers.
>
> Essentially:
> Ra --> Ba
> Ra --> Bb
> Rb --> Ba
> Rb --> Bb
>
> Graphically:
> Ra --- Ba
>\ /
>/ \
> Ra --- Bb
>
> it was really cool that i could send messages to Ra and see them fill up
> both Ba and Bb. Receiving across both brokers also worked. But i was hoping
> for more of a configuration where the Routers where only connected to a
> single Broker and all the Routers knew about each other.
>
> Essentially:
> Ra --> Ba
> Rb --> Bb
> Ra <-> Rb
>
> Graphically:
> Ra --- Ba
> ||
> ||
> Ra --- Bb
>
> but in this configuration messages sent to Ra only got routed to Ba and
> when i made a consumer on Ra i could only get messages off of Ba. Do you
> know what someone would need to do in the configuration to support this?
>  or is this architecture not ideal? the next thing i was going to try was
> to make the Cost of Ra --> Ba = 2 so that it was equal to the Cost of Ra
> --> Rb --> Bb and then maybe they would be considered as equal routes and
> messages would balance between them. i dont think this explains why i
> couldnt consume from both.  ill work on that tomorrow

Re: Docker image for qpid-cpp broker

2017-07-26 Thread Irina Boverman 
Correction: Fedora 26 is latest.

On Wed, Jul 26, 2017 at 11:53 AM, Irina Boverman 
wrote:

> I have created a docker image and posted it here:
>https://hub.docker.com/r/irinabov/docker-qpid-cpp/
>
> Source is here:
>https://github.com/irinabov/docker-qpid-cpp
> --
> Reviews, feedback and comments are welcome.
> This image is based on Fedora 25 and builds proton 0.17.0 and qpid-cpp
> 1.36.0 from apache git repo.
> --
> Regards, Irina.
>

Docker image for qpid-cpp broker

2017-07-26 Thread Irina Boverman 
I have created a docker image and posted it here:
   https://hub.docker.com/r/irinabov/docker-qpid-cpp/

Source is here:
   https://github.com/irinabov/docker-qpid-cpp
--
Reviews, feedback and comments are welcome.
This image is based on Fedora 25 and builds proton 0.17.0 and qpid-cpp
1.36.0 from apache git repo.
--
Regards, Irina.

Issue using different logging implementation

2017-07-26 Thread Feldkamp, Brandon 
Hello!

I’m having an issue starting up qpid due to conflicting loggers. Specifically, 
this explicit cast is throwing errors 
https://github.com/apache/qpid-broker-j/blob/6.1.x/broker/src/main/java/org/apache/qpid/server/Broker.java#L147-L148.
 Is there anyway to override this or bypass logging altogether?

Thanks,
Brandon



The information contained in this e-mail is confidential and/or proprietary to 
Capital One and/or its affiliates and may only be used solely in performance of 
work or services for Capital One. The information transmitted herewith is 
intended only for use by the individual or entity to which it is addressed. If 
the reader of this message is not the intended recipient, you are hereby 
notified that any review, retransmission, dissemination, distribution, copying 
or other use of, or taking of any action in reliance upon this information is 
strictly prohibited. If you have received this communication in error, please 
contact the sender and delete the material from your computer.

Re: SASL GSSAPI and MIN-MAX-FRAME-SIZE

2017-07-26 Thread Rob Godfrey 
On 26 July 2017 at 15:38, Robbie Gemmell  wrote:

> On 26 July 2017 at 14:09, Rob Godfrey  wrote:
> > On 26 July 2017 at 14:43, Robbie Gemmell 
> wrote:
> >
> >> That essentially summarises some discussion I had with others on this
> >> elsewhere late yesterday and was planning to see what you and others
> >> thought about it after having a look at the impls.
> >>
> >> I agree that making a custom mechanism for fragmenting an existing
> >> mechanisms content is ugly and probably of little value in the end
> >> since you would still need to handle the whole as you say. If the
> >> regular mechanism name was offered and it needs >512 byte in a given
> >> situation then it obviously wouldnt work if you enforce that limit..so
> >> either you couldnt expect it to work anyway, in which case why offer
> >> it, or presumably wouldnt enforce the limit. If servers dont offer
> >> such mechanism or clients dont select them, which many wont in this
> >> case, there isn't an issue for them.
> >>
> >> To allow proceeding despite the size, we would need to add a toggle to
> >> proton-j to control what it will allow to be received for sasl frames,
> >> or adjust the default size it will allow, or both. The simplest thing
> >> toggle wise would look to be making the existing transport 'remote max
> >> frame size' overridable until set by the Open frame arriving and use
> >> it to govern this behaviour.
> >>
> >
> > That (configurable initial maximum) sounds sensible to me.  Ultimately
> > outside of the (in-discussion) CBS mechanism neither side really has much
> > influence over the size of the data being exchanged.  Out of interest, on
> > the sending size does proton already just send large SASL frames if you
> > supply it with > 512 bytes of data, or does it error?
> >
> > -- Rob
> >
>
> It does just send them, yes.
>

Ah - it's following the the exact opposite of the robustness principle
then, nice :)

-- Rob


>
> >
> >>
> >> Robbie
> >>
> >> On 26 July 2017 at 09:34, Rob Godfrey  wrote:
> >> > *sigh* I always thought 512 was a bit on the low side for this limit
> :-(
> >> >
> >> > For background the original intent of setting MIN-MAX-FRAME-SIZE at
> 512
> >> > bytes was to allow AMQP to be used on devices with very limited
> >> resources.
> >> > Logic(?) then dictated that all frames exchanged prior to a new max
> frame
> >> > size being agreed need to fit within the known minimum frame size
> limit.
> >> > In retrospect for SASL this was a mistake, as normally you don't
> really
> >> > have any choice ab out how big your sasl frames are going to be (the
> size
> >> > will be determined by the requirements of the mechanism).  If (say) we
> >> > allowed proton to be more relaxed in the frame sizes it allows (we'd
> >> still
> >> > want some limit to prevent DoS style attacks) then the worst that
> happens
> >> > (I think) is that SASL mechanisms that require larger frames will not
> >> work
> >> > against implementations which enforce the 512 byte limit... but then
> such
> >> > implementations can't realistically be supporting mechanisms which
> >> require
> >> > larger exchanges (such as GSSAPI/Kerberos).  I don't really see the
> value
> >> > in inventing a new SASL mechanism for this (allowing fragmentation of
> the
> >> > responses) as in reality this wouldn't help systems with limited
> >> resources
> >> > implement the mechanism (they'll still need to assemble the whole
> >> response
> >> > at some point I imagine).  Techniacally this will be spec violating,
> but
> >> > OTOH without violating the spec you can't implement the mechanism, so
> if
> >> > you offer the mechanism then you are implicitly saying "I'm not going
> to
> >> > enforce this rule".
> >> >
> >> > -- Rob
> >> >
> >> > On 25 July 2017 at 18:02, Gary Tully  wrote:
> >> >
> >> >> Hi,
> >> >> I have been working through adding SASL GSSAPI (Kerberos) support to
> the
> >> >> qpid-jms-client[1] and have hit a limit in proton-j
> >> >>
> >> >> The initial response in the SASL_Init frame can be > 512 which breaks
> >> the
> >> >> max frame size limitation as frame size negotiation has not completed
> >> yet.
> >> >> Proton-j will allow the frame to be written but the parse at the
> other
> >> end
> >> >> identifies the size exceeding the limit and errors out.
> >> >>
> >> >> I see in the AMQP Claims Based Security draft there is some work to
> >> >> describe how to SASL within that limitation in the context of a new
> >> >> mechanism.
> >> >>
> >> >> Is it reasonable to relax the check via config to allow the existing
> >> gssapi
> >> >> mechanism to work.
> >> >>
> >> >> Of the top of your head, what does proton-c do, maybe it never sends
> an
> >> >> initial response in the sasl_init?
> >> >>
> >> >> thanks in advance for any read of this :-)
> >> >>
> >> >> gary.
> >> >>
> >> >> [1]

Re: SASL GSSAPI and MIN-MAX-FRAME-SIZE

2017-07-26 Thread Robbie Gemmell 
On 26 July 2017 at 14:09, Rob Godfrey  wrote:
> On 26 July 2017 at 14:43, Robbie Gemmell  wrote:
>
>> That essentially summarises some discussion I had with others on this
>> elsewhere late yesterday and was planning to see what you and others
>> thought about it after having a look at the impls.
>>
>> I agree that making a custom mechanism for fragmenting an existing
>> mechanisms content is ugly and probably of little value in the end
>> since you would still need to handle the whole as you say. If the
>> regular mechanism name was offered and it needs >512 byte in a given
>> situation then it obviously wouldnt work if you enforce that limit..so
>> either you couldnt expect it to work anyway, in which case why offer
>> it, or presumably wouldnt enforce the limit. If servers dont offer
>> such mechanism or clients dont select them, which many wont in this
>> case, there isn't an issue for them.
>>
>> To allow proceeding despite the size, we would need to add a toggle to
>> proton-j to control what it will allow to be received for sasl frames,
>> or adjust the default size it will allow, or both. The simplest thing
>> toggle wise would look to be making the existing transport 'remote max
>> frame size' overridable until set by the Open frame arriving and use
>> it to govern this behaviour.
>>
>
> That (configurable initial maximum) sounds sensible to me.  Ultimately
> outside of the (in-discussion) CBS mechanism neither side really has much
> influence over the size of the data being exchanged.  Out of interest, on
> the sending size does proton already just send large SASL frames if you
> supply it with > 512 bytes of data, or does it error?
>
> -- Rob
>

It does just send them, yes.

>
>>
>> Robbie
>>
>> On 26 July 2017 at 09:34, Rob Godfrey  wrote:
>> > *sigh* I always thought 512 was a bit on the low side for this limit :-(
>> >
>> > For background the original intent of setting MIN-MAX-FRAME-SIZE at 512
>> > bytes was to allow AMQP to be used on devices with very limited
>> resources.
>> > Logic(?) then dictated that all frames exchanged prior to a new max frame
>> > size being agreed need to fit within the known minimum frame size limit.
>> > In retrospect for SASL this was a mistake, as normally you don't really
>> > have any choice ab out how big your sasl frames are going to be (the size
>> > will be determined by the requirements of the mechanism).  If (say) we
>> > allowed proton to be more relaxed in the frame sizes it allows (we'd
>> still
>> > want some limit to prevent DoS style attacks) then the worst that happens
>> > (I think) is that SASL mechanisms that require larger frames will not
>> work
>> > against implementations which enforce the 512 byte limit... but then such
>> > implementations can't realistically be supporting mechanisms which
>> require
>> > larger exchanges (such as GSSAPI/Kerberos).  I don't really see the value
>> > in inventing a new SASL mechanism for this (allowing fragmentation of the
>> > responses) as in reality this wouldn't help systems with limited
>> resources
>> > implement the mechanism (they'll still need to assemble the whole
>> response
>> > at some point I imagine).  Techniacally this will be spec violating, but
>> > OTOH without violating the spec you can't implement the mechanism, so if
>> > you offer the mechanism then you are implicitly saying "I'm not going to
>> > enforce this rule".
>> >
>> > -- Rob
>> >
>> > On 25 July 2017 at 18:02, Gary Tully  wrote:
>> >
>> >> Hi,
>> >> I have been working through adding SASL GSSAPI (Kerberos) support to the
>> >> qpid-jms-client[1] and have hit a limit in proton-j
>> >>
>> >> The initial response in the SASL_Init frame can be > 512 which breaks
>> the
>> >> max frame size limitation as frame size negotiation has not completed
>> yet.
>> >> Proton-j will allow the frame to be written but the parse at the other
>> end
>> >> identifies the size exceeding the limit and errors out.
>> >>
>> >> I see in the AMQP Claims Based Security draft there is some work to
>> >> describe how to SASL within that limitation in the context of a new
>> >> mechanism.
>> >>
>> >> Is it reasonable to relax the check via config to allow the existing
>> gssapi
>> >> mechanism to work.
>> >>
>> >> Of the top of your head, what does proton-c do, maybe it never sends an
>> >> initial response in the sasl_init?
>> >>
>> >> thanks in advance for any read of this :-)
>> >>
>> >> gary.
>> >>
>> >> [1] https://issues.apache.org/jira/browse/QPIDJMS-303
>> >>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
>> For additional commands, e-mail: dev-h...@qpid.apache.org
>>
>>

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

Re: SASL GSSAPI and MIN-MAX-FRAME-SIZE

2017-07-26 Thread Rob Godfrey 
On 26 July 2017 at 14:43, Robbie Gemmell  wrote:

> That essentially summarises some discussion I had with others on this
> elsewhere late yesterday and was planning to see what you and others
> thought about it after having a look at the impls.
>
> I agree that making a custom mechanism for fragmenting an existing
> mechanisms content is ugly and probably of little value in the end
> since you would still need to handle the whole as you say. If the
> regular mechanism name was offered and it needs >512 byte in a given
> situation then it obviously wouldnt work if you enforce that limit..so
> either you couldnt expect it to work anyway, in which case why offer
> it, or presumably wouldnt enforce the limit. If servers dont offer
> such mechanism or clients dont select them, which many wont in this
> case, there isn't an issue for them.
>
> To allow proceeding despite the size, we would need to add a toggle to
> proton-j to control what it will allow to be received for sasl frames,
> or adjust the default size it will allow, or both. The simplest thing
> toggle wise would look to be making the existing transport 'remote max
> frame size' overridable until set by the Open frame arriving and use
> it to govern this behaviour.
>

That (configurable initial maximum) sounds sensible to me.  Ultimately
outside of the (in-discussion) CBS mechanism neither side really has much
influence over the size of the data being exchanged.  Out of interest, on
the sending size does proton already just send large SASL frames if you
supply it with > 512 bytes of data, or does it error?

-- Rob


>
> Robbie
>
> On 26 July 2017 at 09:34, Rob Godfrey  wrote:
> > *sigh* I always thought 512 was a bit on the low side for this limit :-(
> >
> > For background the original intent of setting MIN-MAX-FRAME-SIZE at 512
> > bytes was to allow AMQP to be used on devices with very limited
> resources.
> > Logic(?) then dictated that all frames exchanged prior to a new max frame
> > size being agreed need to fit within the known minimum frame size limit.
> > In retrospect for SASL this was a mistake, as normally you don't really
> > have any choice ab out how big your sasl frames are going to be (the size
> > will be determined by the requirements of the mechanism).  If (say) we
> > allowed proton to be more relaxed in the frame sizes it allows (we'd
> still
> > want some limit to prevent DoS style attacks) then the worst that happens
> > (I think) is that SASL mechanisms that require larger frames will not
> work
> > against implementations which enforce the 512 byte limit... but then such
> > implementations can't realistically be supporting mechanisms which
> require
> > larger exchanges (such as GSSAPI/Kerberos).  I don't really see the value
> > in inventing a new SASL mechanism for this (allowing fragmentation of the
> > responses) as in reality this wouldn't help systems with limited
> resources
> > implement the mechanism (they'll still need to assemble the whole
> response
> > at some point I imagine).  Techniacally this will be spec violating, but
> > OTOH without violating the spec you can't implement the mechanism, so if
> > you offer the mechanism then you are implicitly saying "I'm not going to
> > enforce this rule".
> >
> > -- Rob
> >
> > On 25 July 2017 at 18:02, Gary Tully  wrote:
> >
> >> Hi,
> >> I have been working through adding SASL GSSAPI (Kerberos) support to the
> >> qpid-jms-client[1] and have hit a limit in proton-j
> >>
> >> The initial response in the SASL_Init frame can be > 512 which breaks
> the
> >> max frame size limitation as frame size negotiation has not completed
> yet.
> >> Proton-j will allow the frame to be written but the parse at the other
> end
> >> identifies the size exceeding the limit and errors out.
> >>
> >> I see in the AMQP Claims Based Security draft there is some work to
> >> describe how to SASL within that limitation in the context of a new
> >> mechanism.
> >>
> >> Is it reasonable to relax the check via config to allow the existing
> gssapi
> >> mechanism to work.
> >>
> >> Of the top of your head, what does proton-c do, maybe it never sends an
> >> initial response in the sasl_init?
> >>
> >> thanks in advance for any read of this :-)
> >>
> >> gary.
> >>
> >> [1] https://issues.apache.org/jira/browse/QPIDJMS-303
> >>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
> For additional commands, e-mail: dev-h...@qpid.apache.org
>
>

Re: SASL GSSAPI and MIN-MAX-FRAME-SIZE

2017-07-26 Thread Robbie Gemmell 
That essentially summarises some discussion I had with others on this
elsewhere late yesterday and was planning to see what you and others
thought about it after having a look at the impls.

I agree that making a custom mechanism for fragmenting an existing
mechanisms content is ugly and probably of little value in the end
since you would still need to handle the whole as you say. If the
regular mechanism name was offered and it needs >512 byte in a given
situation then it obviously wouldnt work if you enforce that limit..so
either you couldnt expect it to work anyway, in which case why offer
it, or presumably wouldnt enforce the limit. If servers dont offer
such mechanism or clients dont select them, which many wont in this
case, there isn't an issue for them.

To allow proceeding despite the size, we would need to add a toggle to
proton-j to control what it will allow to be received for sasl frames,
or adjust the default size it will allow, or both. The simplest thing
toggle wise would look to be making the existing transport 'remote max
frame size' overridable until set by the Open frame arriving and use
it to govern this behaviour.

Robbie

On 26 July 2017 at 09:34, Rob Godfrey  wrote:
> *sigh* I always thought 512 was a bit on the low side for this limit :-(
>
> For background the original intent of setting MIN-MAX-FRAME-SIZE at 512
> bytes was to allow AMQP to be used on devices with very limited resources.
> Logic(?) then dictated that all frames exchanged prior to a new max frame
> size being agreed need to fit within the known minimum frame size limit.
> In retrospect for SASL this was a mistake, as normally you don't really
> have any choice ab out how big your sasl frames are going to be (the size
> will be determined by the requirements of the mechanism).  If (say) we
> allowed proton to be more relaxed in the frame sizes it allows (we'd still
> want some limit to prevent DoS style attacks) then the worst that happens
> (I think) is that SASL mechanisms that require larger frames will not work
> against implementations which enforce the 512 byte limit... but then such
> implementations can't realistically be supporting mechanisms which require
> larger exchanges (such as GSSAPI/Kerberos).  I don't really see the value
> in inventing a new SASL mechanism for this (allowing fragmentation of the
> responses) as in reality this wouldn't help systems with limited resources
> implement the mechanism (they'll still need to assemble the whole response
> at some point I imagine).  Techniacally this will be spec violating, but
> OTOH without violating the spec you can't implement the mechanism, so if
> you offer the mechanism then you are implicitly saying "I'm not going to
> enforce this rule".
>
> -- Rob
>
> On 25 July 2017 at 18:02, Gary Tully  wrote:
>
>> Hi,
>> I have been working through adding SASL GSSAPI (Kerberos) support to the
>> qpid-jms-client[1] and have hit a limit in proton-j
>>
>> The initial response in the SASL_Init frame can be > 512 which breaks the
>> max frame size limitation as frame size negotiation has not completed yet.
>> Proton-j will allow the frame to be written but the parse at the other end
>> identifies the size exceeding the limit and errors out.
>>
>> I see in the AMQP Claims Based Security draft there is some work to
>> describe how to SASL within that limitation in the context of a new
>> mechanism.
>>
>> Is it reasonable to relax the check via config to allow the existing gssapi
>> mechanism to work.
>>
>> Of the top of your head, what does proton-c do, maybe it never sends an
>> initial response in the sasl_init?
>>
>> thanks in advance for any read of this :-)
>>
>> gary.
>>
>> [1] https://issues.apache.org/jira/browse/QPIDJMS-303
>>

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

[Proton-c C++ 0.16.0] [Solaris Sparc] [GCC 4.9.2] Assuming threads will propage exceptions

2017-07-26 Thread Adel Boutros 
Hello,


I hope you missed my mails about Solaris 


We are currently testing whether we can compile on Solaris using GCC 4.9.2. We 
were successful in doing so for Solaris x86 but we have hit a problem in Sparc.


It seems related to certain assumptions made around how threads propagates 
exceptions:


The failing test is "examples/cpp/example_test.py: test_ssl_bad_name"

In examples/cpp/ssl.cpp [1], it spawns another thread and wait for it to throw 
an exception.


However, if you check the thread documentation[2], it states the propagation of 
exceptions is not guaranteed[3].


So I was wondering if the assumption that Proton makes is not a big dangerous 
and should be changed?


Simpler Example

-
#include 
#include 
#include 

class example_cert_error : public std::runtime_error
{
public:
explicit example_cert_error(const std::string& s) : 
std::runtime_error(s) {}
};

int main(int argc, char** argv) {
try {
std::thread th([](){throw example_cert_error("my error"); });
} catch (const example_cert_error& ce) {
std::cout << "Caught: " << ce.what() << std::endl;
}
return 0;
}



Solaris X86

---
$ g++49 -std=c++11 throw.cpp -o throw
$ ./throw
Caught: my error

Solaris Sparc
-
$ g++49 -std=c++11 throw.cpp -o throw
$ ./throw
terminate called without an active exception
Abort (core dumped)


[1]: https://github.com/apache/qpid-proton/blob/0.16.x/examples/cpp/ssl.cpp#L178

[2]: http://en.cppreference.com/w/cpp/thread/thread

[3]: The top-level function may communicate its return value or an exception to 
the caller

Re: SASL GSSAPI and MIN-MAX-FRAME-SIZE

2017-07-26 Thread Rob Godfrey 
*sigh* I always thought 512 was a bit on the low side for this limit :-(

For background the original intent of setting MIN-MAX-FRAME-SIZE at 512
bytes was to allow AMQP to be used on devices with very limited resources.
Logic(?) then dictated that all frames exchanged prior to a new max frame
size being agreed need to fit within the known minimum frame size limit.
In retrospect for SASL this was a mistake, as normally you don't really
have any choice ab out how big your sasl frames are going to be (the size
will be determined by the requirements of the mechanism).  If (say) we
allowed proton to be more relaxed in the frame sizes it allows (we'd still
want some limit to prevent DoS style attacks) then the worst that happens
(I think) is that SASL mechanisms that require larger frames will not work
against implementations which enforce the 512 byte limit... but then such
implementations can't realistically be supporting mechanisms which require
larger exchanges (such as GSSAPI/Kerberos).  I don't really see the value
in inventing a new SASL mechanism for this (allowing fragmentation of the
responses) as in reality this wouldn't help systems with limited resources
implement the mechanism (they'll still need to assemble the whole response
at some point I imagine).  Techniacally this will be spec violating, but
OTOH without violating the spec you can't implement the mechanism, so if
you offer the mechanism then you are implicitly saying "I'm not going to
enforce this rule".

-- Rob

On 25 July 2017 at 18:02, Gary Tully  wrote:

> Hi,
> I have been working through adding SASL GSSAPI (Kerberos) support to the
> qpid-jms-client[1] and have hit a limit in proton-j
>
> The initial response in the SASL_Init frame can be > 512 which breaks the
> max frame size limitation as frame size negotiation has not completed yet.
> Proton-j will allow the frame to be written but the parse at the other end
> identifies the size exceeding the limit and errors out.
>
> I see in the AMQP Claims Based Security draft there is some work to
> describe how to SASL within that limitation in the context of a new
> mechanism.
>
> Is it reasonable to relax the check via config to allow the existing gssapi
> mechanism to work.
>
> Of the top of your head, what does proton-c do, maybe it never sends an
> initial response in the sasl_init?
>
> thanks in advance for any read of this :-)
>
> gary.
>
> [1] https://issues.apache.org/jira/browse/QPIDJMS-303
>