Bug 456947 - JGit client vulnerability in Eclipse (CVE-2014-9390)
Summary: JGit client vulnerability in Eclipse (CVE-2014-9390)
Status: RESOLVED FIXED
Alias: None
Product: Community
Classification: Eclipse Foundation
Component: Cross-Project (show other bugs)
Version: unspecified   Edit
Hardware: PC Linux
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: David Williams CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-01-07 11:44 EST by Denis Roy CLA
Modified: 2015-04-23 15:39 EDT (History)
9 users (show)

See Also:


Attachments
Main "difference" between SR1 repo and 201501121000 repo (4.83 KB, text/plain)
2015-01-09 08:50 EST, David Williams CLA
no flags Details
"deep" difference between repos, showing changes in metadata. (21.31 KB, text/plain)
2015-01-09 08:52 EST, David Williams CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Denis Roy CLA 2015-01-07 11:44:30 EST
https://github.com/blog/1938-vulnerability-announced-update-your-git-clients

In late December a vulnerability was found in Git (and Eclipse's jGit) that mainly affects Windows and Mac Git clients.

I believe jGit (and eGit) has/have been fixed[1], and I think we should put a hot fix out to our community.  At the very least, this would be a great opportunity to test our abilility to deploy such security hot-fixes.



Changes Dec. 18+
http://git.eclipse.org/c/jgit/jgit.git/log/
Comment 1 Bouchet Stéphane CLA 2015-01-07 12:00:25 EST
yes, Egit already deployed a fix :
https://www.eclipse.org/forums/index.php/t/918198/
Comment 2 David Williams CLA 2015-01-07 13:06:38 EST
Adding Matthias to CC as I'd like to get some "authoritative" information about the release that has the fix, 3.4.2, before deciding on the best way to fix this. 

Matthias, is is only the security bug that was fixed between your between your "SR1 repo", 

/home/data/httpd/download.eclipse.org/egit/updates-3.4.1

and the "fix repo"

/home/data/httpd/download.eclipse.org/egit/updates-3.4.2

I can tell from looking that "all" the versions/qualifiers increased, but think that's just your build methodology and not an indication of "change". 

Also, does "using JGit 3.4.2" pretty much require that (an EGit user) also have EGit 3.4.2? (i.e. is there a "strong" coupling?). And if so, similar question for EGit, then, did anything change between EGit 3.4.2 and 3.4.1? 

From reading the "release notes" at 
https://projects.eclipse.org/projects/technology.egit/releases/3.4.2
is sounds like this security issue is the only thing that changed, but, would like a "human verification". (I know, I could "diff" in Git, and other techniques ... but, still prefer that JGit/EGit team be involved. 

Last question for JGit/EGit teams: will your Luna SR2 contribution be something other than 3.4.2? I'm guessing you'd move to next minor version or something? (If history is any guide). -- Just want to be sure that SR2 "updates" correctly, in both cases: a) user has installed the off-cycle fix. b) user has not installed the off-cycle fix. 

Would you, the JGit and EGit teams would have any concerns about providing this off-cycle fix to Sim. Release repo? and EPP packages? That is, any risk you know about that we don't? Such as "in the wild" would anyone have "mistakenly" created their repo with "*.Git" which would no longer work? 


For more background: one reason we "got to this point" is in some discussion with Denis, Markus and I reminded him that people with an EPP package installed would not get the fix "automatically", just from doing "check for updates". So this proposal is to basically make "getting the fix" easier, so that even casual users would likely to get it. Though, of course, there is no guarantee they would update their client -- and Denis has said he will update the "server side" code that helps lesson the problem, as mentioned in the original advisory: 

http://article.gmane.org/gmane.linux.kernel/1853266
<quote>
Even though the issue may not affect Linux users, if you are a
hosting service whose users may fetch from your service to Windows
or Mac OS X machines, you are strongly encouraged to update to
protect such users who use existing versions of Git.
</quote>

Guess we need a bug open for that too? :) 

Thanks all,
Comment 3 David Williams CLA 2015-01-07 14:14:43 EST
I've opened bug 456957 to track the "server side" fix. 

As for "client side", The easiest way to fix is simply to copy the Egit repo at 
/home/data/httpd/download.eclipse.org/egit/updates-3.4.2
to the .../releases/luna/ 
repo, and update the composite files, and ?add? the mirror URLs (appears EGit/JGit don't have the mirrors URL attribute?!) 

This "quick fix" would allow the EPP packages to be rebuilt, with minimal fuss, I believe. 

Markus, to build EPP, do you use .../releases/luna URL, or 
.../releases/luna/201409261001 URL? 

If the latter, to fix with composites, we'd have to "copy" the current contents of /releases/luna/201409261001 "down" a level, replace it with composite files, and then add the EGit/JGit repo "under" /releases/luna/201409261001. 

And, of course, there is the traditional approach, of using the b3 aggregator, where the "input" for all projects is simply Luna SR1, except for EGit/JGit which I would update to .../egit/updates-3.4.2. 

The later is probably safest ... just because it would catch the (very) rare possibility that someone specified a "tight" dependency on EGit/JGit. 

Originally I was thinking of the first option, since easier, but as I typed, am now leaning towards the last, just so the "fixed repo" is cleanly in a "new spot", has proper mirroring set, etc.
Comment 4 Markus Knauer CLA 2015-01-07 15:02:48 EST
Last week I pushed a change to Gerrit to test a SR1a build of the packages

  https://git.eclipse.org/r/#/c/38839/

The results are currently available from a Hudson verification job at

  https://hudson.eclipse.org/packaging/job/epp-tycho-build.gerrit/93/

In addition to the Luna SR1 p2 repository at http://download.eclipse.org/releases/luna/201409261001/ it uses the new {EJ}Git repository at http://download.eclipse.org/egit/updates-3.4.2/ as an additional source. The essential change is in the parent pom of the build

  https://git.eclipse.org/r/#/c/38839/1/releng/org.eclipse.epp.config/parent/pom.xml,cm

Regarding your questions in comment #3 I don't expect any problems at all in EPP. If we decide to add another p2 repository with the updated EGit/JGit to the composite in .../releases/luna that's fine. If we decide that a new aggregation is safer that's fine for EPP as well.

I can easily be convinced for both options, additional p2 repository and new aggregation. For me it is important that it is not too much work for everyone involved, and that it is a safe solution. After all it will be used for a few weeks only until we deliver SR2.
Comment 5 Matthias Sohn CLA 2015-01-08 07:17:39 EST
(In reply to David Williams from comment #2)
> Adding Matthias to CC as I'd like to get some "authoritative" information
> about the release that has the fix, 3.4.2, before deciding on the best way
> to fix this. 
> 
> Matthias, is is only the security bug that was fixed between your between
> your "SR1 repo", 
> 
> /home/data/httpd/download.eclipse.org/egit/updates-3.4.1
> 
> and the "fix repo"
> 
> /home/data/httpd/download.eclipse.org/egit/updates-3.4.2
> 
> I can tell from looking that "all" the versions/qualifiers increased, but
> think that's just your build methodology and not an indication of "change".

We flip all the versions since the tooling we use isn't sufficient to flip
the versions only for changed bundles/packages. I look forward to use Obeo's
baseliner [1] to fix that, didn't find the time to try it yet.

the changes between 3.4.1 and 3.4.2 are the following

JGit:
--------------------
- the jgit fixes needed to fix the security vulnerability:

d476d2f - 2014-12-18, Matthias Sohn : ObjectChecker: Disallow names potentially mapping to ".git" on HFS+
a09b1b6 - 2014-12-18, Christian Halstrick : ObjectChecker: Disallow Windows shortname "GIT~1"
10310bf - 2014-12-18, Shawn Pearce : ObjectChecker: Disallow ".git." and ".git<space>"
07612a6 - 2014-12-18, Shawn Pearce : Always ignore case when forbidding .git in ObjectChecker
8d36fa3 - 2014-12-18, Shawn Pearce : DirCache: Refuse to read files with invalid paths
d547d0c - 2014-12-18, Shawn Pearce : DirCache: Replace isValidPath with DirCacheCheckout.checkValidPath
d8eaf5a - 2014-12-18, Shawn Pearce : Replace "a." with "a-" in unit tests

- remove usage of a deprecated inner class
f9088d6 - 2014-11-26, Matthias Sohn : Apache HttpClientConnection: replace calls to deprecated LocalFile()
61b632e - 2014-11-25, Shawn Pearce : Deprecate TemporaryBuffer.LocalFile without parent directory

- fixed some small nits
98c75a7 - 2014-11-25, Shawn Pearce : Fix two nits about DirCacheEntry constructors

- minor performance improvements by improved caching
b34ea11 - 2014-11-25, Shawn Pearce : Detect buffering failures while writing rebase todo file
4206ea4 - 2014-11-25, Shawn Pearce : Switch FileHeader.extractFileLines to TemporaryBuffer.Heap
67b8bcc - 2014-11-25, Shawn Pearce : AmazonS3: Buffer pushed pack content under $GIT_DIR
f313237 - 2014-11-25, Shawn Pearce : DirCache: Buffer TREE extension to $GIT_DIR

EGit:
--------------------
no code changes, but the EGit p2 repository includes the JGit artifacts so we need a new
version and a new build.
 
> Also, does "using JGit 3.4.2" pretty much require that (an EGit user) also
> have EGit 3.4.2? (i.e. is there a "strong" coupling?). And if so, similar
> question for EGit, then, did anything change between EGit 3.4.2 and 3.4.1? 

there are no changes in EGit 3.4.2 except its 3.4.2 p2 repository
includes the jgit 3.4.2 artifacts

> From reading the "release notes" at 
> https://projects.eclipse.org/projects/technology.egit/releases/3.4.2
> is sounds like this security issue is the only thing that changed, but,
> would like a "human verification". (I know, I could "diff" in Git, and other
> techniques ... but, still prefer that JGit/EGit team be involved. 

no code changes in EGit 3.4.2  except its 3.4.2 p2 repository
includes the jgit 3.4.2 artifacts

> Last question for JGit/EGit teams: will your Luna SR2 contribution be
> something other than 3.4.2? I'm guessing you'd move to next minor version or
> something? (If history is any guide). -- Just want to be sure that SR2
> "updates" correctly, in both cases: a) user has installed the off-cycle fix.
> b) user has not installed the off-cycle fix. 

AFAIK we aren't allowed to add new features in a service release hence I was
assuming to ship 3.4.2 with SR2, otherwise I would ship 3.6.2 which I plan
to release next week to fix a regression we introduced in 3.6.1.

> Would you, the JGit and EGit teams would have any concerns about providing
> this off-cycle fix to Sim. Release repo? and EPP packages? That is, any risk
> you know about that we don't? Such as "in the wild" would anyone have
> "mistakenly" created their repo with "*.Git" which would no longer work? 

Repositories containing malicious content (".GiT", ".gi\u200ct" etc) could no
longer be checked out on affected platforms to protect the user against exploits
using the vulnerability. But I think that's exactly the reason why users should
update to a fixed version. If they run into this issue they can use an older
version of native git or low level native git commands to erase the malicious
content from their repository.

> For more background: one reason we "got to this point" is in some discussion
> with Denis, Markus and I reminded him that people with an EPP package
> installed would not get the fix "automatically", just from doing "check for
> updates". So this proposal is to basically make "getting the fix" easier, so
> that even casual users would likely to get it. Though, of course, there is
> no guarantee they would update their client -- and Denis has said he will
> update the "server side" code that helps lesson the problem, as mentioned in
> the original advisory: 
> 
> http://article.gmane.org/gmane.linux.kernel/1853266
> <quote>
> Even though the issue may not affect Linux users, if you are a
> hosting service whose users may fetch from your service to Windows
> or Mac OS X machines, you are strongly encouraged to update to
> protect such users who use existing versions of Git.
> </quote>
> 
> Guess we need a bug open for that too? :) 

Gerrit should be also upgraded to 2.9.4 which includes an update to JGit 3.4.2
to fix the vulnerability, also configuration changes mentioned in
https://projects.eclipse.org/projects/technology.jgit/releases/3.4.2
should be considered.

[1] https://github.com/cbrun/baseliner
Comment 6 Matthias Sohn CLA 2015-01-08 07:19:46 EST
(In reply to Matthias Sohn from comment #5)
> Gerrit should be also upgraded to 2.9.4 which includes an update to JGit
> 3.4.2
> to fix the vulnerability, also configuration changes mentioned in
> https://projects.eclipse.org/projects/technology.jgit/releases/3.4.2
> should be considered.
> 
> [1] https://github.com/cbrun/baseliner

Gerrit 2.9.4 release notes:
https://gerrit-documentation.storage.googleapis.com/ReleaseNotes/ReleaseNotes-2.9.4.html
Comment 7 Matthias Sohn CLA 2015-01-08 07:21:13 EST
(In reply to David Williams from comment #3)
> I've opened bug 456957 to track the "server side" fix. 
> 
> As for "client side", The easiest way to fix is simply to copy the Egit repo
> at 
> /home/data/httpd/download.eclipse.org/egit/updates-3.4.2
> to the .../releases/luna/ 
> repo, and update the composite files, and ?add? the mirror URLs (appears
> EGit/JGit don't have the mirrors URL attribute?!) 
> 
> This "quick fix" would allow the EPP packages to be rebuilt, with minimal
> fuss, I believe. 
> 
> Markus, to build EPP, do you use .../releases/luna URL, or 
> .../releases/luna/201409261001 URL? 
> 
> If the latter, to fix with composites, we'd have to "copy" the current
> contents of /releases/luna/201409261001 "down" a level, replace it with
> composite files, and then add the EGit/JGit repo "under"
> /releases/luna/201409261001. 
> 
> And, of course, there is the traditional approach, of using the b3
> aggregator, where the "input" for all projects is simply Luna SR1, except
> for EGit/JGit which I would update to .../egit/updates-3.4.2. 
> 
> The later is probably safest ... just because it would catch the (very) rare
> possibility that someone specified a "tight" dependency on EGit/JGit. 
> 
> Originally I was thinking of the first option, since easier, but as I typed,
> am now leaning towards the last, just so the "fixed repo" is cleanly in a
> "new spot", has proper mirroring set, etc.

I'd do the later, but I am not the aggregation pro ;-)
Comment 8 David Williams CLA 2015-01-08 11:41:18 EST
> > And, of course, there is the traditional approach, of using the b3
> > aggregator, where the "input" for all projects is simply Luna SR1, except
> > for EGit/JGit which I would update to .../egit/updates-3.4.2. 
> > 
> > The later is probably safest ... just because it would catch the (very) rare
> > possibility that someone specified a "tight" dependency on EGit/JGit. 
> > 
> > Originally I was thinking of the first option, since easier, but as I typed,
> > am now leaning towards the last, just so the "fixed repo" is cleanly in a
> > "new spot", has proper mirroring set, etc.
> 
> I'd do the later, but I am not the aggregation pro ;-)

As I started on this, I remembered we already have done this once, for Luna SR1. In that case, it was "a few days" before the official release (but, after the freeze date) so there is already a "luna_limited" branch, that I will (re)use for the work. In that earlier case, the "input" for everyone (except the platform :(  was 
../releases/luna/201409261000/
and we ended up producing 
../releases/luna/201409261001/ 
for the "final, official release". 

Thus, now, the "input" for everyone will be changed to 
.../releases/luna/201409261001/
except for EGit/JGit, which will be 
.../egit/updates-3.4.2

At that earlier time, we could still use .../releases/maintenance to put "proposed" version, but that would be awkward now, so I will simply "leave things on the build machine" and put the proposed version in 
.../releases/luna/201501091000 
but won't "tie it into" composite, until the EPP packages have been produced, and sanity checked, in what ever way that Markus does that (and, I will of course sanity check the repo). 

So ... depending on Markus's schedule, from my point of view we could "release" this Friday afternoon 1/9, but ... will admit I have lost track of how long the turn around time is producing EPP packages, getting them to downloads, ... oh, and I guess we may want to "let things mirror" for a day or two, before "officially releasing" (that is, making visible) so perhaps our plan should be to "make visible" Monday morning? 10:00 AM Eastern? 

But, again, I can't speak for Markus (and, haven't chatted with him about it), so will wait to hear his agreement or counter proposal for specific times. 
But, I will commit to having the "proposed repo" ready by 10:00 Eastern, 1/9/2015.
Comment 9 Denis Roy CLA 2015-01-08 11:43:06 EST
(In reply to David Williams from comment #8)
> how long the turn around time is producing EPP packages, getting them to
> downloads,

We're not producing new packages, right?  Just a fix for *Git that folks can quickly "Check for updates" and install?
Comment 10 David Williams CLA 2015-01-08 12:12:18 EST
(In reply to Denis Roy from comment #9)
> (In reply to David Williams from comment #8)
> > how long the turn around time is producing EPP packages, getting them to
> > downloads,
> 
> We're not producing new packages, right?  Just a fix for *Git that folks can
> quickly "Check for updates" and install?

Oh, that does sound vaguely familiar. Normally I'd want the packages to match the repositories, since it is disconcerting (and some say sign of poor quality), for those installing the packages for the first time, in the next month, to immediately be offered an update, but ... since this is really a relatively short term "solution" (since SR2 will be out soon) I would not insist on it. I think I do vaguely recall Markus mentioning he is just producing an updated repo for the packages, not building them. 

Markus, is that your intent? 

Thanks,
Comment 11 David Williams CLA 2015-01-08 12:16:36 EST
(In reply to Matthias Sohn from comment #5)
> (In reply to David Williams from comment #2)
> 
> > Last question for JGit/EGit teams: will your Luna SR2 contribution be
> > something other than 3.4.2? I'm guessing you'd move to next minor version or
> > something? (If history is any guide). -- Just want to be sure that SR2
> > "updates" correctly, in both cases: a) user has installed the off-cycle fix.
> > b) user has not installed the off-cycle fix. 
> 
> AFAIK we aren't allowed to add new features in a service release hence I was
> assuming to ship 3.4.2 with SR2, otherwise I would ship 3.6.2 which I plan
> to release next week to fix a regression we introduced in 3.6.1.
> 

That is not literally true. We, the Planning Council, adjusted our policy, several years ago, to allow new features in SRs, to allow for rapid improvement, especially in new projects, BUT ... with some constraints. Mostly to "have your release review" before RC1 (which, I guess you've already had, since now you are talking about a service release) and has to "be in the build" for RC1 and to "keep the community informed", say with a post to cross-project list. BUT, "just because you can", does not mean you "should". We do, still, want the SRs to be very stable and predicable, but, by all means, if you think it is better and important for the community of users and adopters you can.

Don't forget, adopters want more stability than general users, since they may have products built on Luna releases, and usually are less able to respond to a subsequent "fixed release" a month after SR2, than general users are, and if they "extend" your functionality via APIs, may hit bugs that the general user would not see. So, I suggest you discuss between your project's leaders and committers, and ideally get some adopters and users in on that discussion before deciding, and to not do it "just because you can". A "discussion" on cross-project list might also help you decide -- see if you have the support of other Eclipse projects that are part of the release train -- that is, to put it forward as your "plan, unless other projects object or have concerns". I mean, that's only polite. :) 

Thanks for your hard (and fast!) work.
Comment 12 Markus Knauer CLA 2015-01-08 12:38:34 EST
Releasing an update to the EPP packages via p2 and new packages for the download page:

My thinking was that we update *both*, the EPP p2 repository *and* the packages on the download page. The main work in this is to ensure that everything contains what we assume it should contain, i.e. to verify the build results against Luna SR1 - and that needs to be done independent of the package creation.


My proposal for the schedule and timing:

Thursday (today): As soon as has the (inactive) content available in .../releases/luna/201501091000, I can start to build the packages from that p2 repository (*only* from that p2 repository!).

Friday: I need to ensure that the new packages contain what they are supposed to contain, analyse a diff of the packages and of the p2 repository, copy them on the download server.

Monday: Update eclipse.org download page and activate p2 repositories.

And then: Make people aware that they need to "search for updates" in order to get the bugfix release!
Comment 13 Denis Roy CLA 2015-01-08 13:29:15 EST
I am on board with your plan, Markus.

cc'ing Chris & Eddie.  Please see comment 12.
Comment 14 Christopher Guindon CLA 2015-01-08 14:40:52 EST
(In reply to Markus Knauer from comment #12)

> 
> And then: Make people aware that they need to "search for updates" in order
> to get the bugfix release!

Should we create an alert box on the download page about this? I am thinking something similar to the mac download page?

http://www.eclipse.org/downloads/?osType=macosx
Comment 15 Denis Roy CLA 2015-01-08 15:31:21 EST
> Should we create an alert box on the download page about this? I am thinking
> something similar to the mac download page?

I think so; perhaps not in red, but something to announce a vulnerability with eGit and and invitation to "Check for Updates".
Comment 16 Matthias Sohn CLA 2015-01-08 17:50:29 EST
(In reply to Markus Knauer from comment #12)
> Releasing an update to the EPP packages via p2 and new packages for the
> download page:
> 
> My thinking was that we update *both*, the EPP p2 repository *and* the
> packages on the download page. The main work in this is to ensure that
> everything contains what we assume it should contain, i.e. to verify the
> build results against Luna SR1 - and that needs to be done independent of
> the package creation.
> 
> 
> My proposal for the schedule and timing:
> 
> Thursday (today): As soon as has the (inactive) content available in
> .../releases/luna/201501091000, I can start to build the packages from that
> p2 repository (*only* from that p2 repository!).
> 
> Friday: I need to ensure that the new packages contain what they are
> supposed to contain, analyse a diff of the packages and of the p2
> repository, copy them on the download server.
> 
> Monday: Update eclipse.org download page and activate p2 repositories.
> 
> And then: Make people aware that they need to "search for updates" in order
> to get the bugfix release!

looks good to me, let me know if you need help
Comment 17 Matthias Sohn CLA 2015-01-08 17:51:57 EST
(In reply to Denis Roy from comment #15)
> > Should we create an alert box on the download page about this? I am thinking
> > something similar to the mac download page?
> 
> I think so; perhaps not in red, but something to announce a vulnerability
> with eGit and and invitation to "Check for Updates".

actually the vulnerability is in JGit. Users should update egit 3.4.2 which brings the fixed jgit version
Comment 18 Matthias Sohn CLA 2015-01-08 17:59:03 EST
(In reply to Matthias Sohn from comment #5)
> Gerrit should be also upgraded to 2.9.4 which includes an update to JGit
> 3.4.2
> to fix the vulnerability, also configuration changes mentioned in
> https://projects.eclipse.org/projects/technology.jgit/releases/3.4.2
> should be considered.
> 
> [1] https://github.com/cbrun/baseliner

added comments to https://bugs.eclipse.org/bugs/show_bug.cgi?id=441011#c4 to address this
Comment 19 David Williams CLA 2015-01-08 22:11:09 EST
(In reply to Markus Knauer from comment #12)
> ... 
> Thursday (today): As soon as has the (inactive) content available in
> .../releases/luna/201501091000, I can start to build the packages from that
> p2 repository (*only* from that p2 repository!).
> 

I see you skim read my notes too? :) In comment 8 I said, 
"But, I will commit to having the "proposed repo" ready by 10:00 Eastern, 1/9/2015." 
Or ... perhaps it's one of those time zone things. 

In either case, there is now a repo at 
.../releases/luna/201501121000

I used "Monday's date", since that's the target for "release" (that is, to make visible). 

I used p2diff, and could see the only thing different from SR1 was the egit/jgit bundles. 

The only "surprise" was that I could see that 
org.eclipse.mylyn.github* bundles (which are in the EGit b3aggrcn file) changed from "3.4.0.*" to "3.4.2.*" which makes me wonder if I really needed to include them in this "hot fix". Perhaps not as tightly bound? But, unless Matthias says "that is a problem", I'm going to leave it as is.
Comment 20 Matthias Sohn CLA 2015-01-09 05:08:50 EST
(In reply to David Williams from comment #19)
> (In reply to Markus Knauer from comment #12)
> > ... 
> > Thursday (today): As soon as has the (inactive) content available in
> > .../releases/luna/201501091000, I can start to build the packages from that
> > p2 repository (*only* from that p2 repository!).
> > 
> 
> I see you skim read my notes too? :) In comment 8 I said, 
> "But, I will commit to having the "proposed repo" ready by 10:00 Eastern,
> 1/9/2015." 
> Or ... perhaps it's one of those time zone things. 
> 
> In either case, there is now a repo at 
> .../releases/luna/201501121000
> 
> I used "Monday's date", since that's the target for "release" (that is, to
> make visible). 
> 
> I used p2diff, and could see the only thing different from SR1 was the
> egit/jgit bundles. 
> 
> The only "surprise" was that I could see that 
> org.eclipse.mylyn.github* bundles (which are in the EGit b3aggrcn file)
> changed from "3.4.0.*" to "3.4.2.*" which makes me wonder if I really needed
> to include them in this "hot fix". Perhaps not as tightly bound? But, unless
> Matthias says "that is a problem", I'm going to leave it as is.

my fault, doesn't matter, you can use either 3.4.0 or 3.4.2, there is no source change between 3.4.0 and 3.4.2 for the github connector, don't remember why I also released a new version for it, probably I was just too tired to notice this wasn't necessary
Comment 21 David Williams CLA 2015-01-09 08:42:56 EST
Updating title to be more specific, and easier to find with search engines.
Comment 22 David Williams CLA 2015-01-09 08:50:55 EST
Created attachment 249818 [details]
Main "difference" between SR1 repo and 201501121000 repo

Just for the record, p2diff shows, in attachment, the bundles that changed from SR1 to "patched" repo. 

As future reminder, An interesting "change" is the "hash" for the category "Collaboration". I think, the way categories work, that it does not really matter for this case (I believe the UI just "combines" all it finds), but ... it might in future cases? Hence is another reason to always "re-aggregate"? Instead of the "quick hack" fixes we discussed.
Comment 23 David Williams CLA 2015-01-09 08:52:50 EST
Created attachment 249819 [details]
"deep" difference between repos, showing changes in metadata.

This attachment is harder to read (and harder to sort) but provides a sanity check that nothing unusual changed in the repos metadata.
Comment 24 Markus Knauer CLA 2015-01-09 09:23:12 EST
Status EPP for Luna SR1a:

- Build is available at https://hudson.eclipse.org/packaging/job/luna.epp-tycho-build/226/
  This build uses the new input from http://download.eclipse.org/releases/luna/201501121000/

- One notable change: Signing of Mac OSX executables had to be disabled in SR1a (in SR1: enabled) like all other Mac OSX signing since about October (?) 2014.

- A "deep diff" (comparison between SR1 and SR1a) was successful and didn't contain anything suspicious.
  http://download.eclipse.org/technology/epp/downloads/release/luna/SR1a/epp.luna.sr1a.diff.tar.bz2

- A comparison of the EPP SR1 and SR1a repositories was successful and didn't contain anything suspicious.
  http://download.eclipse.org/technology/epp/packages/luna/SR1a/p2.diff.txt

- For update tests before the official release, the following two p2 URL repositories need to be added:
  http://download.eclipse.org/releases/luna/201501121000/
  http://download.eclipse.org/technology/epp/packages/luna/SR1a/

Current status of the packages and of the EPP p2 repository is copied to the download server.

Now back to some manual testing.
Comment 25 Matthias Sohn CLA 2015-01-09 10:34:39 EST
(In reply to Markus Knauer from comment #24)
> Status EPP for Luna SR1a:
> 
> - Build is available at
> https://hudson.eclipse.org/packaging/job/luna.epp-tycho-build/226/
>   This build uses the new input from
> http://download.eclipse.org/releases/luna/201501121000/
> 
> - One notable change: Signing of Mac OSX executables had to be disabled in
> SR1a (in SR1: enabled) like all other Mac OSX signing since about October
> (?) 2014.
> 
> - A "deep diff" (comparison between SR1 and SR1a) was successful and didn't
> contain anything suspicious.
>  
> http://download.eclipse.org/technology/epp/downloads/release/luna/SR1a/epp.
> luna.sr1a.diff.tar.bz2
> 
> - A comparison of the EPP SR1 and SR1a repositories was successful and
> didn't contain anything suspicious.
>   http://download.eclipse.org/technology/epp/packages/luna/SR1a/p2.diff.txt
> 
> - For update tests before the official release, the following two p2 URL
> repositories need to be added:
>   http://download.eclipse.org/releases/luna/201501121000/
>   http://download.eclipse.org/technology/epp/packages/luna/SR1a/
> 
> Current status of the packages and of the EPP p2 repository is copied to the
> download server.
> 
> Now back to some manual testing.

I could successfully update a fresh installation from 
eclipse-standard-luna-SR1-macosx-cocoa-x86_64.tar.gz 
to JGit & EGit 3.4.2 using the p2 URLs above
Comment 26 Markus Knauer CLA 2015-01-12 05:08:25 EST
(In reply to Markus Knauer from comment #24)
> Now back to some manual testing.

I tried some updates from earlier Luna releases to Luna SR1a with the following two additional p2 repositories and they were successful.

  http://download.eclipse.org/releases/luna/201501121000/
  http://download.eclipse.org/technology/epp/packages/luna/SR1a/

- Java package on Linux
- RCP/RAP package on Mac OSX + Linux + Windows
- Java EE package on Windows
- Committers/Standard package on Windows
Comment 27 Christopher Guindon CLA 2015-01-12 10:19:47 EST
The packages are now available on our downloads page:

https://www.eclipse.org/downloads/index.php
Comment 28 Markus Knauer CLA 2015-01-12 10:21:45 EST
Thanks to everyone involved! Especially to the JGit team!
Comment 29 David Williams CLA 2015-01-12 10:47:30 EST
Thanks to all, and I'll leave as the closing comment the advice to anyone with "older than Luna" installs -- if you can not upgrade to Luna! 

If users or adopters or distributors have installations older than Luna, the advice is to add a more recent EGit/JGit release to their installation by using one of the following update sites. They should all be compatible with releases back to at least Juno. 

The first one in list, is the one closest to "Luna" and what you get if you simply "check for updates" from a Luna install. Some with older installs might feel safest with it, since it has been in the field the longest, but the newer ones are also considered stable, and perhaps better since they have new function and more functional fixes. 

 https://projects.eclipse.org/projects/technology.egit/releases/3.4.2 
 https://projects.eclipse.org/projects/technology.egit/releases/3.5.3 
 https://projects.eclipse.org/projects/technology.egit/releases/3.6.0 

Thanks again,