Bug 501000 - EGit Authenticator prevents login dialog
Summary: EGit Authenticator prevents login dialog
Status: CLOSED FIXED
Alias: None
Product: MPC
Classification: Technology
Component: Install (show other bugs)
Version: unspecified   Edit
Hardware: All All
: P3 critical with 5 votes (vote)
Target Milestone: 1.5.1   Edit
Assignee: Carsten Reckord CLA
QA Contact:
URL:
Whiteboard:
Keywords:
: 502567 503389 (view as bug list)
Depends on: 368882
Blocks: 483192
  Show dependency tree
 
Reported: 2016-09-07 10:33 EDT by Carsten Reckord CLA
Modified: 2019-02-12 11:24 EST (History)
18 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Carsten Reckord CLA 2016-09-07 10:33:38 EDT
The custom java.net.Authenticator implementation registered by EGit to get credentials from configured proxies does not redirect to the eclipse.ui.net Authenticator, which is responsible for showing a login dialog to prompt for credentials, see bug 368882. 

Until a fix for bug 368882 is in Simrel, we should work around this in MPC.
Comment 1 Carsten Reckord CLA 2016-09-12 10:02:56 EDT
Fixed in commit c6f0388b204779aa6ca788eec84de4aa1f613afe for MPC 1.5.1 / Neon.1.

We wrap the registered in our own Authenticator that first checks the proxy settings for matching authentication, just like EGit does. We then delegate on to the original Authenticator. In case of the EGit authenticator, we bypass the existing Authenticator and instead delegate to an instance of the registered class from the org.eclipse.core.net.authenticator extension point, or failing that, to an instance of org.eclipse.ui.net.NetAuthenticator. 

This should be fully compatible with the EGit use case, since we will always check the proxy config first and wont show a password prompt if we find a match. In all other cases, we will prompt the user for their credentials.
Comment 2 Ed Merks CLA 2016-09-29 02:09:20 EDT
Note that this change causes a very serious new problem.  

On my customer project they're using https basic authentication to access their private git clone.  Before this change, all that worked well. After a day of effort trying to figure out why in some test installations it works but in some it didn't, the finger of blame pointed at Neon.1.  After much debugging to see how the execution paths different, I finally noticed that in the problematic installations there were three calls to this method:

java.net.Authenticator.setDefault(Authenticator)

This change is the cause of that third call. With this change, when trying to clone, a prompt comes up, produced by your replacement to the system-wide authenticator and that dialog prompts for a password for the overall site (not noticing that there is an user@ in the URI).  If I enter the proper credentials (there's no option to save them, which seems bad as well). If I enter proper credentials, then JGIT does not see a 401 and does not apply the necessary credential when using that site.  So, later on, the cloning process fails with 401 because EGit itself doesn't know that it should provide the proper credentials so it isn't fetching them from secure storage and applying them.  Strangely, if I dismiss the dialog that's effectively prompting for a proxy password, then EGit's normal behavior kicks in because it sees the 401 and applies the authentication information in the secure preference store.

So fortunately there is a workaround for this very serious problem, but a super confusing one that's very hard to explain to my client.

I'll clone the source and see if I can figure out how to fix this problem.  Why isn't there an Oomph setup for it?
Comment 3 Ed Merks CLA 2016-09-29 02:10:17 EDT
I've tempted to mark this as critical or even a blocker, because users will not know how to work around the problem that's been introduced.
Comment 4 Ed Merks CLA 2016-09-29 06:34:43 EDT
I'm adding Matthias because users will likely see this as an EGit problem.
Comment 5 Carsten Reckord CLA 2016-09-29 06:48:44 EDT
Oh damn, and here I thought I was being so careful :( I specifically tested this with EGit against a private GitLab instance. Not sure what wires got crossed there, but it worked at the time, and now I get exactly the problem you are describing.

I'm fine with disabling MPC's authenticator for now, since the EGit issue is far more severe than what this solves for MPC. 

In general, I think we will need a better strategy for Platform network access though, since the singleton java.net.Authenticator instance is unfortunately a shared resource for all projects.
Comment 6 Eclipse Genie CLA 2016-09-29 10:32:42 EDT
New Gerrit change created: https://git.eclipse.org/r/82187
Comment 7 Carsten Reckord CLA 2016-09-29 11:40:27 EDT
The Gerrit change removes MPC's use of its Authenticator configuration. It fixes the EGit issue, but of course will valid use cases for the Login dialog again as well.

I can merge the fix and publish a new MPC version momentarily, but how do we proceed from there? 

With Neon.1 just out of the door, do we request a Neon.1a? Or do we communicate the availability of a fix for affected users somehow? I guess the Installer could ship the updated version immediately, but for downloaded packages the regular "Search for updates" won't suffice to push it out unfortunately.
Comment 8 Ed Merks CLA 2016-09-29 11:58:56 EDT
I'd be very happy with a p2 update site with the fix.  I can't speak for everyone.
Comment 10 Carsten Reckord CLA 2016-09-29 12:20:18 EDT
I've pushed the change and published the site at http://download.eclipse.org/mpc/releases/1.5.1a for now.
Comment 11 Jesper Skov CLA 2016-09-30 04:09:19 EDT
(In reply to Carsten Reckord from comment #10)
> I've pushed the change and published the site at
> http://download.eclipse.org/mpc/releases/1.5.1a for now.

This plugin fixes the problem for me, thanks.
Comment 12 Carsten Reckord CLA 2016-09-30 05:04:28 EDT
(In reply to comment #7)
> With Neon.1 just out of the door, do we request a Neon.1a? Or do we communicate
> the availability of a fix for affected users somehow? I guess the Installer
> could ship the updated version immediately, but for downloaded packages the
> regular "Search for updates" won't suffice to push it out unfortunately.

Matthias, any input on this?
Comment 13 Ed Merks CLA 2016-09-30 07:39:26 EDT
I too can confirm this fixes the problem and this makes me much happier than installing Neon.0 on my customer project.  And I think the customer will be impressed that a fix was delivered immediately!  Many thanks!!

One thing I could do in the generated product catalog is temporarily add this update site to all the Neon product versions.  Perhaps the Neon.1 update site itself could add a reference to it as well (much like it has a reference to the EPP site) so that anyone updating will pick up the fixed version.  That only leaves the issue of the pre-packaged products coming with the problem out of the box, but if an update fixed the problem, maybe that sufficient.
Comment 14 Carsten Reckord CLA 2016-09-30 07:56:55 EDT
(In reply to Ed Merks from comment #13)
> One thing I could do in the generated product catalog is temporarily add
> this update site to all the Neon product versions.

That would be great. 

I'm still testing, but I believe I also have a patch for EGit that would solve the issue as well, independently of the MPC fix. This has the benefit that unlike MPC, EGit updates are detected and installed by the auto updater.
Comment 15 Matthias Sohn CLA 2016-09-30 08:10:44 EDT
(In reply to Carsten Reckord from comment #14)
> (In reply to Ed Merks from comment #13)
> > One thing I could do in the generated product catalog is temporarily add
> > this update site to all the Neon product versions.
> 
> That would be great. 

+1

> I'm still testing, but I believe I also have a patch for EGit that would
> solve the issue as well, independently of the MPC fix. This has the benefit
> that unlike MPC, EGit updates are detected and installed by the auto updater.

looking forward to your patch, push it for the stable-4.5 branch

midterm I want to get rid of Authenticator in EGit by switching to use Apache httpclient instead of URLConnection, unfortunately didn't find the time yet to finish that
Comment 16 Markus Knauer CLA 2016-09-30 08:40:34 EDT
(In reply to Carsten Reckord from comment #14)
> ... I believe I also have a patch for EGit that would solve the issue
> as well, independently of the MPC fix. This has the benefit that
> unlike MPC, EGit updates are detected and installed by the auto updater.

It's true that EGit is an independent root feature in all EPP packages, whereas the MPC is included as a part of the package itself. As a result of this, EGit would see automated updates *if* a p2 repository with the updated EGit artifacts is known to the package - currently only the Neon p2 repository and the Eclipse Platform repository are registered in *all* packages. I have my doubt that an update of EGit without adding it to the SimRel p2 repository would help solving this issue.
Comment 17 Carsten Reckord CLA 2016-09-30 09:08:26 EDT
(In reply to Markus Knauer from comment #16)
> I have my doubt that an update of EGit without adding it to the
> SimRel p2 repository would help solving this issue.

Ah, yes. You are right :-( So how can we proceed? Would adding an additional repository to the simrel composite be an option? Or would we need to request a full respin / Neon.1a release?
Comment 18 Markus Knauer CLA 2016-09-30 10:33:10 EDT
(In reply to Carsten Reckord from comment #17)
> ... So how can we proceed?

I suggest to write to cross-project-issues-dev in order to make others aware of this problem in Neon.1, and to start a discussion about possible actions. Additionally it would be good to ask the Technology PMC how to proceed.
Comment 19 Ed Merks CLA 2016-09-30 10:46:41 EDT
I believe the requirement on epp.mpc.feature.group is [1.5.1,1.5.2) so as long as the update site with the fix is visible, this fix will install.  One way to make it visible is to add it to the neon composite (and then also add it to the Oomph product catalog for the Neon product versions because it doesn't point at the composite but at the latest child of the composite, all to avoid extra load on the Eclipse server for accessing the composite and all its children).  To me this seems far less disruptive than a full respin.

But yes, cross projects is a good place to post for opinions.
Comment 20 Eclipse Genie CLA 2016-09-30 12:21:45 EDT
New Gerrit change created: https://git.eclipse.org/r/82295
Comment 21 Carsten Reckord CLA 2016-09-30 12:26:46 EDT
(In reply to Markus Knauer from comment #18)
> I suggest to write to cross-project-issues-dev in order to make others aware
> of this problem in Neon.1, and to start a discussion about possible actions.
> Additionally it would be good to ask the Technology PMC how to proceed.

I will do that momentarily.

(In reply to Ed Merks from comment #19)
> I believe the requirement on epp.mpc.feature.group is [1.5.1,1.5.2) so as
> long as the update site with the fix is visible, this fix will install.

Unfortunately, it won't. The epp.mpc.feature.group is not a root IU, so it isn't included in the check for updates. That's where my patch for EGit from comment #14 would come in. I have pushed it to https://git.eclipse.org/r/#/c/82295/. 

In case it is decided that publishing an addition to the simrel composite instead of a full respin, I'd offer to build a minimal site with the MPC change (for new installs) and the EGit change (so existing clients get a fix via auto-update), making sure that both are binary-identical except for the two touched classes.
Comment 22 Ed Merks CLA 2016-09-30 13:11:30 EDT
Carsten,

I see, yes, only Oomph's Perform Setup Tasks... resolves the entire tree again, whereas regular p2 update just looks for updates to the root IUs. But Perform Setup Task... only helps if you created the installation with the Eclipse Installer.
Comment 23 Patrik Dufresne CLA 2016-09-30 13:16:33 EDT
Is this patches available via "Check for Updates" ? If not, I can I get this patches installed ?
Comment 24 Carsten Reckord CLA 2016-09-30 13:25:53 EDT
(In reply to comment #23)
> Is this patches available via "Check for Updates" ? If not, I can I get this
> patches installed ?

You will need to install it via Help > Install New Software..., using http://download.eclipse.org/mpc/releases/1.5.1a as the repository
Comment 25 David Williams CLA 2016-09-30 13:49:44 EDT
(In reply to Carsten Reckord from comment #21)

> In case it is decided that publishing an addition to the simrel composite
> instead of a full respin, I'd offer to build a minimal site with the MPC
> change (for new installs) and the EGit change (so existing clients get a fix
> via auto-update), making sure that both are binary-identical except for the
> two touched classes.

Procedurally, if you are going to ask for a "respin" you should definitely get the support of your PMCs and then have your Planning council representative make a request for a respin. But, in the mean time, I have opened bug 502937 to document some approaches to doing such a respin. And, if not clear, I assume you are only discussing the Sim. Release repository, not asking for a respin of all EPP packages. I think the later is reserved for cases where "data is harmed" or a "security exposure occurs". But, by all means, simply be clear what you are asking for and I'm sure those involved will say "yea or nay". 

But, our discussions in the planning council have focused on users getting updates via "check for updates" in an easier way, that did not impact many other projects (or committers) or cause them re-work. 

Thanks,
Comment 26 Carsten Reckord CLA 2016-09-30 15:14:39 EDT
Matthias, with your permission, I'd like to post the steps to fix this manually to the corresponding AERI problem [1], so users of the Error Reporter will be informed how to get it solved.

[1] https://dev.eclipse.org/recommenders/committers/aeri/v2/#!/problems/54ef6917e4b0eb19d1a16254
Comment 27 Ari Meyer CLA 2016-10-03 14:08:29 EDT
(In reply to Carsten Reckord from comment #26)
> Matthias, with your permission, I'd like to post the steps to fix this
> manually to the corresponding AERI problem [1], so users of the Error
> Reporter will be informed how to get it solved.
> 
> [1]
> https://dev.eclipse.org/recommenders/committers/aeri/v2/#!/problems/
> 54ef6917e4b0eb19d1a16254


Thanks for this info:
>> You will need to install it via Help > Install New Software..., using http://download.eclipse.org/mpc/releases/1.5.1a as the repository

I'm also able to clone now with this new Marketplace Client.  Glad I finally found this post after much searching!  The error messages we get don't make any sense, esp. since we're able to use prior releases without issue with the same proxy settings.  The Error Reporter suggestion would certainly help, as this is really a blocker for many of us.  Thanks!
Comment 28 David Williams CLA 2016-10-03 16:26:34 EDT
(In reply to Carsten Reckord from comment #24)
> (In reply to comment #23)
> > Is this patches available via "Check for Updates" ? If not, I can I get this
> > patches installed ?
> 
> You will need to install it via Help > Install New Software..., using
> http://download.eclipse.org/mpc/releases/1.5.1a as the repository

Can I clarify explicitly, if there is any sort of "respin" done, it is ONLY the mpc repo that needs to be fixed? Or are there changes in EGit and others that need a fix? Seems this bug has talked about several, but I do not understand if those others are just side issues caused by the MPC issue, or if they all need a new, fixed "repository".

A less important question, I noticed the versions in 1.5.1a increased only the qualifier, not the service field. Is that desired? If so, why? Is it that EPP specifies an overly tight range? 

Thanks,
Comment 29 Ed Merks CLA 2016-10-04 01:00:41 EDT
David, yes, it appears to me that it specifies [1.5.1,1.5.2) as the dependency.
Comment 30 Carsten Reckord CLA 2016-10-04 05:36:06 EDT
(In reply to Ari Meyer from comment #27)
> The Error Reporter suggestion would certainly
> help, as this is really a blocker for many of us.  Thanks!

I've posted the Error Reporter message yesterday morning, but didn't subsequently receive it on a test installation myself. I've contacted the Error Reporter guys and am waiting to hear back from them (yesterday was a holiday in Germany, so they were out).
Comment 31 Carsten Reckord CLA 2016-10-04 05:36:24 EDT
(In reply to Markus Knauer from comment #18)
> I suggest to write to cross-project-issues-dev in order to make others aware
> of this problem in Neon.1, and to start a discussion about possible actions.
> Additionally it would be good to ask the Technology PMC how to proceed.

I have done as suggested and posted to cross-project-issues-dev and technology-pmc on Friday, but it worries me that there has been zero reaction to my mail so far. I've confirmed with my colleagues that they have received the mail through those lists, but can somebody else confirm that they got it?

In any case, I'll try to get a hold of Ian today so we can formally ask for a respin.
Comment 32 Carsten Reckord CLA 2016-10-04 05:39:13 EDT
(In reply to David Williams from comment #28)
> Can I clarify explicitly, if there is any sort of "respin" done, it is ONLY
> the mpc repo that needs to be fixed? Or are there changes in EGit and others
> that need a fix? Seems this bug has talked about several, but I do not
> understand if those others are just side issues caused by the MPC issue, or
> if they all need a new, fixed "repository".

If we can get the new version of MPC out in a way that it gets pulled in via "Check for updates", then the changes in MPC alone are enough. But since MPC isn't a root feature, and I don't quite understand your proposal in bug 502937, I don't know if that's the case. As I understand it, given the current EPP structure, the "EPP Common" feature (org.eclipse.epp.package.common.feature), which contains MPC, and the product IUs (epp.package.java etc), which contain the EPP Common feature, would need a bump in their version for this to work.

> A less important question, I noticed the versions in 1.5.1a increased only
> the qualifier, not the service field. Is that desired? If so, why? Is it
> that EPP specifies an overly tight range? 
(In reply to Ed Merks from comment #29)
> David, yes, it appears to me that it specifies [1.5.1,1.5.2) as the
> dependency.

The [1.5.1,1.5.2) is just in MPC's B3 aggregator file. The EPP Common feature pulls in MPC with a version range of "0.0.0". I didn't increase the micro version, because given the situation I considered this the safest option with the least risk, but I can update the MPC feature and core plugin and the aggregator file to 1.5.2 just as well.
Comment 33 Carsten Reckord CLA 2016-10-04 06:29:06 EDT
(In reply to comment #30)
> (In reply to Ari Meyer from comment #27)
> I've posted the Error Reporter message yesterday morning, but didn't
> subsequently receive it on a test installation myself. I've contacted the Error
> Reporter guys and am waiting to hear back from them (yesterday was a holiday in
> Germany, so they were out).

I've received an answer from the Error Reporter folks. Seems like the message only goes out to new reporters, not ones who have already reported the issue. I'll see that I contact those via email who have left a mail address.
Comment 34 Andrey Loskutov CLA 2016-10-04 10:23:37 EDT
*** Bug 503389 has been marked as a duplicate of this bug. ***
Comment 35 David Williams CLA 2016-10-04 10:50:42 EDT
(In reply to Carsten Reckord from comment #32)

> The [1.5.1,1.5.2) is just in MPC's B3 aggregator file. The EPP Common
> feature pulls in MPC with a version range of "0.0.0". I didn't increase the
> micro version, because given the situation I considered this the safest
> option with the least risk, but I can update the MPC feature and core plugin
> and the aggregator file to 1.5.2 just as well.

I would be recommend an increase in the service field. That makes it easier for consumers who "for sure want to get the fix" to specify a prereq something like [1.5.2, 1.6.0). Otherwise, they have to specify [1.5.2.<qualifier>, 1.6.0) which is kind of awkward. 

It is, though, sort of an "in theory" comment I am making. I do not know of anyone who does prereq MPC and obviously EPP is counting on "getting the latest". So please know I am not saying you *have* to increase the service field, just recommending it. You *might* be right -- it is always hard to know how consumers have specified their prereqs and which would be more or less trouble for them. 

= = = = = 

And, I think in same thread, if EPP specifies "0.0.0" then they substitute an exact version in the feature, so they would have to be rebuilt (at least at the repository level, to get the new MPC version (what ever it turns out to be) for "check updates" to work as expected. 

= = = = = 

This seems unfortunate that MPC was not also made a "root feature". 
Markus, was there a technical reason for that?
Comment 36 Carsten Reckord CLA 2016-10-04 10:59:12 EDT
(In reply to David Williams from comment #35)
> And, I think in same thread, if EPP specifies "0.0.0" then they substitute
> an exact version in the feature, so they would have to be rebuilt (at least
> at the repository level, to get the new MPC version (what ever it turns out
> to be) for "check updates" to work as expected. 

I've just looked in the Neon.1 content.jar, and MPC is included by EPP as an exact version:

<required namespace='org.eclipse.equinox.p2.iu' name='org.eclipse.epp.mpc.feature.group' range='[1.5.1.v20160913-1450,1.5.1.v20160913-1450]'/>

Also, the "General Purpose Tools" category IU seems to use the version range from the aggregator file:

<required namespace='org.eclipse.equinox.p2.iu' name='org.eclipse.epp.mpc.feature.group' range='[1.5.1,1.5.2)'/>

I wasn't aware of that before, but I guess it might be best to just stay with 1.5.1 then...
Comment 37 Garret Wilson CLA 2016-10-04 11:55:08 EDT
http://stackoverflow.com/q/39798030/421049
Comment 38 David Williams CLA 2016-10-04 12:02:09 EDT
(In reply to Carsten Reckord from comment #36)
> (In reply to David Williams from comment #35)
> > And, I think in same thread, if EPP specifies "0.0.0" then they substitute
> > an exact version in the feature, so they would have to be rebuilt (at least
> > at the repository level, to get the new MPC version (what ever it turns out
> > to be) for "check updates" to work as expected. 
> 
> I've just looked in the Neon.1 content.jar, and MPC is included by EPP as an
> exact version:
> 
> <required namespace='org.eclipse.equinox.p2.iu'
> name='org.eclipse.epp.mpc.feature.group'
> range='[1.5.1.v20160913-1450,1.5.1.v20160913-1450]'/>
> 
> Also, the "General Purpose Tools" category IU seems to use the version range
> from the aggregator file:
> 
> <required namespace='org.eclipse.equinox.p2.iu'
> name='org.eclipse.epp.mpc.feature.group' range='[1.5.1,1.5.2)'/>
> 
> I wasn't aware of that before, but I guess it might be best to just stay
> with 1.5.1 then...

Well, you for sure would not want to use the same qualifier, I don't think you are saying that. The features that "include" mpc would have to be regenerated. 

And, as far as the category goes, the category is also regenerated (by the b3 aggregator) so I do not think that range should be the deciding factor. 

You really want to go by "semantics" and "impact to outside adopters" (if, there are any?)
Comment 39 Carsten Reckord CLA 2016-10-04 12:06:51 EDT
(In reply to David Williams from comment #38)
> Well, you for sure would not want to use the same qualifier, I don't think
> you are saying that.

Definitely not.

> 
> And, as far as the category goes, the category is also regenerated (by the
> b3 aggregator) so I do not think that range should be the deciding factor. 

Ah, okay. In that case, yes, I think bumping the micro version would be better. I'll create a new build.
Comment 40 Markus Knauer CLA 2016-10-04 12:10:10 EDT
(In reply to David Williams from comment #35)
> And, I think in same thread, if EPP specifies "0.0.0" then they substitute
> an exact version in the feature, so they would have to be rebuilt (at least
> at the repository level, to get the new MPC version (what ever it turns out
> to be) for "check updates" to work as expected. 

The "EPP Common Package Feature" (org.eclipse.epp.package.common.feature) is part of *all* packages, and bound with its version to the package. Inside this feature the version constraints are very open, and would allow to upgrade its three dependencies (MPC, AERI, Oomph) independently, but it is correct that "check updates" does not search on that level.

The packages include the EPP Common feature like this...

  <required
   namespace='org.eclipse.equinox.p2.iu'
   name='org.eclipse.epp.package.common.feature.feature.group'
   range='[4.6.1.20160912-1200,4.6.1.20160912-1200]'/>

...and the feature itself defines its dependencies to the MPC like this:

  <required
   namespace='org.eclipse.equinox.p2.iu'
   name='org.eclipse.epp.mpc.feature.group'
   range='0.0.0'/>

The answer is: Yes, at least the p2 repository of the packages and the common feature have to be rebuild with an increased version.

(In reply to David Williams from comment #35)
> This seems unfortunate that MPC was not also made a "root feature". 
> Markus, was there a technical reason for that?

For this particular use-case of updating the MPC it seems unfortunate, but when we split the packages into root-features and non-root-features we wanted to ensure that some essential parts of all packages cannot be uninstalled or removed (accidentally) by a user.
Comment 41 Markus Knauer CLA 2016-10-05 05:17:41 EDT
(In reply to Carsten Reckord from comment #39)
> I'll create a new build.

Is a new build available and can be consumed from a p2 URL? I'd like to give that a test-run if possible.
Comment 42 Carsten Reckord CLA 2016-10-05 05:20:42 EDT
(In reply to Markus Knauer from comment #41)
> (In reply to Carsten Reckord from comment #39)
> > I'll create a new build.
> 
> Is a new build available and can be consumed from a p2 URL? I'd like to give
> that a test-run if possible.

Yes, at http://download.eclipse.org/mpc/releases/1.5.2. 

I've also talked to Ian and am just in the process of writing to Technology PMC to formally ask for a repository "respin".
Comment 43 Andrey Loskutov CLA 2016-10-05 05:25:28 EDT
(In reply to Carsten Reckord from comment #42)
> (In reply to Markus Knauer from comment #41)
> > (In reply to Carsten Reckord from comment #39)
> > > I'll create a new build.
> > 
> > Is a new build available and can be consumed from a p2 URL? I'd like to give
> > that a test-run if possible.
> 
> Yes, at http://download.eclipse.org/mpc/releases/1.5.2. 
> 
> I've also talked to Ian and am just in the process of writing to Technology
> PMC to formally ask for a repository "respin".

Carsten, can we have another fix included? We have a severe regression in UI (see bug 502514), for which the best solution would be to revert commit http://git.eclipse.org/c/mpc/org.eclipse.epp.mpc.git/commit/?id=310d627cebf98d983503f0d47a1d8dff83f81840 (and so reopen bug 498553) until we can ship 4.6.2 with the right fix for bug 502514.
Comment 44 Markus Knauer CLA 2016-10-05 05:48:05 EDT
(In reply to Carsten Reckord from comment #42)
> Yes, at http://download.eclipse.org/mpc/releases/1.5.2. 

I've been testing this build by using the Neon.1 RCP/RAP package. Before installing the new MPC version the error was clearly visible and reproducible, after manually installing the new MPC version from the above URL the error could not be reproduced any more.

I'd propose to follow the standard process, i.e. ask the Technology PMC to discuss with the Planning Council the inclusion of the new version in the Neon p2 repositories. When this is done I would start to regenerate the EPP p2 repository to allow automatic updates of the packages. Up to now I'm not convinced that we should replace the existing download archives, but that's another discussion.
Comment 45 Carsten Reckord CLA 2016-10-05 10:45:39 EDT
David, Markus, thank you for all your help. As you might have seen, I've initiated the respin request with the Technology PMC[1] and I hope we will get the vote at the Planning Council meeting today. 

I'd like to go ahead and push an update of our aggregation file to the simrel Gerrit in preparation. Should I just push it to Neon_maintenance, or do you plan on creating a branch for it?

[1] https://dev.eclipse.org/mhonarc/lists/technology-pmc/msg07772.html
Comment 46 David Williams CLA 2016-10-05 10:55:37 EDT
(In reply to Carsten Reckord from comment #45)
> David, Markus, thank you for all your help. As you might have seen, I've
> initiated the respin request with the Technology PMC[1] and I hope we will
> get the vote at the Planning Council meeting today. 
> 
> I'd like to go ahead and push an update of our aggregation file to the
> simrel Gerrit in preparation. Should I just push it to Neon_maintenance, or
> do you plan on creating a branch for it?
> 
> [1] https://dev.eclipse.org/mhonarc/lists/technology-pmc/msg07772.html

You should go ahead and update your b3aggrcon files, in Neon_maintenance and master (if master is using the same content/fix) since if nothing else, that would put the fix into staging repositories we currently produce. 

I have not yet decided about branching or mechanics of producing a "patch build" for Neon.1 but I will handle that, so as long as I know what the correct URL is (and, versions, I guess) then I will have all that I need. 

Thanks,
Comment 47 Eclipse Genie CLA 2016-10-05 11:21:02 EDT
New Gerrit change created: https://git.eclipse.org/r/82539
Comment 48 Carsten Reckord CLA 2016-10-05 11:29:00 EDT
Done, see https://git.eclipse.org/r/82539 for Neon_maintenance (master: https://git.eclipse.org/r/82541)

Note that the Platform project has asked on https://bugs.eclipse.org/bugs/show_bug.cgi?id=498553 to include another change. I've verified that change, produced a build including both, and forwarded the request to the PMC. But I haven't included the new build in this simrel contribution, pending a decision from PMC and Planning Council.
Comment 50 David Williams CLA 2016-10-11 10:12:34 EDT
So, now that the fix is "out" I think it would would good if a few words were said about how to avoid these "post release" problems in the future. Is it just a matter of "more testing"? Need more unit tests? Would a proxy test environment help? (which is sort of related to bug 441733 which gives one solution, for one type of proxy). Or, perhaps a "sign up" of corporate users who hit this problem to do quick, pre-release tests in the future?

All just questions or ideas ... I just thought we should give it a very brief retrospective here in the bug. 

Thanks again to those that detected, fixed, and helped confirm the fix.
Comment 51 Andrey Loskutov CLA 2016-10-11 10:18:51 EDT
(In reply to David Williams from comment #50)
> So, now that the fix is "out"

Does the fixed MPC include the patch for bug 498553?
Comment 52 David Williams CLA 2016-10-11 11:07:38 EDT
(In reply to Andrey Loskutov from comment #51)
> (In reply to David Williams from comment #50)
> > So, now that the fix is "out"
> 
> Does the fixed MPC include the patch for bug 498553?

If you are asking me, I do not know for sure. I said I would leave it up to Carsten's discretion and I have not looked at the source repository. And, you are correct, it should be (have been) better documented.
Comment 53 Thomas Wolf CLA 2016-10-12 02:28:28 EDT
*** Bug 502567 has been marked as a duplicate of this bug. ***
Comment 54 Carsten Reckord CLA 2019-02-12 11:24:53 EST
I'm going to close this. The problematic change was rolled back, and currently there are no plans to revisit the authenticator dialog story.