Re: [PATCH] git-cvsserver: handle change type T

Paolo Bonzini [off-list ref] writes:

Junio C Hamano wrote:
...

quoted

Do cvs clients even know how to handle symlinks, or will this patch just
start sending the readlink(2) result as if it is just a regular file
contents?

It was before too.  The problem arises if one found the problem,
deleted the symlink, added the regular file -- and now cvsserver stops
working at all. :-(

Yeah, I see why $git_perms fall back to "rw" now around l.2620 -- if file
mode is 120000, none of the r/w/x would have been added in.

Martin, likes, dislikes?

On Mon, Mar 17, 2008 at 9:01 PM, Junio C Hamano [off-list ref] wrote:

 Martin, likes, dislikes?

Hmmm. Trying to make up my mind on this. It looks like symlink support
is broken in cvsserver, it is something we did not even consider, so I
am trying to visualise _how_ broken it is, and what it would take to

 - refuse to handle symlinks (temporarily, until we can guarantee our
handling is sane)
 - translate symlinks that are internal - hard, and probably not even
a good idea
 - handle symlinks directly - is the client safe from malicious symlinks?

I have never used symlinks with either git or cvs, so I am unsure as
to whether their handling is compatible. Do either of them perform any
sanity checks on the targetof the symlink?

cheers,



m

I have never used symlinks with either git or cvs, so I am unsure as
to whether their handling is compatible. Do either of them perform any
sanity checks on the targetof the symlink?

I doubt that CVS actually supports symlinks.  git makes no sanity checks.

Paolo