incubator-clerezza-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reto Bachmann-Gmuer <r...@apache.org>
Subject Re: -1 Against CLEREZZA-479 commits (was Re: logging in with undereferenceable webid)
Date Wed, 11 May 2011 06:57:43 GMT
I can confirm that I now longer have all permission when using an webid that
cannot be dereferenced or where the key in invalid. In both cases I don't
get an error message but seem to be user anonymous. So I suspend my -1 at
the current stage.

Still I'm sceptical about the current partial solution of the issue. I'm
puzzled by the creation of a test suite requiring such massive changes to
the system under test. I understand a test-suite might require adding some
hooks to the tested system, but here it seems a major redesign is being done
to the whole authentication system for clerezza to be testable with the
suite being implemented. I don't think I'm opposing to this changes but I'd
like them to be under smaller issues describing their scope.

Question regarding the latest commit:
Implementation of AuthenticationMethod can now add principals to the
subject, I assume that with this one can log-in with multiple authentication
methods to gain more permission (e.g. standard set of permission from the
webid, occasionally entering password for admin rights), what I don't
understand is why the implementation of AuthenticationMethod remove
principals (the anonymous principal) that is already associated to the
subject.

Sorry I meant that one should do
> :f install
> mvn:org.apache.clerezza/platform.security.foafssl.test/0.1-incubating-SNAPSHOT
> :f install mvn:org.bouncycastle/bcmail-jdk16/1.46
>
I'm looking forward to a documentation of the test suite. I'd recommend to
use clerezza commands rather than felix-commmands with :f


>
> then one needs to start the test suite.
>
What does this mean? starting the first of the bundles above?


> I need to do something so that at least the second install is not
> necessary.
>
>
> > anyway, the page says:
> > java.security.PrivilegedActionException:
> javax.net.ssl.SSLHandshakeException:
> sun.security.validator.ValidatorException: PKIX path building failed:
> sun.security.provider.certpath.SunCertPathBuilderException: unable to find
> valid certification path to requested target
> yes, that's what it things say when they are not installed recently.
> I think you told me that is now how it used to happen at some point. Any
> idea where one should look to fix that?
>
Well, I think this occurs when acting as client. Afaik we rely solely on
traditional PKI with jvm CA configuration there (I have some code somewhere
to turn this verification off, but obviously this isn't a real solution)



>
> >
> > This is an improvement, since it is what will allow automated testing of
> > the whole thing.
> > As I understood you want a tool to test an arbitrary webid
> implementation. This shouldn't require changes to our implementation as any
> WebId complaint implementation is supposed to pass, and clearly before it
> was at least closer to WebId compliance as it now.
>
> Well yes, but the test suite really helped me debug this. For one you can
> now login with a false certificate and it will tell you exactly why it
> failed.
>
I'm not sure, this sounds like something which should be part of clerezza
rather than an optional test-suite


> Imagine what you would have to do without such a test suite and you had a
> field problem, with some user telling you that he could not log in? Good
> luck.
>
> The UI of the test suit certainly can be improved. I'd love some help
> there.
>
Haven't been using the test-suite yet, is it documented somewhere?


>
> If you are so keen on security, please allow me to think about it and fix
it,
> So keen on security? This whole module is about providing a cryptographic
proof of identity, now this is not working.

 It is working now. Thanks for pointing out the issue.
> I just mean you could give me a few hours of slack to solve the issue.
>
sure, but having small issues (as well as competence with the source-control
tool used) allow to easily revert to last approved version while the issue
is being solved.



>
> > And not in a way to deny users access that should have access (which
> would be bad) but by giving access even with a clearly broken proof and
> allowing anybody to do staff which requires asmin permission. I don't think
> I'm being particularly picky if I ask you to act immediately.
>
> It's done.
>
> >
> > and I'd suggest removing the Apache Felix Web Management Console which
> has a
> > different admin password than the main admin - so you told me - and which
> is
> > bound to leave a back door in every Clerezza installation. That seems
> easy to
> > fix.
> > Not true, it requires the knowledge that the password has to be changes
> there, but it's not a back-door in every installation, this is not to say
> this shouldn't be changed.BUT: What has this to do with the topic, open an
> issue and remove a few lines from storageless parent for a quick fix.
>
> Since you have put the heat on me, I just thought I'd give you something to
> do while I fix the problem :-)
>

You mean I'm obviously lacking work if I have time to complain about a
blatant security whole?

Reto

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message