Community
Participate
Working Groups
If I try to clone the org.eclipse.ptp.git repo, it fails with: greg:ptp greg$ git clone git://git.eclipse.org/gitroot/ptp/org.eclipse.ptp.git Cloning into org.eclipse.ptp... remote: fatal: loose object f64696502c671b8b0c26807b2152737d8b2b44c1 (stored in ./objects/f6/4696502c671b8b0c26807b2152737d8b2b44c1) is corrupt remote: aborting due to possible repository corruption on the remote side.
Permissions on the mentioned file are 440 and owned by wwwrun. Looks to me like the https setup is incorrect.
Matt mentions it's an ACL issue. I'm wondering how safe https access to the git repos is.
It looks like Matt has fixed the permissions so the build is working again. I can't tell you what a relief it is that this is not a corrupt repo!
(In reply to comment #2) Well, since it's not really corruption of the object but 'no read permission' for anonymous users(which says to me the error message is incomplete) I think https is 'safe'. We have 17 projects using https and I think this might be the second time the ACls have gone funny(on a Git repo at least). -M.
> > We have 17 projects using https and I think this might be the second time the > ACls have gone funny(on a Git repo at least). > Mind educating me? This sounds like some use https and some do not. Why wouldn't they all? That's pretty important to do, right? (so committer passwords, when used, are not transmitted in the raw)?
(In reply to comment #5) > Why wouldn't they all? That's pretty important to do, right? (so committer > passwords, when used, are not transmitted in the raw)? Well, by default there is only *one* way to push data to Eclipse.org(regardless of VCS): ssh . So while you can read anonymously you can't change anything. However some committers are behind corporate firewalls, and their respective IT departments ban ssh connections and will only allow HTTPS(we don't allow updates via HTTP period). In summary: Write access via HTTPS is 'opt in', if you don't need it, we agree and only allow ssh. -M.
(In reply to comment #6) > (In reply to comment #5) > > > Why wouldn't they all? That's pretty important to do, right? (so committer > > passwords, when used, are not transmitted in the raw)? > > Well, by default there is only *one* way to push data to Eclipse.org(regardless > of VCS): ssh . Ah, thank you, I somehow thought this was an http vs https issue. Thanks as always for explaining.. So, any idea how permissions get "messed up"? Anything on the SUSE bulletins? :)
(In reply to comment #7) > So, any idea how permissions get "messed up"? Anything on the SUSE bulletins? > :) I haven't seen anything in the Suse bulletins. Based on the observed behavior there is a 1 in N chance that when the acls are created that the 'default' mask gets incorrectly computed(winds up being 440(or 400) rather than 777). I think I've seen this maybe 10 times in 5 years. I've added some verbage to the Git entry on our wiki to explain this potential problem, and have added a link to this bug. -M.
> Mind educating me? This sounds like some use https and some do not. Why > wouldn't they all? That's pretty important to do, right? (so committer > passwords, when used, are not transmitted in the raw)? Just in the "FWIW" department.... http is enabled by default, but it is not configured at all for authentication. So even if someone supplies valid committer credentials via http, the commit will never succeed. The "turning on https" magic that we do is link the https-accessible git repo to the LDAP group that owns it. Since we have separate Apache config files for http and for https, the separation is quite clear (we can't mistakenly enable commits over plain http).
