I have no idea which is best. For being able to say we use industry standard Kerberos, calling an accepted implementation seems wise, like OpenSSL support.
- HH On Thu, Oct 26, 2017 at 11:39, Paulo R. Dellani <dell...@pobox.com> wrote: > This all sounds very interesting. What is the idea? Wrap libkrb5 through UFFI > or implement it in Smalltalk? > > On 10/26/2017 04:38 PM, henry wrote: > >> A Kerberos effort will have to be a group effort. Sideways to my main focus >> and your all’s main focii. >> >> - HH >> >> On Thu, Oct 26, 2017 at 09:15, henry >> <[he...@callistohouse.club](%22mailto:he...@callistohouse.club%22)> wrote: >> >>> I think another good service to integrate well to is Elastic Search. >>> >>> Of the 4 types of integration, I vote for and step forward to volunteer to >>> help Kerberos integration in Pharo. What to do? >>> >>> - HH >>> >>> On Thu, Oct 26, 2017 at 09:06, henry >>> <[he...@callistohouse.club](%22%22mailto:he...@callistohouse.club%22%22)> >>> wrote: >>> >>>> I try posting with a smaller image. >>>> >>>> [""hubbub.jpg""] >>>> >>>> - HH >>>> >>>>> ——— Original Message ——— >>>>> Subject: Re: [Pharo-users] Smalltalk Argument >>>>> Local Time: October 26, 2017 8:52 AM >>>>> UTC Time: October 26, 2017 12:52 PM >>>>> From: he...@callistohouse.club >>>>> To: p...@highoctane.be [<p...@highoctane.be>](mailto:p...@highoctane.be), >>>>> Any question about pharo is welcome >>>>> [<pharo-users@lists.pharo.org>](mailto:pharo-users@lists.pharo.org) >>>>> >>>>> Perhaps not, or not yet. Perhaps it is the communications foundation for >>>>> an always-on cloud/bigData control layer. >>>>> >>>>> I would position ParrotTalk as a Kerberos transport. ParrotTalk does >>>>> 2048-bin key negotiation and subsequent encryption/encoding, both >>>>> user-supplied. >>>>> >>>>> Please see the attached diagram, co-locating ParrotTalk with my other >>>>> components. >>>>> >>>>> ParrotTalk does not do user authentication/authorization. Which means to >>>>> me that I should consider Kerberos authorization/authentication to >>>>> establish as an integratable transport to play in bigData. >>>>> >>>>> This means you still need a Kerberos client and I need a Kerberos client. >>>>> How do we start? >>>>> >>>>> - HH >>>>> >>>>> PS: I did much work integrating Kafka into a framework. I was thinking of >>>>> inserting msg sending replication to a partition count of replicate >>>>> queues for sending and receiving Hubbub traffic, thus inserting right >>>>> where Kerberos is in the diagram. I would love to see client coupling for >>>>> Kerberos, Kafka and Hadoop, while I figure out proper security to make >>>>> that group happy with this as a possible control layer solution, forking >>>>> off jobs. >>>>> >>>>> On Thu, Oct 26, 2017 at 03:14, p...@highoctane.be >>>>> <[p...@highoctane.be](%22%22%22mailto:p...@highoctane.be%22%22%22)> wrote: >>>>> >>>>>> Sure. Current main issue is to have Pharo work with Kerberos as secured >>>>>> Hadoop uses the UGI (UserGroupInformation) thing and that is a black >>>>>> hole of crypto things. >>>>>> >>>>>> How would you see ParrotTalk work? >>>>>> >>>>>> I made a XmppTalk thing (binding for libstrophe) for having Pharo images >>>>>> and other stuff talk together (currently using OpenFire/Gajim/Profanity) >>>>>> FWIW >>>>>> >>>>>> See >>>>>> [https://docs.google.com/presentation/d/1HTG3GB3xdwlje8wADZPjUQNIyA6tmuxyZz1UaX5ikEU/edit?usp=sharing](%22%22%22https://docs.google.com/presentation/d/1HTG3GB3xdwlje8wADZPjUQNIyA6tmuxyZz1UaX5ikEU/edit?usp=sharing%22%22%22) >>>>>> >>>>>> libstrophe does the SSL thing under the hood (using OpenSSL) and is >>>>>> actively maintained. >>>>>> [https://github.com/strophe/libstrophe/blob/master/src/tls_openssl.c](%22%22%22https://github.com/strophe/libstrophe/blob/master/src/tls_openssl.c%22%22%22) >>>>>> >>>>>> And I currently work with Kafka so, Pharo as a consumer or producer, >>>>>> sure am interested. But need Kerberos support. >>>>>> >>>>>> Tell me more about your vision. Even better, draw it in some way :-) >>>>>> >>>>>> Phil >>>>>> >>>>>> On Thu, Oct 26, 2017 at 8:43 AM, henry >>>>>> <[he...@callistohouse.club](%22%22%22mailto:he...@callistohouse.club%22%22%22)> >>>>>> wrote: >>>>>> >>>>>>> This is a goal of ParrotTalk, to bring bit-compatible communications to >>>>>>> Squeak, Pharo and Java. This is not an invocation bridge you speak of >>>>>>> but a communications bridge to be able to run against Hadoop or >>>>>>> whichever big data needs integration with (Kafka). I had hoped it might >>>>>>> be adopted for such. Yet again this is not exactly what you were >>>>>>> looking for but yet interesting perhaps? >>>>>>> >>>>>>> - HH >>>>>>> >>>>>>> On Thu, Oct 26, 2017 at 02:17, >>>>>>> [p...@highoctane.be](%22%22%22mailto:p...@highoctane.be%22%22%22) < >>>>>>> p...@highoctane.be> wrote: >>>>>>> >>>>>>>> I like that piece a lot, seeing exactly the described situation in >>>>>>>> large enterprises. >>>>>>>> >>>>>>>> I made a strategic decision to go with Pharo for the long run for my >>>>>>>> solutions because it is a stable base on which to build (ok, there are >>>>>>>> evolutions, but fundamentally, I can rely on it being under control >>>>>>>> and can maintain solutions in a version). >>>>>>>> >>>>>>>> The rationale is that at a deep level I am really fed up with having >>>>>>>> to deal with accidental complexity (now having to deal with >>>>>>>> Spark/Scala/sbt/Java/maven stuff) that makes the dev focus 80% >>>>>>>> technology drag and 20% net business contribution. >>>>>>>> >>>>>>>> One key thing is that a team needs guidance and Smalltalk makes it >>>>>>>> easier due to well known ways of doing things. >>>>>>>> >>>>>>>> Now we miss the boat on mobile and bigdata, but this is solvable. >>>>>>>> >>>>>>>> If we had an open Java bridge (and some people in the community have >>>>>>>> it for Pharo but do not open source it - so this is eminently doable) >>>>>>>> + Pharo as an embeddable piece (e.g. like Tcl and Lua) and not a big >>>>>>>> executable we would have a way to embed Pharo in a lot of places (e.g. >>>>>>>> in the Hadoop ecosystem where fast starting VMs and small footprint >>>>>>>> would make the cluster capacity x2 or x3 vs uberjars all over the >>>>>>>> place) this would be a real disruption. >>>>>>>> >>>>>>>> Think about being able to call Pharo from JNA >>>>>>>> https://github.com/java-native-access/jna the same way we use C with >>>>>>>> UFFI. >>>>>>>> >>>>>>>> Smalltalk argument for me is that it makes development bearable (even >>>>>>>> fun and enjoyable would I say) vs the other stacks. That matters. >>>>>>>> >>>>>>>> Phil
