Re: River's Future

This is interesting but the link is broken. Michal Peter October 11, 2016 at 10:02 AM I'd like to donate atomic input validation for Java serialization to River. At least one security researcher has provided some initial positive feedback. See the comments at th

Re: another interesting link

>> 2. proxy codebase jars contain a list of requested permissions to be granted to the jar signer and url (client need not know in advance). This one is tricky: 1) It is not always possible to specify fine grained permissions statically (for example we want to restrict the connect permission to c

Re: another interesting link

I am well aware of StartNow since that is the first Jini "support library" I have used. Indeed - it is really easy to use. But it is only one side of the issue - the API and some support support code that is supposed to be linked statically with the service implementation. What I am talking ab

Re: another interesting link

In my dreams I always thought of "self configuring" and "adapting" services. So instead of reading a "configuration" a service would simply search for other services and use them. Exporter service being an example. Ideally - the only thing that should be configured would be the "identity" (ie. c

New life for River?

I've just came across this: http://arstechnica.co.uk/tech-policy/2016/01/android-n-switches-to-openjdk-google-tells-oracle-it-is-protected-by-the-gpl/ Hopefully it means we can have River working on Android soon. Michal

Re: Security

BTW - I'm really interested in the reasoning why deserialization code does not call the non-serializable superclass constructor in the security context of the subclass(es) - so that it really mimics the normal constructor call chain. Michal Michał Kłeczek (XPro) wrote: > Isn't the i

Re: Security

Isn't the issue with non-serializable superclass constructor call this one? : http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5353 If so - I don't really see how it relates to River - to be able to expoit this kind of vulnerability an attacker must have already downloaded and run his code -

Re: SerialReflectionFactory - got a better name?

Also, I am not sure I like "Distributed" or "DistributedObject" - it suggests an instance is distributed. "Transferable"? Sorry - English is not my mother tongue so it is hard to find viable alternatives :) Michal On Thursday 26 of June 2014 13:23:39 Michał Kł

Re: SerialReflectionFactory - got a better name?

1. I understand "Memento" is an interface and "ReflectiveMemento" - an implementation 2. Isn't just "Memento" too generic? DistributedObjectMemento? SerializableMemento? (to indicate implementations should support standard serialization)? 3. A little different issue - did u find a way to seria

Re: SerialReflectionFactory - got a better name?

It really is a Memento. Isn't it? Michal 23 cze 2014 13:24 "Peter Firmstone" napisał(a): > Distributed object use SerialReflectionFactory to recreate themselves > remotely using one of their public constructors, a static factory method or > builder object, however one thing about SerialReflectio

Re: [VOTE] Patricia Shanahan for PMC Chair

+1 Michal 19 maj 2014 13:39 "Dawid Loubser" napisał(a): > Dude, it's open-source. We're all members ;-) > (or can at least all share opinions...) > > Dawid > > > On 19/05/2014 13:37, Bryan Thompson wrote: > > I assume that only members can vote? > > > >> On May 19, 2014, at 7:19 AM, Peter Firmst

Re: New Chair for Apache River PMC

That is going to cause qa_refactor merge difficult. My take - pretty radical - on this would be: 1. Rename branch trunk to "2.x.x" - 2.x would enter "legacy maintanance" mode 2. Rename qa_refactor to "trunk" 3. Rename packages in "trunk", introduce compatibility jars 4. Release 3.0.0-alpha from "

Re: Health of the Apache River Project

ven a committer is entirely another > matter. I don't understand the project structure and I don't want to > touch those ant scripts, especially classanddepjar task, with a stick, > let alone modify it. > > (...) > > > Having said that, I wouldn’t jump in and “Mavenize River

Re: River-436 Patch attached to Jira

new possibilities. > > > > I am more than eager to discuss it and compare to alternatives. > > > > Note that the code is not really production-grade (yet). I've attached > > it for review. -- Michał Kłeczek XPro Sp. z o. o. ul. Borowskiego 2 03-475 Warszawa Polska

Re: River-436 - need some explanation of preferred class provider

d not authorized at > > server1, could not glue themselves into the class loader hierarchy. > > > > This kind of mechanism lets the app developer designate exactly what > > they want to have happen and control it from the service where it should > > be controlled. > &

River-436 Patch attached to Jira

ttached it for review. -- Michał Kłeczek XPro Sp. z o. o. ul. Borowskiego 2 03-475 Warszawa Polska

Re: SerialReflectionFactory and ObjectStreamContext

> > > On Monday, March 10, 2014 10:48:29 AM Peter wrote: > > > I'm open to suggestion. > > > > > > Regards, > > > > > > Peter. > > > > > > - Original message - > > > > > > > Peter, > > &

Re: River-436 - need some explanation of preferred class provider

Actually it is even worse. Since RMIClassProvider API is stateless the client has only one list of URLs at a time... Regards, On Sunday, March 09, 2014 10:54:57 PM Michał Kłeczek wrote: > The whole point of my example is that the client has no knowledge of Util > interface - it is simp

Re: SerialReflectionFactory and ObjectStreamContext

message - > > > Peter, > > > > Can your SerialReflectionFactory expose an API to interact with the > > stream? It would be enough to be able to retrieve context Collection > > from ObjectStreamContext. > > > > Thanks, > >Michał

Re: River-436 - need some explanation of preferred class provider

it out and plug it in. > There is room for a single standard to eventually win. But, there isn’t a > single standard that is standing alone right now that I see. > > Gregg Wonderly -- Michał Kłeczek XPro Sp. z o. o. ul. Borowskiego 2 03-475 Warszawa PolskaBEGIN:VCARD ADR;TYPE=p

SerialReflectionFactory and ObjectStreamContext

Peter, Can your SerialReflectionFactory expose an API to interact with the stream? It would be enough to be able to retrieve context Collection from ObjectStreamContext. Thanks, -- Michał Kłeczek XPro Sp. z o. o. ul. Borowskiego 2 03-475 Warszawa PolskaBEGIN:VCARD ADR;TYPE=pref;TYPE=work

Re: DistributedLambda

Peter, I'm still trying to grasp what you want to achieve... Is it simply in-band code downloading? Regards, -- Michał Kłeczek XPro Sp. z o. o. ul. Borowskiego 2 03-475 Warszawa PolskaBEGIN:VCARD ADR;TYPE=pref;TYPE=work:;;ul. Borowskiego 2;Warszawa;;03-475;Poland EMAIL:michal.klec...@xpr

Re: River-436 - need some explanation of preferred class provider

Although lambdas are not compiled to anonymous classes the code IS NOT generated at runtime. They end up as methods and bound in runtime using invokeDynamic. See: http://cr.openjdk.java.net/~briangoetz/lambda/lambda-translation.html Regards 7 mar 2014 19:22 "Peter" napisał(a): > - Original

Re: River-436 - need some explanation of preferred class provider

arent” or other > hierarchal relationships doesn’t mean that the actions taken there have to > create any sort of hierarchy. > > Gregg Wonderly > > On Mar 7, 2014, at 10:32 AM, Michał Kłeczek > wrote: > > > Sure there is a need for code downloading for JERI proxie

Re: River-436 - need some explanation of preferred class provider

be downloaded, unless you need a smart proxy. > > Gregg Wonderly > > On Mar 7, 2014, at 10:32 AM, Michał Kłeczek > wrote: > > > Sure there is a need for code downloading for JERI proxies. You seem to > assume > > no custom endpoint implementations. > > > >

Re: River-436 - need some explanation of preferred class provider

ic proxies are a different story, and JERI already uses the > dynamic proxy mechanism. There’s no need, for example to download an > implementation class for an object that is directly exported - you only > really need the service interface to be available locally. > > > Cheers, > &

Re: River-436 - need some explanation of preferred class provider

institute such as class loading scheme completely > > > > independently of Jini’s use of some other class loading scheme, > > > > provided that you at least allow the “parent load this please” > > > > mechanism of hierarchical class loading to occur. > > >

Re: River-436 - need some explanation of preferred class provider

installed locally. > > If you have a solution to ClassLoader issues, I'm all ears, honestly though, > ClassLoaders are a Java issue, we do our best to work around them, I'm not > aware of a silver bullet. Beware of complex ClassLoader relationships, as > th

Re: River-436 - need some explanation of preferred class provider

a particular codebase to plugin a specific class name. > > Gregg Wonderly > > On Mar 4, 2014, at 7:39 PM, Gregg Wonderly wrote: > >> On Mar 4, 2014, at 12:02 AM, Michał Kłeczek > >> wrote: > >> > >> The real problem is that Util interface is

Re: River-436 - need some explanation of preferred class provider

uires new conventions for codebase annotations. > > One restriction is that service api cannot be changed after deployment. > > We could allow Service API to be loaded on demand after deployment, if it > doesn't already exist at the client, but again it cannot be changed after >

Re: River-436 - need some explanation of preferred class provider

. Anyway... It is not really River-436 problem so my patch proposal is going to have the same issue since it is just a replacement for String annotations and not change in class loading scheme. Thanks, Michal 4 mar 2014 06:38 "Michał Kłeczek" napisał(a): > 1. The problem is the

Re: River-436 - need some explanation of preferred class provider

; } > > > > > > Wrapper service codebase includes Util interface but it is _preferred_. > > > > > > Would deserialization of WrapperProxy end with ClassCastException? > > > From what I understand UtilProxy is annotated with its codebase. When > > > deserializing UtilProxy a ClassLoader is going to be created with > > > parent set to TCCL. It means Util interface is going to be loaded > > > twice by two ClassLoaders - one for WrapperProxy codebase and another > > > for UtilProxy codebase. > > > > > > Am I correct? > > > And if so: is it desired behavior? > > > > > > Regards, > > > > > > -- > > > Michał Kłeczek > > > XPro Quality Matters > > > http://www.xpro.biz > > > > >

Re: River-436 - need some explanation of preferred class provider

to be loaded twice by two > ClassLoaders - one for WrapperProxy codebase and another for UtilProxy > codebase. > > Am I correct? > And if so: is it desired behavior? > > Regards, > > -- > Michał Kłeczek > XPro Quality Matters > http://www.xpro.biz >

Re: [jira] [Commented] (RIVER-435) Proposed Standard for Single-Archive Service Deployment Packaging

eds to be interpreted by the client to an > > object implementing an interface. > > This object can be verified in exactly the same way as normal proxies > > are verified ( by a TrustVerifier - in particular the ProxyTrustVerifier > > ). All that happens during deserialization. > &

Re: [jira] [Commented] (RIVER-435) Proposed Standard for Single-Archive Service Deployment Packaging

>>> this list mainly with Peter. > >>>> Basically the idea is to change codebase annotation from > >>>> java.lang.String which needs to be interpreted by the client to an > object > >>>> implementing an interface. > >>>> This o

<    1   2