openid branch
Patrick Aljord
I've just added support for openid here:
http://gitorious.org/projects/gitorious/repos/patcitos-clone-latest
I don't have time to work on specs at least for now so if somebody has
time do it (all specs still pass though, it's just that new ones
should be written to support openid) don't hesitate.
Here is how it works:
OpenID users don't need to register, they can just login and then
their account is created automatically on first login picking up their
openid "nickname" as login (so 0 forms to fill on registration!). If
login already exists on gitorious.org, a message is sent to the user
to modify his "openid persona" or create a new "openid persona" with a
link to his openid provider so he/she can just do that.
I didn't add support for multiple openid because people can just
modify their openid on their account page and if their openid provider
is down they can ask for gitorious to send them a new password (if you
think this sucks because email is so insecure, you should know that
openid too resides on email, if you forget your openid password they
send it to you by mail so if your email is hacked your openid is
hacked too). Anyway, I think that multiple openid is nice but not
mandatory so if you have time add it :)
Any comments welcome.
Pat
Vincent
Hey all,
I've just added support for openid here:
http://gitorious.org/projects/gitorious/repos/patcitos-clone-latest
I don't have time to work on specs at least for now so if somebody has
time do it (all specs still pass though, it's just that new ones
should be written to support openid) don't hesitate.
Here is how it works:
OpenID users don't need to register, they can just login and then
their account is created automatically on first login picking up their
openid "nickname" as login (so 0 forms to fill on registration!). If
login already exists on gitorious.org, a message is sent to the user
to modify his "openid persona" or create a new "openid persona" with a
link to his openid provider so he/she can just do that.
Is it also possible to link your OpenID to your existing account? And perhaps change it later on?
I didn't add support for multiple openid because people can just
modify their openid on their account page and if their openid provider
is down they can ask for gitorious to send them a new password (if you
think this sucks because email is so insecure, you should know that
openid too resides on email, if you forget your openid password they
send it to you by mail so if your email is hacked your openid is
hacked too).
Actually, that's not entirely true, because it largely depends on your OpenID provider. For example, myopenid.com relies on email, but there are also providers that rely on other methods (e.g. https://openid.ee/about/english).
You could also start your own OpenID server and then you'd need e.g. FTP access :)
Anyway, I think that multiple openid is nice but not
mandatory so if you have time add it :)
I'd love OpenID support, so a +1 from me :)
Any comments welcome.
Pat
Best,
--
Vincent
Patrick Aljord
>
> Is it also possible to link your OpenID to your existing account? And
> perhaps change it later on?
>
Yes, you can login with your existing account, go to the My
Account/edit Details section and add/edit your openid from there.
>
> Actually, that's not entirely true, because it largely depends on your
> OpenID provider. For example, myopenid.com relies on email, but there are
> also providers that rely on other methods (e.g.
> https://openid.ee/about/english).
> You could also start your own OpenID server and then you'd need e.g. FTP
> access :)
good point though that would concern 0.001% of users, at least for now :)
> > Anyway, I think that multiple openid is nice but not
> > mandatory so if you have time add it :)
>
> I'd love OpenID support, so a +1 from me :)
>
OpenID is there already, that was line was about "multiple openid" :)
Cheers,
Pat
Vincent
On Mon, Mar 24, 2008 at 4:45 AM, Vincent <imn...@gmail.com> wrote:
>
> Is it also possible to link your OpenID to your existing account? And
> perhaps change it later on?
>
Yes, you can login with your existing account, go to the My
Account/edit Details section and add/edit your openid from there.
>
> Actually, that's not entirely true, because it largely depends on your
> OpenID provider. For example, myopenid.com relies on email, but there are
> also providers that rely on other methods (e.g.
> https://openid.ee/about/english).
> You could also start your own OpenID server and then you'd need e.g. FTP
> access :)
good point though that would concern 0.001% of users, at least for now :)
The same holds true for the amount of people arguing that email is insecure, isn't it? ;-)
> > Anyway, I think that multiple openid is nice but not
> > mandatory so if you have time add it :)
>
> I'd love OpenID support, so a +1 from me :)
>
OpenID is there already, that was line was about "multiple openid" :)
Then interpret that line as "I'd like it live on gitorious.org" while I go and bang my head against the wall...
Cheers,
Pat
Best,
--
Vincent
Patrick Aljord
> Then interpret that line as "I'd like it live on gitorious.org" while I go
> and bang my head against the wall...
>
heh me too but that doesn't depend on me.
Meanwhile, here is a couple of screenies:
http://p80.free.fr/gitorious.png //link from the register page to openid login
http://p80.free.fr/gitorious1.png
http://p80.free.fr/gitorious2.png
very impressive isn't it ;)
Sam Vilain
> I didn't add support for multiple openid because people can just
> modify their openid on their account page and if their openid provider
> is down they can ask for gitorious to send them a new password (if you
> think this sucks because email is so insecure, you should know that
> openid too resides on email, if you forget your openid password they
> send it to you by mail so if your email is hacked your openid is
> hacked too).
I know that other people have commented on this inaccuracy, but I think
it's worth pointing out that the weak link is actually the URL; it's up
to the OpenID provider how they choose to recover from lost password
scenarios.
In the regular case, with an OpenID URL of "taichi.geek.nz", DNS is the
weakest link; all you are proving in this instance is that you can exert
some level of control over the servers that those DNS records point to.
If the *client* of the OpenID (ie, the site you are authenticating to)
knows how to do HTTPS, then you could try the https:// version of a URL
instead. In this instance you are proving you know how to create X.509
certificates and get them authorized by an agent, and set them up on a
web server, and get that running OpenID. Which is no mean feat! ;)
Other ways that cryptography can be used to enhance the authenticity of
an OpenID include DNSSec, although this is currently still in very early
days with little support. This would be something of an automatic
enhancement, so long as you can figure out that the domain in question
has DNSSec records.
OpenID support is an interesting direction to take gitorious in; however
it does not satisfy the property that authentication that a push was
permitted to take place must be gathered without having taken part in
that push. If that could happen, then all mirrors could be read-write,
as the mirroring process would work by checking those push
authentication breadcrumbs. And a distributed network of sites, that
anyone can push forks to and contribute hosting of, would IMHO be
significant achievement.
Sam.
Johan Sørensen
> OpenID support is an interesting direction to take gitorious in; however
> it does not satisfy the property that authentication that a push was
> permitted to take place must be gathered without having taken part in
> that push. If that could happen, then all mirrors could be read-write,
> as the mirroring process would work by checking those push
> authentication breadcrumbs. And a distributed network of sites, that
> anyone can push forks to and contribute hosting of, would IMHO be
> significant achievement.
I'm not quite sure I follow the first few sentences there? You mean in
the sense that I can validate the integrity of a git mirror, or that
if I push to mirrorX I could "bless" to automatically replicate/push
those changes to mirrorY + mirrorZ?
I do however agree with the last part there. In fact one of my initial
ideas for gitorious was simply a looking-glass of sorts that could
provide a "feed" of updates in all the published clones of a repos.
For my own practical needs it went from there and turned into what
gitorious currently is. But I definitely still think the idea of a
more distributed network of sites is worth pursuing in the long run.
>
> Sam.
Cheers,
JS
Sam Vilain
>> OpenID support is an interesting direction to take gitorious in; however
>> it does not satisfy the property that authentication that a push was
>> permitted to take place must be gathered without having taken part in
>> that push. If that could happen, then all mirrors could be read-write,
>> as the mirroring process would work by checking those push
>> authentication breadcrumbs. And a distributed network of sites, that
>> anyone can push forks to and contribute hosting of, would IMHO be
>> significant achievement.
>
> I'm not quite sure I follow the first few sentences there? You mean in
> the sense that I can validate the integrity of a git mirror, or that
> if I push to mirrorX I could "bless" to automatically replicate/push
> those changes to mirrorY + mirrorZ?
More the latter.
Consider PGP signed tags. They can be replicated to every node, and the
signature on them verified. You don't need to authenticate that the
push is permitted, just that the tag is authentic. A mirror site could
replicate only changes which it can verify the signatures of. Then it
has to trust no-one - except the record that a particular PGP key is
permitted to make tags in a particular project.
The prototype I posted on this list was subsequently commented on on the
git mailing list; there was even some discussion of integrating support
for it into git-push.
http://marc.info/?l=git&m=120149355632377&w=2
However, another adequate solution might be to keep a "master" git
archive which records information required for replication;
- a list of projects, and forks. copies of the packed-refs file from
each project/fork.
- for each project, what things are currently allowed to push to
which refs/ spaces.
- PGP signatures embedded in the commits for an overall authentication
(this is something of a repeat of a design I posted in the above thread)
So, in this master record, it will be noted that such-and-such SSH key
has access to push to all refs under the forks of project FOO, etc.
Updates to this overall history can be hourly,
I'm leaving it as a bit of an exercise for the reader how this is turned
into a fully decentralised system - but if you can get the above data
output, then I'll see what I can do about getting repo.or.cz to publish
equivalent details and perhaps it will emerge as a standard.
With decentralisation, the primary function of each of the repo-like
sites out there is to declare their own namespace and register projects
within them - much like the CTAN or CPAN archives. The users of the
repositories can then themselves contribute to the hosting, while not
losing any of the desirable characteristics of centralised hosting
(chiefly, one place to go looking for projects and project updates).
> I do however agree with the last part there. In fact one of my initial
> ideas for gitorious was simply a looking-glass of sorts that could
> provide a "feed" of updates in all the published clones of a repos.
> For my own practical needs it went from there and turned into what
> gitorious currently is. But I definitely still think the idea of a
> more distributed network of sites is worth pursuing in the long run.
Cool, I think we're thinking along similar lines!
Sam.