Saving the credentials by browser on login page

Charles Crouch ccrouch at redhat.com
Wed Sep 26 15:11:29 UTC 2012


does the AS7 console let you save cred's?

----- Original Message -----
> 
> Just backing up a step. Do any other competing products in our space
> do this now?
> 
> 
> 
> 
> On Sep 26, 2012, at 7:08 AM, Jiri Kremser <jkremser at redhat.com>
> wrote:
> 
> > Hi,
> >  thanks for responses.
> > 
> > "The typical GWT solution (from my email) uses one single form for
> > the login process."
> > 
> > That was my first attempt and I agree it would be simpler. It
> > worked but the UI was obviously different (in terms of look and
> > feel), it can be styled by css to look same like SmartGWT, but we
> > use also form validations and error notification area in the form.
> > These are supported only by SmartGWT. If it doesn't mind, I can
> > rewrite it to use the pure gwt for logging in, but I thought we
> > wanted to move away from the pure GWT components.
> > 
> > I am sure the same can be done with SmartGWT.
> > I didn't find the way. The problem is the SmartGWT don't provide
> > any functionality for wrapping the existing HTML elements as I've
> > written few mails ago.
> > *
> > http://stackoverflow.com/questions/9935328/wrapping-html-element-by-smartgwt-widgets?rq=1
> > *
> > http://stackoverflow.com/questions/12564518/wrapping-pre-made-elements-using-smartgwt
> > * http://forums.smartclient.com/showthread.php?t=23739
> > 
> > ..and the login form created by SmartGWT is definitely not
> > recognized by browser as a "login form", so it doesn't provide any
> > saving options for credentials. No wonder, there are so many
> > layers of "divs" and the buttons are represented as html tables,
> > and so on.
> > 
> > 
> > 1) Copying usernames and passwords is risky because the actual
> > strings will be stored in memory variables.
> > 
> > The same thing is happening right now. The SmartGWT form fields are
> > represented by java script variables and the text from it could be
> > extracted right now.
> > Because of the fact the all client code can be fakeable (I hope it
> > is a word:]), the most security checks including authN and authZ
> > should be done completely on the server-side. Here is nice video
> > of GWT security: http://www.youtube.com/watch?v=hKrvY42dw1A. He
> > shows that obfuscation doesn't solve anything.
> > 
> > 2) Having a JSNI method for login is also exploitable. The login
> > process will be at the fingertips of attackers armed with clever
> > XSS attacks. This will enable silent login attempts with
> > absolutely no warning to the user.
> > 
> > here is a code sniped from my compiled project (file
> > 61B0DAF0F7EDA8CBC84C80FE3874EB2A.cache.html, but the name may
> > differ):
> > 
> >  if (statusCode == 200) {
> >  ...
> >   org_rhq_enterprise_gui_coregui_client_UserSessionManager_login__Ljava_lang_String_2Ljava_lang_String_2V(this.org_rhq_enterprise_gui_coregui_client_LoginView$9_val$username,
> >  this.org_rhq_enterprise_gui_coregui_client_LoginView$9_val$password);
> >  ...
> >  }
> > 
> > What stops me now from calling this function right now with the
> > current version and why is JSNI login method a problem (btw. my
> > exposed function has signature doLogin() no params here, the
> > values are taken from the form).
> > 
> > 
> > JK
> > 
> > 
> > 
> > ----- Original Message -----
> > From: "Lukas Krejci" <lkrejci at redhat.com>
> > To: rhq-devel at lists.fedorahosted.org
> > Sent: Wednesday, September 26, 2012 10:53:43 AM
> > Subject: Re: Saving the credentials by browser on login page
> > 
> > On Tuesday, September 25, 2012 17:47:20 Stefan Negrea wrote:
> >> I am concerned too with the security risk of this proposed
> >> approach. The
> >> typical GWT solution (from my email) uses one single form for the
> >> login
> >> process. I am sure the same can be done with smartGWT.
> >> 
> >> I see two problem with the current proposal:
> >> 1) The extra copying between the HTML form and smartGWT form is
> >> exploitable.
> >> Copying usernames and passwords is risky because the actual
> >> strings will be
> >> stored in memory variables.
> > 
> > Are they not stored in the HTML form, too? Like
> > document.getElementById("passwordField").value(); ? If the attacker
> > can get
> > himself to manipulate the DOM on the page, he can extract any info
> > the user
> > enters, no matter if the form is dynamic or static. And there needs
> > to be no
> > copying for that to be possible.
> > 
> >> 2) Having a JSNI method for login is also
> >> exploitable. The login process will be at the fingertips of
> >> attackers armed
> >> with clever XSS attacks. This will enable silent login attempts
> >> with
> >> absolutely no warning to the user.
> >> 
> > 
> > Yes, the exposure of the login method through JSNI makes the attack
> > attempts
> > easier. But the login method has always been there, only with a
> > slightly more
> > obfuscated name. Anyone knowing GWT would be able to deduce the
> > name easily
> > (like Jirka did when he wrote the JSNI impl).
> > 
> >> The solution: use just the HTML form and change the post address
> >> of that
> >> form. Instead of showing the smartGWT form on the login page, make
> >> this
> >> HTML form visible on the webpage. You should just manipulate the
> >> DOM to
> >> change the location of the form in the tree. Rather than making
> >> the
> >> solution more complicated (extra layers of forms), we should work
> >> on
> >> removing any unnecessary elements/code/variables from the login
> >> process.
> >> 
> >> The idea is to use the browser infrastructure for the entire
> >> process. The
> >> security concerns will then shift from our application to the
> >> browser
> >> itself. And that is an acceptable security risk.
> >> 
> > 
> > +1, that would be the ideal solution.
> > 
> >> 
> >> Stefan Negrea
> >> 
> >> ----- Original Message -----
> >> 
> >>> From: "Lukas Krejci" <lkrejci at redhat.com>
> >>> To: rhq-devel at lists.fedorahosted.org
> >>> Sent: Tuesday, September 25, 2012 10:44:13 AM
> >>> Subject: Re: Saving the credentials by browser on login page
> >>> 
> >>> What about constrained environments where users can't install
> >>> their
> >>> own
> >>> browser addons?
> >>> 
> >>> I mean, c'mon. This is a very standard browser feature we're
> >>> talking
> >>> about
> >>> here that we're preventing.
> >>> 
> >>> I personally can see no security threat to having a static HTML
> >>> form
> >>> to do the
> >>> logging in. The server endpoints are still the same, the data
> >>> passed
> >>> to them
> >>> is still the same. It's the server that does the authentication
> >>> and
> >>> no server
> >>> logic is being changed here. Also, no data is stored on the
> >>> client
> >>> side.
> >>> 
> >>> Wrt XSS - maybe the exposure of the doLogin() method makes the
> >>> potential
> >>> breach a bit easier but that method always existed and was being
> >>> translated
> >>> into javascript by GWT compiler. So all Jirka did there was that
> >>> he
> >>> changed a
> >>> a javascript function to have a "nicer name".
> >>> 
> >>> I am all for having another pair(s) of eyes on this, but I think
> >>> we're being a
> >>> bit paranoid here.
> >>> 
> >>> Take a look at the diff
> >>> http://git.fedorahosted.org/cgit/rhq/rhq.git/commit/?h=jkremser/loginSavin
> >>> g&id=36668b80ee7f8caef63bc3b6bdc10768038031e2
> >>> 
> >>> There is no new functionality there - it's just another way of
> >>> calling the
> >>> same method.
> >>> 
> >>> On Tuesday, September 25, 2012 11:11:41 John Mazzitelli wrote:
> >>>> IMO, just publish the grease monkey script and be done with it.
> >>>> 
> >>>> ----- Original Message -----
> >>>> 
> >>>>> I was under the impression that we had already decided that
> >>>>> this
> >>>>> was
> >>>>> a risky proposition? Typically, something like this would get
> >>>>> flagged in a code audit (manual or automated). The thing with
> >>>>> security is that you may not fully understand what you are
> >>>>> exposing
> >>>>> as dangerous until you get hacked.   As JON can control other
> >>>>> servers it could quickly become a severe issue for a customer.
> >>>>> Once
> >>>>> a product gets tainted by a serious security issue it is very
> >>>>> hard
> >>>>> to recover from that kind of publicity.
> >>>>> 
> >>>>> Is there a Red Hat security team that can advise on this?
> >>>>> Perhaps
> >>>>> standard practices...
> >>>>> 
> >>>>> 
> >>>>> -- Mike
> >>>>> 
> >>>>> On Sep 25, 2012, at 6:59 AM, Jiri Kremser <jkremser at redhat.com>
> >>>>> 
> >>>>> wrote:
> >>>>>> Hi,
> >>>>>> 
> >>>>>> I've implemented the issue using the hidden form hack. I've
> >>>>>> found
> >>>>>> only one example of this on the web
> >>>>>> (http://borglin.net/gwt-project/?page_id=467, great blog
> >>>>>> btw.).
> >>>>>> However, the example doesn't use the SmartGWT but pure GWT.
> >>>>>> They
> >>>>>> actually use directly the hidden form for logging in by
> >>>>>> calling
> >>>>>> FormPanel.wrap(Document.get().getElementById(LOGINFORM_ID))
> >>>>>> and
> >>>>>> rendering it. It wraps an existing element with pure GWT
> >>>>>> component. SmartGWT, unfortunately, doesn't support such
> >>>>>> functionality (I tried smartclient forum, stackoverflow and
> >>>>>> JavaDoc :]), so I had to "mirror" the values between the two
> >>>>>> forms (the hidden one and the SmartGWT one), and when
> >>>>>> submitting
> >>>>>> the visible form, the submit is invoked on the hidden form too
> >>>>>> which calls JSNI method for logging in.
> >>>>>> 
> >>>>>> It works without problems in Chrome21 and IE8. FF 10 asks for
> >>>>>> saving the credentials, but fills it only if the user access
> >>>>>> the
> >>>>>> page by pressing the logout (=> don't fill it if you access
> >>>>>> the
> >>>>>> page directly, strange).
> >>>>>> 
> >>>>>> The changes are pushed in git branch jkremser/loginSaving
> >>>>>> 
> >>>>>> Concerning security:
> >>>>>> * I had to expose the "doLogin()" function via JSNI in order
> >>>>>> to
> >>>>>> be
> >>>>>> able to call it from Java Script. doLogin() reads the
> >>>>>> credentials
> >>>>>> from the hidden form and with them performs the
> >>>>>> login(user,pass)
> >>>>>> and subsequently sends POST to portal's struts action
> >>>>>> (j_security_check.do). The only risk, I can see, is that
> >>>>>> attacker
> >>>>>> can make the hidden form visible and type the credentials
> >>>>>> directly
> >>>>>> to it (or from JavaScript) bypassing the form validation on
> >>>>>> the
> >>>>>> proper login form. However, right now we validate only if the
> >>>>>> username and password is not "".
> >>>>>> 
> >>>>>> * Credentials are NOT stored by the application logic. Browser
> >>>>>> asks
> >>>>>> the user and stores it if he/she confirms, like many other web
> >>>>>> application. Here, one can say, it is not a good practice and
> >>>>>> we
> >>>>>> should avoid it. We can discuss it. It depends, If the online
> >>>>>> banking app suggests me saving the password I would probably
> >>>>>> change the bank. I am not saying RHQ is not so critical (it
> >>>>>> may
> >>>>>> be
> >>>>>> in many cases), but don't forget it is only option. User can
> >>>>>> turn
> >>>>>> it off or use it, it is up to him. Same thing holds for
> >>>>>> securing
> >>>>>> the webapp with SSL + certificate. Because without running it
> >>>>>> on
> >>>>>> SSL it is quite funny to talk about security aspects, and send
> >>>>>> the
> >>>>>> password in plain text :]
> >>>>>> 
> >>>>>> * Other risk may come from the fact the login form (the hidden
> >>>>>> variant) is now present in the static html content, so if the
> >>>>>> webapp is hosted on public IP, some crawler or bot can
> >>>>>> potentially
> >>>>>> mark this page as hackable. Counterargument could be that the
> >>>>>> same
> >>>>>> thing is possible now after evaluating the JavaScript.
> >>>>>> 
> >>>>>> 
> >>>>>> I've also prepared the Grease Monkey script for FF and placed
> >>>>>> it to
> >>>>>> /etc/dev-utils. It fills the credentials if you press alt+c
> >>>>>> and
> >>>>>> it
> >>>>>> works well also in Chrome with Tampermonkey add-on. I haven't
> >>>>>> tried it with the IE yet.
> >>>>>> 
> >>>>>> JK
> >>>>>> 
> >>>>>> 
> >>>>>> ----- Original Message -----
> >>>>>> From: "Stefan Negrea" <snegrea at redhat.com>
> >>>>>> To: rhq-devel at lists.fedorahosted.org
> >>>>>> Sent: Wednesday, September 5, 2012 9:27:28 PM
> >>>>>> Subject: Re: Saving the credentials by browser on login page
> >>>>>> 
> >>>>>> Hello,
> >>>>>> 
> >>>>>> 
> >>>>>> This is a known issue with GWT applications and the fix is
> >>>>>> simple.
> >>>>>> This section explains well the strategy:
> >>>>>> http://code.google.com/p/google-web-toolkit-incubator/wiki/LoginSecu
> >>>>>> rity
> >>>>>> FAQ#auto-complete_and_GWT
> >>>>>> 
> >>>>>> 
> >>>>>> Storing passwords or usernames in cookies is dangerous!
> >>>>>> 
> >>>>>> 
> >>>>>> Thank you,
> >>>>>> Stefan
> >>>>>> 
> >>>>>> ----- Original Message -----
> >>>>>> 
> >>>>>>> From: "Lukas Krejci" <lkrejci at redhat.com>
> >>>>>>> To: rhq-devel at lists.fedorahosted.org
> >>>>>>> Sent: Friday, August 31, 2012 8:16:53 AM
> >>>>>>> Subject: Re: Saving the credentials by browser on login page
> >>>>>>> 
> >>>>>>> On Friday, August 31, 2012 09:03:58 John Mazzitelli wrote:
> >>>>>>>> I would disagree that it is a "rather big" usability issue.
> >>>>>>>> Relative to all
> >>>>>>>> the other issues in the UI, I would put this low on the
> >>>>>>>> list.
> >>>>>>> 
> >>>>>>> Well, this one is right in the face of everybody using RHQ.
> >>>>>>> It's
> >>>>>>> the
> >>>>>>> first
> >>>>>>> thing they see and there's no going around that.
> >>>>>>> Something along the lines of "they can't get right even such
> >>>>>>> a
> >>>>>>> simple
> >>>>>>> thing as
> >>>>>>> password completion? They suck!"
> >>>>>>> 
> >>>>>>>> I would agree that if some solution can simply enable the
> >>>>>>>> browser
> >>>>>>>> to do "its
> >>>>>>>> thing", that would be nice. But I heard things like "storing
> >>>>>>>> the
> >>>>>>>> password
> >>>>>>>> in a cookie" and things like that - that's what I say we
> >>>>>>>> should
> >>>>>>>> not
> >>>>>>>> even
> >>>>>>>> entertain the thought.
> >>>>>>> 
> >>>>>>> +100
> >>>>>>> 
> >>>>>>>> If there is some magic to put some hidden dummy form
> >>>>>>>> in the page to trick the browser to remember the info using
> >>>>>>>> its
> >>>>>>>> normal
> >>>>>>>> mechanisms, then that would be different.
> >>>>>>> 
> >>>>>>> I actually thought this was the plan.
> >>>>>>> 
> >>>>>>>> But again, relative to everything else, this would be low on
> >>>>>>>> the
> >>>>>>>> list to
> >>>>>>>> implement IMO as we've got lots of other stuff that would be
> >>>>>>>> higher
> >>>>>>>> priority (is there even a BZ on this?). As Jiri mentioned
> >>>>>>>> earlier,
> >>>>>>>> for
> >>>>>>>> devs, it would probably be nice to have some a greasemonkey
> >>>>>>>> script
> >>>>>>>> to help
> >>>>>>>> out here. That would be a good solution for devs whose
> >>>>>>>> fingers
> >>>>>>>> hurt
> >>>>>>>> typing
> >>>>>>>> rhqadmin :}
> >>>>>>>> 
> >>>>>>>> ----- Original Message -----
> >>>>>>>> 
> >>>>>>>>> Well, this whole thing is not about us implementing some
> >>>>>>>>> convenience
> >>>>>>>>> for the users but about us NOT PREVENTING a convenience
> >>>>>>>>> function
> >>>>>>>>> that browsers implement.
> >>>>>>>>> 
> >>>>>>>>> I see a big difference there. It is a standard feature of
> >>>>>>>>> all
> >>>>>>>>> browsers to offer to "save passwords" on any page where
> >>>>>>>>> people
> >>>>>>>>> put
> >>>>>>>>> in credentials. This is not possible on RHQ login page. It
> >>>>>>>>> is
> >>>>>>>>> not
> >>>>>>>>> for us to answer the security aspects of this solution or
> >>>>>>>>> to
> >>>>>>>>> try
> >>>>>>>>> to
> >>>>>>>>> be "smarter" than the browsers are.
> >>>>>>>>> 
> >>>>>>>>> For me this is a rather big usability issue.
> >>>>>>>>> 
> >>>>>>>>> Lukas
> >>>>>>>>> 
> >>>>>>>>> ----- Original Message -----
> >>>>>>>>> 
> >>>>>>>>>> From: "John Mazzitelli" <mazz at redhat.com>
> >>>>>>>>>> To: rhq-devel at lists.fedorahosted.org
> >>>>>>>>>> Sent: Thursday, August 30, 2012 6:16:55 PM
> >>>>>>>>>> Subject: Re: Saving the credentials by browser on login
> >>>>>>>>>> page
> >>>>>>>>>> 
> >>>>>>>>>> IMO, I would recommend staying far away from doing
> >>>>>>>>>> anything
> >>>>>>>>>> "for
> >>>>>>>>>> convenience" that has anything to do with security. This
> >>>>>>>>>> is
> >>>>>>>>>> asking
> >>>>>>>>>> for trouble.
> >>>>>>>>>> 
> >>>>>>>>>> It is best if something like "my password was hacked" can
> >>>>>>>>>> be
> >>>>>>>>>> 100%
> >>>>>>>>>> blamed on, say, the browser or a weak password (as opposed
> >>>>>>>>>> to
> >>>>>>>>>> it
> >>>>>>>>>> being blamed on RHQ :-)
> >>>>>>>>>> 
> >>>>>>>>>> Seriously, the minute you start attempting to implement
> >>>>>>>>>> something
> >>>>>>>>>> around security like this, you WILL get people looking
> >>>>>>>>>> very
> >>>>>>>>>> closely
> >>>>>>>>>> at your code and dollars to donuts, some hole some where
> >>>>>>>>>> will
> >>>>>>>>>> be
> >>>>>>>>>> found (which I can attest to with the "convenience"
> >>>>>>>>>> feature
> >>>>>>>>>> we
> >>>>>>>>>> had
> >>>>>>>>>> for the agent token stuff a while ago that we ended up
> >>>>>>>>>> removing).
> >>>>>>>>>> 
> >>>>>>>>>> As the guy on that old TV cop show used to say, "Let's be
> >>>>>>>>>> careful
> >>>>>>>>>> out
> >>>>>>>>>> there!"
> >>>>>>>>>> 
> >>>>>>>>>> P.S. Your fingers learn to type "rhqadmin" really fast
> >>>>>>>>>> after
> >>>>>>>>>> you do
> >>>>>>>>>> it for a while. :)
> >>>>>>>>>> 
> >>>>>>>>>> ----- Original Message -----
> >>>>>>>>>> 
> >>>>>>>>>>> IMO storing the password is a poor choice (even if done
> >>>>>>>>>>> properly)
> >>>>>>>>>>> and
> >>>>>>>>>>> may not be welcomed as a feature by some organizations.
> >>>>>>>>>>> However,
> >>>>>>>>>>> storing the user name might be nice but even that should
> >>>>>>>>>>> not
> >>>>>>>>>>> be
> >>>>>>>>>>> in
> >>>>>>>>>>> plain text. Here is another link to complement the link
> >>>>>>>>>>> below:
> >>>>>>>>>>> http://crackstation.net/hashing-security.htm
> >>>>>>>>>>> 
> >>>>>>>>>>> 
> >>>>>>>>>>> Obviously this is a sensitive area.
> >>>>>>>>>>> 
> >>>>>>>>>>> 
> >>>>>>>>>>> 
> >>>>>>>>>>> HTML5 local storage is another option to cookies. Cookies
> >>>>>>>>>>> get
> >>>>>>>>>>> sent
> >>>>>>>>>>> with every request including images and gwt-rpc. This way
> >>>>>>>>>>> the
> >>>>>>>>>>> username would never leave the client (except for the
> >>>>>>>>>>> actual
> >>>>>>>>>>> login).
> >>>>>>>>>>> FF and IE9 have support for it and there is a polyfill
> >>>>>>>>>>> for
> >>>>>>>>>>> web
> >>>>>>>>>>> storage in IE8.
> >>>>>>>>>>> 
> >>>>>>>>>>> 
> >>>>>>>>>>> 
> >>>>>>>>>>> 
> >>>>>>>>>>> 
> >>>>>>>>>>> 
> >>>>>>>>>>> 
> >>>>>>>>>>> 
> >>>>>>>>>>> On Aug 30, 2012, at 7:36 AM, Jiri Kremser <
> >>>>>>>>>>> jkremser at redhat.com >
> >>>>>>>>>>> wrote:
> >>>>>>>>>>> 
> >>>>>>>>>>> 
> >>>>>>>>>>> Hi,
> >>>>>>>>>>> I've found this page [1] and I am trying to get this idea
> >>>>>>>>>>> working.
> >>>>>>>>>>> Lukas suggested the values can be obtained from the
> >>>>>>>>>>> hidden
> >>>>>>>>>>> form
> >>>>>>>>>>> by
> >>>>>>>>>>> JS (DOM manipulation). But there will be probably
> >>>>>>>>>>> necessary
> >>>>>>>>>>> to do
> >>>>>>>>>>> the other way i.e. to fill the form and submit it with
> >>>>>>>>>>> some
> >>>>>>>>>>> kind
> >>>>>>>>>>> of
> >>>>>>>>>>> no-op somehow on the background to let the browser to
> >>>>>>>>>>> store
> >>>>>>>>>>> it.
> >>>>>>>>>>> Other option could be to use the cookies
> >>>>>>>>>>> com.google.gwt.user.client.Cookies.{get|set}Value() but I
> >>>>>>>>>>> am
> >>>>>>>>>>> not
> >>>>>>>>>>> sure about storing the password in plaintext somewhere in
> >>>>>>>>>>> the
> >>>>>>>>>>> cookie
> >>>>>>>>>>> without asking the user.
> >>>>>>>>>>> 
> >>>>>>>>>>> Browser does basically the same, but at least it asks :]
> >>>>>>>>>>> Yes, but this is not secure either.
> >>>>>>>>>>> 
> >>>>>>>>>>> 
> >>>>>>>>>>> 
> >>>>>>>>>>> 
> >>>>>>>>>>> 
> >>>>>>>>>>> [1]
> >>>>>>>>>>> http://code.google.com/p/google-web-toolkit-incubator/wiki/Logi
> >>>>>>>>>>> nSec
> >>>>>>>>>>> uri
> >>>>>>>>>>> tyFAQ#auto-complete_and_GWT
> >>>>>>>>>>> _______________________________________________
> >>>>>>>>>>> rhq-devel mailing list
> >>>>>>>>>>> rhq-devel at lists.fedorahosted.org
> >>>>>>>>>>> https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
> >>>>>>>>>>> 
> >>>>>>>>>>> 
> >>>>>>>>>>> _______________________________________________
> >>>>>>>>>>> rhq-devel mailing list
> >>>>>>>>>>> rhq-devel at lists.fedorahosted.org
> >>>>>>>>>>> https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
> >>>>>>>>>> 
> >>>>>>>>>> _______________________________________________
> >>>>>>>>>> rhq-devel mailing list
> >>>>>>>>>> rhq-devel at lists.fedorahosted.org
> >>>>>>>>>> https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
> >>>>>>>>> 
> >>>>>>>>> _______________________________________________
> >>>>>>>>> rhq-devel mailing list
> >>>>>>>>> rhq-devel at lists.fedorahosted.org
> >>>>>>>>> https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
> >>>>>>>> 
> >>>>>>>> _______________________________________________
> >>>>>>>> rhq-devel mailing list
> >>>>>>>> rhq-devel at lists.fedorahosted.org
> >>>>>>>> https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
> >>>>>>> 
> >>>>>>> _______________________________________________
> >>>>>>> rhq-devel mailing list
> >>>>>>> rhq-devel at lists.fedorahosted.org
> >>>>>>> https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
> >>>>>> 
> >>>>>> _______________________________________________
> >>>>>> rhq-devel mailing list
> >>>>>> rhq-devel at lists.fedorahosted.org
> >>>>>> https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
> >>>>>> _______________________________________________
> >>>>>> rhq-devel mailing list
> >>>>>> rhq-devel at lists.fedorahosted.org
> >>>>>> https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
> >>>>> 
> >>>>> _______________________________________________
> >>>>> rhq-devel mailing list
> >>>>> rhq-devel at lists.fedorahosted.org
> >>>>> https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
> >>>> 
> >>>> _______________________________________________
> >>>> rhq-devel mailing list
> >>>> rhq-devel at lists.fedorahosted.org
> >>>> https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
> >>> 
> >>> _______________________________________________
> >>> rhq-devel mailing list
> >>> rhq-devel at lists.fedorahosted.org
> >>> https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
> >> 
> >> _______________________________________________
> >> rhq-devel mailing list
> >> rhq-devel at lists.fedorahosted.org
> >> https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
> > _______________________________________________
> > rhq-devel mailing list
> > rhq-devel at lists.fedorahosted.org
> > https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
> > _______________________________________________
> > rhq-devel mailing list
> > rhq-devel at lists.fedorahosted.org
> > https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
> 
> _______________________________________________
> rhq-devel mailing list
> rhq-devel at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
> 
> 
> 


More information about the rhq-devel mailing list