You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by jude <fl...@gmail.com> on 2012/02/20 10:03:34 UTC
Signed RSL from Apache
In the whitepaper there was mention that Adobe would not be signing the
framework RSL compiled by the Apache Flex project. That's a big hit for
downloading every time. Is there a way to get the Apache Flex RSL signed?
Re: Signed RSL from Apache
Posted by Haykel BEN JEMIA <ha...@gmail.com>.
Sure caching works per domain, but it would be ideal to cache the framework
RSLs globally.
Haykel
2012/2/20 Jarosław Szczepankiewicz <js...@gmail.com>
> caching the RSL in the browser is already used and ready (as far as
> www server is properly using Etag etc. headers). Apache http is
> caching static resources very well out of the box (at least if it is
> not in clusters which may broke Etag). The most important result of
> the adobe announcement is that there is no global cache. But you can
> still use RSL for flex serving from your host.
>
Re: Signed RSL from Apache
Posted by Paul Evans <pa...@creative-cognition.co.uk>.
On 20 Feb 2012, at 11:07, Martin Heidegger wrote:
> The Flashplayer does cache swfs if they come from the same domain.
No, the browser caches SWFs, not flash player.
On 20 Feb 2012, at 12:04, Martin Heidegger wrote:
> The flash player caches the signed RSL's differently.
Yes, but flash player caching is not on the table for Apache Flex even if signed. Adobe won't trust any but their own signed RSLs to the player cache.
Re: Signed RSL from Apache
Posted by almansour belleh blanco <za...@gmail.com>.
> The flash player caches the signed RSL's differently. [1]
>
> [1] http://livedocs.adobe.com/flex/3/html/help.html?content=rsl_09.html
>
> yours
> Martin.
A more up-to-date version
http://help.adobe.com/en_US/flex/using/WS2db454920e96a9e51e63e3d11c0bf69084-7add.html
--
Mansour Blanco
Software engineer
Stackoverflow: http://stackoverflow.com/users/612920/mansuro
Blog: zuro.blogspot.com
github: https://github.com/Mansuro
Re: Signed RSL from Apache
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> Not sure if I'm getting confused here, but I thought we couldn't use RSLs as
> Adobe won't sign them?
We can still use RSLs both framework RSLs and user compiled/non framework RSLs. Apache framework RSLs will not be cached by the flash player but they can be cached by the browser (on a domain basis). There's no change to how non framework RSL work or behave. Caching of signed framework RSLs is a flash player feature so there's nothing we can really do about it. I was a nice to have but not essential feature for the use of RSLs.
Justin
RE: Signed RSL from Apache
Posted by David Arno <da...@davidarno.org>.
> From: Martin Heidegger [mailto:mh@leichtgewicht.at]
> Sent: 20 February 2012 12:04
>
> The flash player caches the signed RSL's differently. [1]
Not sure if I'm getting confused here, but I thought we couldn't use RSLs as
Adobe won't sign them? So Apache Flex will need to be based on plain,
unsigned, SWCs. Thus the browser will cache them, not the player. For
security, I was suggesting that we generate and check MD5 checksums for
these SWCs, thus allowing them to be served centrally, rather than on a
per-host basis.
Which bit have I got wrong?
David.
Re: Signed RSL from Apache
Posted by Martin Heidegger <mh...@leichtgewicht.at>.
On 20/02/2012 20:50, David Arno wrote:
>> From: Paul Evans [mailto:paulevans@creative-cognition.co.uk]
>> Sent: 20 February 2012 10:20
>>
>> From previous discussion, Alex raised concern of potential exposure to a
>> man-in-the-middle attack - unless we find a way of getting them signed.
> Do they really need signing? If we generate MD5 hashes for the SDK SWCs,
> then the loader could check those hashes on load. Would that not be secure
> enough, or is there a flaw in that idea?
>
> David.
The flash player caches the signed RSL's differently. [1]
[1] http://livedocs.adobe.com/flex/3/html/help.html?content=rsl_09.html
yours
Martin.
RE: Signed RSL from Apache
Posted by "Michael A. Labriola" <la...@digitalprimates.net>.
>wouldn't that be essentially the same as them "blessing" our framework, which is something they were unwilling to do in the first place? From what I remember, that is the entire beef they had -- they didn't want to say that our >framework was worthy of an RSL, unless it went through their security review first.
It's a little different in that, we would simply be asking that they are acknowledging something is an official release from Apache, not that our bits should be cached in the player, just the hashes of the official bits. I do not think this is practical or that they will do so... just saying it is one way to solve the issue if they were interested
Re: Signed RSL from Apache
Posted by Nicholas Kwiatkowski <ni...@spoon.as>.
wouldn't that be essentially the same as them "blessing" our framework,
which is something they were unwilling to do in the first place? From what
I remember, that is the entire beef they had -- they didn't want to say
that our framework was worthy of an RSL, unless it went through their
security review first.
-Nick
On Mon, Feb 20, 2012 at 8:24 AM, Michael A. Labriola <
labriola@digitalprimates.net> wrote:
> >more specifically... If attacker succeeds in the above, every app that
> wants to use the same library version is compromised by that browser cache
> even after leaving the 'man-in-the-middle' compromised network.
>
> I am not going to hold my breath on this, but the way to avoid this would
> be to have adobe host a minimal-sized, signed rsl, that contained our
> hashes. Then we have the hashes with a level of confidence.
>
> Mike
>
>
RE: Signed RSL from Apache
Posted by Iwo Banaś <ba...@gmail.com>.
On Feb 20, 2012 1:21 PM, "Michael A. Labriola" <la...@digitalprimates.net>
wrote:
> I am not going to hold my breath on this, but the way to avoid this would
be to have adobe host a minimal-sized, signed rsl, that contained our
hashes. Then we have the hashes with a level of confidence.
Can't the hashes of all used libraries be compiled into the application?
The problem with hash verification may be a performance of md5
calculations in as3. I recall a performance issues caused by custom RSL
verification in one project.
Cheers,
Iwo
RE: Signed RSL from Apache
Posted by "Michael A. Labriola" <la...@digitalprimates.net>.
>more specifically... If attacker succeeds in the above, every app that wants to use the same library version is compromised by that browser cache even after leaving the 'man-in-the-middle' compromised network.
I am not going to hold my breath on this, but the way to avoid this would be to have adobe host a minimal-sized, signed rsl, that contained our hashes. Then we have the hashes with a level of confidence.
Mike
Re: Signed RSL from Apache
Posted by Paul Evans <pa...@creative-cognition.co.uk>.
On 20 Feb 2012, at 12:41, Paul Evans wrote:
> * Can I 'man-in-the-middle' and inject badLibrary with corresponding md5 to make it look good - i.e. spoof the central repository
> * can i get a badLoader into the application
more specifically... If attacker succeeds in the above, every app that wants to use the same library version is compromised by that browser cache even after leaving the 'man-in-the-middle' compromised network.
Re: Signed RSL from Apache
Posted by Martin Heidegger <mh...@leichtgewicht.at>.
David,
you just brought up a question in my mind: What if we don't use the
"global index" at runtime but also at compile time:
programmer
-> Defines "RSL" with compile-time swc/f and online path and
eventual failbacks
compiler
-> Creates MD5 from from swc/f
-> Compares it against MD5 from online path
-> Compiles the MD5 into the swf (loader)
(Reasoning: Avoid man-in-the-middle for developers)
loader
-> Downloads the swc of one of the mirrors.
-> Compares the MD5 hash
-> If match accept and use loader to load it.
-> If no-match try other failbacks.
yours
Martin.
RE: Signed RSL from Apache
Posted by David Arno <da...@davidarno.org>.
> From: Haykel BEN JEMIA [mailto:haykelbj@gmail.com]
> Sent: 20 February 2012 16:00
> Talking about security, I think there is nothing being done to
> prevent man-in-the-middle for JS libraries hosted by Google
> for example, so it does not seem to be an issue even if JS is plain
> text and easier to manipulate (I did not hear about such an attack).
> Is the RSL issue we are talking about a real issue?
I think it's more a case that the JavaScript community seem more /relaxed/ about security. Such attacks are theoretically possible at least. If you are writing an application for a bank for example that handles financial transactions, then I'd imagine even theoretical threats have to be taken seriously.
David.
Re: Signed RSL from Apache
Posted by Haykel BEN JEMIA <ha...@gmail.com>.
Talking about security, I think there is nothing being done to prevent
man-in-the-middle for JS libraries hosted by Google for example, so it does
not seem to be an issue even if JS is plain text and easier to manipulate
(I did not hear about such an attack). Is the RSL issue we are talking
about a real issue?
Haykel
On 20 February 2012 16:47, Paul Evans <pa...@creative-cognition.co.uk>wrote:
>
> On 20 Feb 2012, at 15:30, Haykel BEN JEMIA wrote:
>
> >> Although: I suspect with effort, it is possible for suitably skilled for
> >> man-in-the-middle attacker to intercept the loader SWF and replace the
> >> byte-code storing the MD5 values their own and still inject badLibrary.
> > What about storing the data as an embedded octet-streams instead of
> strings?
>
> I am not sure that changes very much. If the validation bytes, whether
> stored as a string, octet or otherwise are a static sequence of bytes,
> established when the official library is compiled, then I think our
> notional attackers could match the pattern and substitute their own.
>
>
Re: Signed RSL from Apache
Posted by Paul Evans <pa...@creative-cognition.co.uk>.
On 20 Feb 2012, at 15:30, Haykel BEN JEMIA wrote:
>> Although: I suspect with effort, it is possible for suitably skilled for
>> man-in-the-middle attacker to intercept the loader SWF and replace the
>> byte-code storing the MD5 values their own and still inject badLibrary.
> What about storing the data as an embedded octet-streams instead of strings?
I am not sure that changes very much. If the validation bytes, whether stored as a string, octet or otherwise are a static sequence of bytes, established when the official library is compiled, then I think our notional attackers could match the pattern and substitute their own.
Re: Signed RSL from Apache
Posted by Haykel BEN JEMIA <ha...@gmail.com>.
Haykel Ben Jemia
Allmas
Web & Mobile Development
http://www.allmas-tn.com
On 20 February 2012 14:52, Paul Evans <pa...@creative-cognition.co.uk>wrote:
>
> Although: I suspect with effort, it is possible for suitably skilled for
> man-in-the-middle attacker to intercept the loader SWF and replace the
> byte-code storing the MD5 values their own and still inject badLibrary.
>
>
What about storing the data as an embedded octet-streams instead of strings?
RE: Signed RSL from Apache
Posted by David Arno <da...@davidarno.org>.
> From: Paul Evans [mailto:paulevans@creative-cognition.co.uk]
> Sent: 20 February 2012 13:53
>
> Sorry - still thinking up problems rather than solutions.
I think that is the best way with anything to do with security.
David.
Re: Signed RSL from Apache
Posted by Paul Evans <pa...@creative-cognition.co.uk>.
On 20 Feb 2012, at 13:19, David Arno wrote:
>> * can i get a badLoader into the application
> Probably. After all, what happens if someone spoofs the apache flex download
> site and provides a dodgy version of the SDK? But that's a whole different
> issue.
Yeah, though signed RSLs currently protect any app which uses them from being compromised by browser-cached libraries from otherApp based on a dodgy sdk.
Question is, can the proposed goodLoader do similar without itself being compromised? I hope so - it sounds promising.
Although: I suspect with effort, it is possible for suitably skilled for man-in-the-middle attacker to intercept the loader SWF and replace the byte-code storing the MD5 values their own and still inject badLibrary.
Sorry - still thinking up problems rather than solutions.
RE: Signed RSL from Apache
Posted by David Arno <da...@davidarno.org>.
> From: Paul Evans [mailto:paulevans@creative-cognition.co.uk]
> Sent: 20 February 2012 12:41
> i don't know enough about security, but in probing for flaws in that idea
I'd approach from:
I don't know much about security either. Thus why I'm questioning whether it
can be done, rather than just suggesting we do it :)
> * what happens if an application can't reach the central md5 store?
I wouldn't anticipate there being a central md5 store. The md5 values would
need to be compiled into the loader I would have thought. The loader then
compares the computed checksum of the fetched RSL with what it was
expecting.
> * Can I 'man-in-the-middle' and inject badLibrary with corresponding
> md5 to make it look good - i.e. spoof the central repository
As long as the md5's aren't fetched from a remote source, then I don't think
this should be an issue.
> * can i get a badLoader into the application
Probably. After all, what happens if someone spoofs the apache flex download
site and provides a dodgy version of the SDK? But that's a whole different
issue.
David.
Re: Signed RSL from Apache
Posted by Paul Evans <pa...@creative-cognition.co.uk>.
On 20 Feb 2012, at 11:50, David Arno wrote:
> If we generate MD5 hashes for the SDK SWCs,
> then the loader could check those hashes on load. Would that not be secure
> enough, or is there a flaw in that idea?
i don't know enough about security, but in probing for flaws in that idea I'd approach from:
* what happens if an application can't reach the central md5 store?
* Can I 'man-in-the-middle' and inject badLibrary with corresponding md5 to make it look good - i.e. spoof the central repository
* can i get a badLoader into the application
*shruggs*
RE: Signed RSL from Apache
Posted by David Arno <da...@davidarno.org>.
> From: Paul Evans [mailto:paulevans@creative-cognition.co.uk]
> Sent: 20 February 2012 10:20
>
> From previous discussion, Alex raised concern of potential exposure to a
> man-in-the-middle attack - unless we find a way of getting them signed.
Do they really need signing? If we generate MD5 hashes for the SDK SWCs,
then the loader could check those hashes on load. Would that not be secure
enough, or is there a flaw in that idea?
David.
Re: Signed RSL from Apache
Posted by Martin Heidegger <mh...@leichtgewicht.at>.
The Flashplayer does cache swfs if they come from the same domain.
Apache could offer a central library repository that would be much like
Google JavaScript repository. Its not a RLS but could be equally worth
it. However Google's infrastructure (connections, routing, etc.) is
awesome, no idea how Apache could offer something similar.
yours
Martin.
Re: Signed RSL from Apache
Posted by Haykel BEN JEMIA <ha...@gmail.com>.
Thanks for the link Paul. Indead this is a big issue and I think it can not
be fixed as only Adobe can create signed RSLs! Let's make them as small as
possible for now.
Haykel
On 20 February 2012 11:20, Paul Evans <pa...@creative-cognition.co.uk>wrote:
>
> On 20 Feb 2012, at 09:54, David Arno wrote:
>
> > The idea that Haykel was suggesting though would be to avoid serving it
> from individual hosts and to serve it globally instead. That way the
> browser only has to cache it once, not once per domain. There would be
> cross-domain issues, but I think they could be solved.
>
> From previous discussion, Alex raised concern of potential exposure to a
> man-in-the-middle attack - unless we find a way of getting them signed.
>
> http://markmail.org/message/ph6mvqgn5kj6m35n
>
>
Re: Signed RSL from Apache
Posted by Paul Evans <pa...@creative-cognition.co.uk>.
On 20 Feb 2012, at 09:54, David Arno wrote:
> The idea that Haykel was suggesting though would be to avoid serving it from individual hosts and to serve it globally instead. That way the browser only has to cache it once, not once per domain. There would be cross-domain issues, but I think they could be solved.
From previous discussion, Alex raised concern of potential exposure to a man-in-the-middle attack - unless we find a way of getting them signed.
http://markmail.org/message/ph6mvqgn5kj6m35n
RE: Signed RSL from Apache
Posted by David Arno <da...@davidarno.org>.
> From: Jarosław Szczepankiewicz [mailto:jszczepankiewicz@gmail.com]
> Sent: 20 February 2012 09:44
>
> caching the RSL in the browser is already used and ready (as far as
> www server is properly using Etag etc. headers). Apache http is
> caching static resources very well out of the box (at least if it is not in
> clusters which may broke Etag). The most important result of the adobe
> announcement is that there is no global cache.
> But you can still use RSL for flex serving from your host.
The idea that Haykel was suggesting though would be to avoid serving it from individual hosts and to serve it globally instead. That way the browser only has to cache it once, not once per domain. There would be cross-domain issues, but I think they could be solved.
David.
Re: Signed RSL from Apache
Posted by Jarosław Szczepankiewicz <js...@gmail.com>.
caching the RSL in the browser is already used and ready (as far as
www server is properly using Etag etc. headers). Apache http is
caching static resources very well out of the box (at least if it is
not in clusters which may broke Etag). The most important result of
the adobe announcement is that there is no global cache. But you can
still use RSL for flex serving from your host.
Re: Signed RSL from Apache
Posted by Jarosław Szczepankiewicz <js...@gmail.com>.
2012/2/20 David Arno <da...@davidarno.org>:
>> From: Haykel BEN JEMIA [mailto:haykelbj@gmail.com]
>> Sent: 20 February 2012 09:27
>>
>> Is it possible to enhance the preloader to download required RSLs from
>> a central Apache repository or are there any technical or FP security issues
>> that would make this impossible?
>
> Unless it is technically impossible (and I don't think it is,) this is certainly an area worth looking into. If we can't cache inside the Flash Player, we should look at caching in the browser. It's the approach that JQuery takes very successfully.
>
> David.
>
RE: Signed RSL from Apache
Posted by David Arno <da...@davidarno.org>.
> From: Haykel BEN JEMIA [mailto:haykelbj@gmail.com]
> Sent: 20 February 2012 09:27
>
> Is it possible to enhance the preloader to download required RSLs from
> a central Apache repository or are there any technical or FP security issues
> that would make this impossible?
Unless it is technically impossible (and I don't think it is,) this is certainly an area worth looking into. If we can't cache inside the Flash Player, we should look at caching in the browser. It's the approach that JQuery takes very successfully.
David.
Re: Signed RSL from Apache
Posted by Haykel BEN JEMIA <ha...@gmail.com>.
Is it possible to enhance the preloader to download required RSLs from a
central Apache repository or are there any technical or FP security issues
that would make this impossible?
Haykel
On 20 February 2012 10:17, Roland Zwaga <ro...@stackandheap.com> wrote:
> >
> > In the whitepaper there was mention that Adobe would not be signing the
> > framework RSL compiled by the Apache Flex project. That's a big hit for
> > downloading every time. Is there a way to get the Apache Flex RSL signed?
> >
>
> I believe this is impossible, the Flash Player will only cache RSL's that
> are explicitly signed by Adobe.
> This is indeed unfortunate, but in this case I understand Adobe's reasons.
> Anyways, this has been discussed already on the list, most people agree
> that it will be possible to
> remove the need for this caching by making the SDK more modular so that a
> simple application doesn't need
> to download 500K worth of SDK swc's.
>
> Roland
>
Re: Signed RSL from Apache
Posted by Roland Zwaga <ro...@stackandheap.com>.
>
> In the whitepaper there was mention that Adobe would not be signing the
> framework RSL compiled by the Apache Flex project. That's a big hit for
> downloading every time. Is there a way to get the Apache Flex RSL signed?
>
I believe this is impossible, the Flash Player will only cache RSL's that
are explicitly signed by Adobe.
This is indeed unfortunate, but in this case I understand Adobe's reasons.
Anyways, this has been discussed already on the list, most people agree
that it will be possible to
remove the need for this caching by making the SDK more modular so that a
simple application doesn't need
to download 500K worth of SDK swc's.
Roland
Re: Signed RSL from Apache
Posted by Paul Evans <pa...@creative-cognition.co.uk>.
On 20 Feb 2012, at 16:56, Omar Gonzalez wrote:
> 1.) security and 2.) Flash Player RSL caching at a global
> level (all domains),
> Having Apache host RSLs would help us to
> resolve #1 as Adobe will no longer host our RSLs. I hope that's clear and
> that I've gotten that all correct, someone correct me if I'm wrong here
> please.
RE #1, much this afternoon's discussion has been that unless they are signed or can in some other secure way authenticated at runtime, then #2 is likely unviable due to exposure to a 'man-in-the-middle' which issue Alex eluded to back in january:
On 5 Jan 2012, at 17:15, Alex Harui wrote:
> There are no plans at this time to host RSLs somewhere. It might be
> possible if we get enough support for it. However, they won't be signed and
> I'm concerned about the security implications of that. I'm not a security
> expert, but I believe unsigned RSLs will leave you exposed to a
> man-in-the-middle attack, at that alone might be sufficient to kill any
> momemtum for a central place to pick up RSLs.
Re: Signed RSL from Apache
Posted by Alex Harui <ah...@adobe.com>.
On 2/20/12 11:40 AM, "Michael A. Labriola" <la...@digitalprimates.net>
wrote:
>
> I always thought it would be interesting to stream the first two frames from a
> server. Then keep alive the connection, use some connection to a server to
> indicate which classes were needed next and just stream additional frames each
> time we need a group of definitions. Not saying we need to adapt everything to
> do that, just always wanted to try.
>
I'm not sure I understand the plan. What would you use for the SWF header
total bytes? Would it really be ok to go to the server and wait for the
response when you need a class?
It is possible already to pack modules onto extra frames of the SWF. It is
an interesting mechanism in that it allows you to pull down classes while
the user is busy doing something else without having to make separate module
fetches. You might run into fault scenarios where the bytes for some class
still isn't downloaded yet, but for wizards where you have some
predictability as to what classes are needed when, it could be useful. I
don't know of anyone who has really bothered to leverage this feature
though.
I did a prototype where I placed frame-rate as the number one priority. I
chopped UIComponent into a bunch of smaller chunks and packed some of those
chunks on later frames. Then you don't need a preloader that is written in
non-framework code. There is a basic "kernel" that can display a label and
textinput that downloads in about 1 sec, then you can bring in other
components in later frames as the features it needs become available. I
added other tricks like validating invisible components at a lower priority
so running effects get validated right away and a whole bunch of new
components get validated over many more frames but don't screw up the
transition. It is pretty interesting, but requires strategizing how you
design the initial states of the application.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
RE: Signed RSL from Apache
Posted by "Michael A. Labriola" <la...@digitalprimates.net>.
>Flex does not leverage that aspect of Flash. Like Java, it has code
>libraries which can be substantial in size. Unlike Java, it does not
>supported class loading on the fly. You have to preload the code before making access to a class.
Alex,
I always had a theory I wanted to try out but never had a chance to. Just curious to get your initial reaction on it as it pertains to this conversation. SWF is a streaming format. Generally, Flex takes advantages of 2 frames, but the system manager does already hint at looking at frames beyond 2.
I always thought it would be interesting to stream the first two frames from a server. Then keep alive the connection, use some connection to a server to indicate which classes were needed next and just stream additional frames each time we need a group of definitions. Not saying we need to adapt everything to do that, just always wanted to try.
Initial gut check on the theory?
Mike
RE: Computers as Theatre (was Re: Signed RSL from Apache)
Posted by Rui Silva <fl...@rduartes.net>.
Computers as Theatre it is, Alex.
I'm liking a lot what I read and start to understand what you've been
hinting at in other posts. Looking forward to look into your code and
understand your ideas in more detail.
Rui
Re: Signed RSL from Apache
Posted by Haykel BEN JEMIA <ha...@gmail.com>.
On 21 February 2012 11:33, David Arno <da...@davidarno.org> wrote:
> > From: Alex Harui [mailto:aharui@adobe.com]
> > Sent: 20 February 2012 19:18
> >
> > I have a prototype of a framework that leverage the zero-install
> capability of Flash
> > much better, which should eliminate the need for RSLs.
>
> Is this on your whiteboard yet so that we can all take a look? If not, I
> look forward to you putting it there soon as I'd be interested in how you
> achieved this.
>
>
+100 :)
> David.
>
>
>
Haykel
Computers as Theatre (was Re: Signed RSL from Apache)
Posted by Alex Harui <ah...@adobe.com>.
On 2/21/12 2:33 AM, "David Arno" <da...@davidarno.org> wrote:
> Is this on your whiteboard yet so that we can all take a look? If not, I
> look forward to you putting it there soon as I'd be interested in how you
> achieved this.
I don't even have a whiteboard folder yet. And it looks like these
prototypes needs legal clearance before checking in.
The basic principle is that once you have carved UIComponent and other
framework classes up into chunks the core UIComponent, LayoutManager and
StyleManager needed to render a Label and TextInput and some graphics fits
in about 80K which can be downloaded and rendered in about 1 sec over DSL
and VPN.
Let's say you have an app with a login dialog. Instead of a making the main
screen the initial state, your initial state is the login dialog, since
that's what the user will see first. As the player displays that login
dialog, the rest of the code is streaming in in the background. It is the
developers job to design subsequent states that don't have huge
dependencies: putting a DataGrid in the second state would be a bad idea,
putting a wireframe image of a DataGrid would be a valid substitute.
Usually, it takes a person two or 3 seconds to log in so by then you've got
a whole bunch of other classes downloaded. As long as you don't switch to a
state that requires a class you haven't downloaded, you are fine. I added
some logic so that when a state finishes rendering, you can automatically
switch to a next state. That way, you can effectively script a "reveal" of
the main screen.
By reducing the interdependency of classes in the framework, it becomes
possible to pack various classes on different frames and carefully
choreograph the "opening act" of your app, which sounds like a lot of work
(and is), but brings me to the inspiration for this scheme: Brenda Laurel's
book "Computers as Theatre".
The book was a difficult read, and not quite targeted at standard apps, but
my takeaway is this: Theater play designers have to deal with reality (as
opposed to movie directors who can make any reality). In live theater, you
can't just cut from, say a busy street seen to inside someone's house. It
takes time to move people off the stage and move a sofa onto a stage or lift
or drop a backdrop. Theater play designers use lighting, focus,
distraction, suspension of belief and other tricks to make it all happen.
This prototype explored allowing SWF designers to employ similar tricks in
the setup of their SWF in order to leverage the frame-based nature and
streaming capability of Flash to carefully script the opening of their apps.
The main screen then isn't the initial backdrop (state) because it requires
a lot of code the create it, but you can design a sequence of initial states
to get there.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
RE: Signed RSL from Apache
Posted by David Arno <da...@davidarno.org>.
> From: Alex Harui [mailto:aharui@adobe.com]
> Sent: 20 February 2012 19:18
>
> I have a prototype of a framework that leverage the zero-install
capability of Flash
> much better, which should eliminate the need for RSLs.
Is this on your whiteboard yet so that we can all take a look? If not, I
look forward to you putting it there soon as I'd be interested in how you
achieved this.
David.
Re: Signed RSL from Apache
Posted by Alex Harui <ah...@adobe.com>.
On 2/20/12 3:51 PM, "arieljake@yahoo.com" <ar...@yahoo.com> wrote:
> Can we program the loader to pull the hash from a URL via ssl?
There are lots of possibilities. Basically, if you are fetching the answer
to a question, you allow both the question and answer to be hacked to get
any answer you want. It will never be as secure as the current mechanism,
but it might be good enough. However, I still want to see the need for
startup time RSLs to go away.
I'm not sure how you would use SSL. Via a socket? Or https? There might be
browser limitations on it.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: Signed RSL from Apache
Posted by Ariel Jakobovits <ar...@yahoo.com>.
Can we program the loader to pull the hash from a URL via ssl?
Ariel Jakobovits
ajakobov@adobe.com
650-350-0282
On Feb 20, 2012, at 1:02 PM, Justin Mclean <ju...@classsoftware.com> wrote:
> Hi,
>
>> Also note that many large apps seem to have given up on RSLs because they've
>> had to hack the classes in the RSLs to fix bugs.
> Once the the project is up and running fully (people submitting patches etc etc) this will be less of an issue as there will be less need to monkey patch any Flex framework classes. Also you can you can compile any other changes you require right into the Flex framework. This makes RSLs actually usable again.
>
> Justin
Re: Signed RSL from Apache
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
>> Also you can you can compile any other changes you
>> require right into the Flex framework. This makes RSLs actually usable again.
> I'm not sure I understood this.
We can compile our own framework RSLs by applying any unsubmitted monkey patches directly to a local copy of the source code.
In my view the big issue with framework RSLs wasn't the caching but that they didn't work easily with needed monkey patches.
Justin
Re: Signed RSL from Apache
Posted by Alex Harui <ah...@adobe.com>.
On 2/20/12 1:02 PM, "Justin Mclean" <ju...@classsoftware.com> wrote:
> Hi,
>
>> Also note that many large apps seem to have given up on RSLs because they've
>> had to hack the classes in the RSLs to fix bugs.
> Once the the project is up and running fully (people submitting patches etc
> etc) this will be less of an issue as there will be less need to monkey patch
> any Flex framework classes.
That's true, but I still think RSLs are cumbersome. There is the problem
where a small change can drag in a huge RSL, and there is the problem of the
cache-miss.
> Also you can you can compile any other changes you
> require right into the Flex framework. This makes RSLs actually usable again.
I'm not sure I understood this.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: Signed RSL from Apache
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> Also note that many large apps seem to have given up on RSLs because they've
> had to hack the classes in the RSLs to fix bugs.
Once the the project is up and running fully (people submitting patches etc etc) this will be less of an issue as there will be less need to monkey patch any Flex framework classes. Also you can you can compile any other changes you require right into the Flex framework. This makes RSLs actually usable again.
Justin
Re: Signed RSL from Apache
Posted by Martin Heidegger <mh...@leichtgewicht.at>.
On 21/02/2012 04:36, Haykel BEN JEMIA wrote:
> loader.swf will also be loaded with the app and can be hacked by a m-i-t-m
> attack.
The purpose of the loader is that a application that is loaded uses
verified libraries. If the initial
access to the embedded loader.swf is corrupted by a m-i-t-m then there
is nothing that can be
done anyways.
yours
Martin.
Re: Signed RSL from Apache
Posted by Haykel BEN JEMIA <ha...@gmail.com>.
loader.swf will also be loaded with the app and can be hacked by a m-i-t-m
attack.
Sorry for the short message. Sent from my tablet.
Le 20 févr. 2012 20:29, "Martin Heidegger" <mh...@leichtgewicht.at> a écrit :
> On 21/02/2012 04:18, Alex Harui wrote:
>
>> I don't think we can find a way to know that a file downloaded from one
>> mirror is
>> the same as one coming from another mirror without downloading it in the
>> first place.
>>
> What is wrong about an approach where the "loader.swf" has MD5 hash of the
> files? It
> has to load and check the loaded files before initializing them. The
> man-in-the-middle would need to
> provide a hacked swf with the same md5 ... hard to archieve.
>
> yours
> Martin.
>
Re: Signed RSL from Apache
Posted by Martin Heidegger <mh...@leichtgewicht.at>.
On 21/02/2012 04:18, Alex Harui wrote:
> I don't think we can find a way to know that a file downloaded from one mirror is
> the same as one coming from another mirror without downloading it in the
> first place.
What is wrong about an approach where the "loader.swf" has MD5 hash of
the files? It
has to load and check the loaded files before initializing them. The
man-in-the-middle would need to
provide a hacked swf with the same md5 ... hard to archieve.
yours
Martin.
Re: Signed RSL from Apache
Posted by Alex Harui <ah...@adobe.com>.
On 2/20/12 9:26 AM, "Bertrand Delacretaz" <bd...@apache.org> wrote:
> Hi Omar,
>
> On Mon, Feb 20, 2012 at 8:56 AM, Omar Gonzalez
> <om...@gmail.com> wrote:
>
> In the case of RSLs I assume signatures are checked by the client,
> what are the requirements for that?
RSL signatures are checked by the Flash Player.
Flash is a zero-install download-sensitive technology. You hit a web-page
and your app starts streaming in and as soon as you get enough code
downloaded, you can start displaying UI, even while the rest of the code
gets downloaded.
Flex does not leverage that aspect of Flash. Like Java, it has code
libraries which can be substantial in size. Unlike Java, it does not
supported class loading on the fly. You have to preload the code before
making access to a class.
RSLs are essentially JARs that you preload. You can then see that if the
download size is significant, you don't want each app to have to re-download
the RSLs.
A central location is helpful, but that central server can be far away from
the user. Mirrors don't help completely because the Flash security model
cares about the domain name serving the file. If you put the signature you
are looking for in the application binary, it can also be hacked. Browser
caches get flushed. A rogue swf on the same domain serving a swf can
cross-script the RSL.
There is no perfect solution, but what the player does is check exclusively
for Adobe's signature and caches a file by signature in a non-browser cache,
and allows you to load that file into your security context (but not other
non-signed files from the same domain originally serving that file).
I don't see Adobe changing its position on this for now, so Apache Flex
needs to decide what to do given that. Relying on browser caching is about
as good as you can do. You will be exposed to man-in-the-middle. I don't
think we can find a way to know that a file downloaded from one mirror is
the same as one coming from another mirror without downloading it in the
first place.
Also note that many large apps seem to have given up on RSLs because they've
had to hack the classes in the RSLs to fix bugs.
IMHO, RSLs are a temporary hack to a problem of having large amounts of
intertwined classes in the framework. I have a prototype of a framework
that leverage the zero-install capability of Flash much better, which should
eliminate the need for RSLs.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: Signed RSL from Apache
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi Omar,
On Mon, Feb 20, 2012 at 8:56 AM, Omar Gonzalez
<om...@gmail.com> wrote:
> ...RSL stands for runtime shared library. Portions of the Flex SDK are
> compiled into .SWZ files that are(were) signed by Adobe. This would yield
> two benefits, 1.) security and 2.) Flash Player RSL caching at a global
> level (all domains), meaning all sites using a specific version of the Flex
> SDK can be cached only once by a user. Because Adobe will no longer sign
> Apache Flex RSLs we lose #2. Having Apache host RSLs would help us to
> resolve #1 as Adobe will no longer host our RSLs...
Thanks for the explanation, so IIUC RSLs are binary files that are
signed and hosted on http servers. Apache does have a mirroring
structure (see http://www.apache.org/mirrors/ for example), so hosting
is not a problem.
Files released by Apache projects are usually signed using detached
PGP signatures, see http://www.apache.org/dev/release-signing - a
release manager signs the files, and the release is backed by a PMC
vote, making it an act of the foundation.
In the case of RSLs I assume signatures are checked by the client,
what are the requirements for that?
-Bertrand
Re: Signed RSL from Apache
Posted by Omar Gonzalez <om...@gmail.com>.
On Mon, Feb 20, 2012 at 8:50 AM, Bertrand Delacretaz <bdelacretaz@apache.org
> wrote:
> Hi,
>
> On Mon, Feb 20, 2012 at 1:03 AM, jude <fl...@gmail.com> wrote:
> > ..In the whitepaper there was mention that Adobe would not be signing the
> > framework RSL compiled by the Apache Flex project. That's a big hit for
> > downloading every time. Is there a way to get the Apache Flex RSL
> signed?...
>
> I have no idea what RSL is, but I might be able to help from the
> Apache side if you can explain what the use case and technical
> requirements are.
>
> -Bertrand
>
Hi Bertrand,
RSL stands for runtime shared library. Portions of the Flex SDK are
compiled into .SWZ files that are(were) signed by Adobe. This would yield
two benefits, 1.) security and 2.) Flash Player RSL caching at a global
level (all domains), meaning all sites using a specific version of the Flex
SDK can be cached only once by a user. Because Adobe will no longer sign
Apache Flex RSLs we lose #2. Having Apache host RSLs would help us to
resolve #1 as Adobe will no longer host our RSLs. I hope that's clear and
that I've gotten that all correct, someone correct me if I'm wrong here
please.
--
Omar Gonzalez
s9tpepper@apache.org
Re: Signed RSL from Apache
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi,
On Mon, Feb 20, 2012 at 1:03 AM, jude <fl...@gmail.com> wrote:
> ..In the whitepaper there was mention that Adobe would not be signing the
> framework RSL compiled by the Apache Flex project. That's a big hit for
> downloading every time. Is there a way to get the Apache Flex RSL signed?...
I have no idea what RSL is, but I might be able to help from the
Apache side if you can explain what the use case and technical
requirements are.
-Bertrand