Yes, my comments and concerns are purely and only related to the
license text in the products. In their usual diligent manner, our
tireless release engineers have already addressed that concern.
It would of course be great if ECF could move to EPL 2.0 and also
use SUA 2.0, but alas, that's not the case.
Any other conversion from http -> https in code or in
documentation is of course fine and good, though a word of caution
is in order because, for example, my older Java 8 implementation
cannot read from archive.eclipse.org via https:
org.eclipse.equinox.p2.core.ProvisionException: Unable to read
repository at
https://archive.eclipse.org/webtools/downloads/drops/R3.2/C3.2.0/I-C3.2.0-20100614204142/repository/content.xml.
at
org.eclipse.equinox.internal.p2.repository.CacheManager.createCache(CacheManager.java:247)
at
org.eclipse.equinox.internal.p2.metadata.repository.SimpleMetadataRepositoryFactory.getLocalFile(SimpleMetadataRepositoryFactory.java:69)
at
org.eclipse.equinox.internal.p2.metadata.repository.SimpleMetadataRepositoryFactory.load(SimpleMetadataRepositoryFactory.java:89)
at
org.eclipse.equinox.internal.p2.metadata.repository.MetadataRepositoryManager.factoryLoad(MetadataRepositoryManager.java:63)
at
org.eclipse.equinox.internal.p2.repository.helpers.AbstractRepositoryManager.loadRepository(AbstractRepositoryManager.java:775)
at
org.eclipse.equinox.internal.p2.repository.helpers.AbstractRepositoryManager.loadRepository(AbstractRepositoryManager.java:676)
at
org.eclipse.equinox.internal.p2.metadata.repository.MetadataRepositoryManager.loadRepository(MetadataRepositoryManager.java:110)
at
org.eclipse.equinox.internal.p2.metadata.repository.MetadataRepositoryManager.loadRepository(MetadataRepositoryManager.java:105)
at
org.eclipse.cbi.p2repo.p2.loader.impl.P2RepositoryLoader.load(P2RepositoryLoader.java:94)
at
org.eclipse.cbi.p2repo.p2.loader.impl.P2RepositoryLoader.load(P2RepositoryLoader.java:60)
at
org.eclipse.cbi.p2repo.aggregator.p2.util.MetadataRepositoryResourceImpl$RepositoryLoaderJob.run(MetadataRepositoryResourceImpl.java:486)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63)
Caused by: javax.net.ssl.SSLHandshakeException: Received fatal
alert: handshake_failure
at sun.security.ssl.Alerts.getSSLException(Unknown Source)
at sun.security.ssl.Alerts.getSSLException(Unknown Source)
at sun.security.ssl.SSLSocketImpl.recvAlert(Unknown Source)
at sun.security.ssl.SSLSocketImpl.readRecord(Unknown Source)
at
sun.security.ssl.SSLSocketImpl.performInitialHandshake(Unknown
Source)
at sun.security.ssl.SSLSocketImpl.startHandshake(Unknown
Source)
at sun.security.ssl.SSLSocketImpl.startHandshake(Unknown
Source)
at
org.apache.http.conn.ssl.SSLConnectionSocketFactory.createLayeredSocket(SSLConnectionSocketFactory.java:396)
at
org.apache.http.conn.ssl.SSLConnectionSocketFactory.connectSocket(SSLConnectionSocketFactory.java:355)
at
org.apache.http.impl.conn.DefaultHttpClientConnectionOperator.connect(DefaultHttpClientConnectionOperator.java:142)
at
org.apache.http.impl.conn.PoolingHttpClientConnectionManager.connect(PoolingHttpClientConnectionManager.java:373)
at
org.apache.http.impl.execchain.MainClientExec.establishRoute(MainClientExec.java:394)
at
org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:237)
at
org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:185)
at
org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:89)
at
org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:110)
at
org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:185)
at
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:83)
at
org.eclipse.ecf.provider.filetransfer.httpclient45.HttpClientFileSystemBrowser.runRequest(HttpClientFileSystemBrowser.java:246)
at
org.eclipse.ecf.provider.filetransfer.browse.AbstractFileSystemBrowser$DirectoryJob.run(AbstractFileSystemBrowser.java:69)
... 1 more
Most likely a root certificate problem because it works fine with
the 231 Java 8 version.
I agree with
the
license related changes but all other changes to https are fine
with me
and will not be reverted.
Dani
From:
Ed
Merks <ed.merks@xxxxxxxxx>
To:
platform-dev@xxxxxxxxxxx
Date:
08.01.2020
11:29
Subject:
[EXTERNAL]
Re: [platform-dev] 4.15 M1 milestone week reminders
Sent
by: platform-dev-bounces@xxxxxxxxxxx
Sravan,
The http://git.eclipse.org403 was a bad bug:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=558828
Its current behavior of a 301
redirection
to https://git.eclipse.orgis argued to be a feature that we should
embrace. I will not argue
that point, other than to point out that it's just annoying that
a simple
URL connection fails. But one could call
java.net.HttpURLConnection.setFollowRedirects(boolean)
globally or
java.net.HttpURLConnection.setInstanceFollowRedirects(boolean)
on the connection instance so that the 301 is followed...
Imagine now http://www.eclipse.orgmaking the same change. Every browser
would just follow the redirect.
Imagine that it just stops working entirely as in the 403 case;
that's
just a bug and if we needed to work around that, we'd need to
revisit every
wiki page and every scrap of documentation to change all the
URLs everywhere.
It seems to me that this is most clearly not feasible activity
and would
be addressed immediately.
So while I do understand your
thinking
and logic for why you changed this in the product definitions
(and I definitely
greatly appreciate all the hard work you folks to do
keep releng
working), to argue that we should/must change the legal text in
anticipation
of http://www.eclipsenot working reasonably or in
anticipation of some software being unable
to follow redirects is just too much of a leap from that
starting premise.
Even the internal browser can load http://git.eclipse.org/c/oomph/org.eclipse.oomph.git/plain/setups/org.eclipse.setupand redirects it to display https://git.eclipse.org/c/oomph/org.eclipse.oomph.git/plain/setups/org.eclipse.setupso one has to assume that even if http://www.eclipse.orgchanged its behavior to 301, it would
continue to work properly for browsing
purposes at the very least (and for most purposes for that
matter).
So I would argue that we avoid doing
anything that is highly likely to result in yet more license
prompts for
the users of Eclipse. I.e., just leave the SUA 2.0 alone and
revisit
it if/when there is a substantive reason to change the
meaningful content.
We all have better things to do...
Regards,
Ed
On 08.01.2020 09:08, Sravan K
Lakkimsetti
wrote:
Hi,
To
me not able to access license page is a bigger problem. If it
is legal
document it should be accessible. By using http we are
currently depending
on http->https redirection service available at eclipse
foundation.
We also seen this service can go down any time like it
happened on Jan
2, 2020. In my opinion to avoid dependency on redirection
service and single
point of failure it is better to move to https protocol
instead of unsecure
http. This is the reason I tried go with https.
What
is your suggestion on avoiding the similar failures in future.
How do we
proceed?
-Sravan
From:Ed Merks <ed.merks@xxxxxxxxx>
Sent: 08 January 2020 12:23
To: platform-dev@xxxxxxxxxxx
Subject: [EXTERNAL] Re: [platform-dev] 4.15 M1 milestone
week reminders
Sravan,
If "we" really want to change
the license that is currently used by literally 1000s of
features/products,
we should change it in the central license feature first and
hope (which
is a rather pointless hope) that all projects rebuild to use the
new version
and all of them contribute that to SimRel (which seems unlikely
to me given
this was not accomplished in the last 3 months). We'll also
need
to hope that all copies everywhere (EPP products, for example)
are also
changed (yet again). Then we should expect all users to
re-review
the new text because they will be forced to do so. The
not-so-impressed
user user can then agree yet again to what is effectively the
same license.
To me this all smacks of completely
gratuitous
work for dozens or hundreds of people with absolutely zero value
because
browsers switch to https automatically when visiting a web link
and even
if not, any concerned user can make sure they view links using
https if
they're concerned that they might be presented with a
bogus/hacked bit
of legal documentation.
In the end, it's really a very
inappropriate
plan for the platform to make this decision for everyone without
consulting
anyone. After all, it's a legal document so is it really your
role
to decide to alter it? Moreover, should we not question whether
the
date needs to be changed given this is no longer the "November
22,
2017" version of this legal document?
Regards,
Ed
On
08.01.2020 07:11, Sravan K Lakkimsetti wrote:
In
my opinion, we should move towards https instead of depending
on http->https
redirection made available by webmaster. We should plan to
move to https
in this release.
For
M1 I suggest to revert the change. But for M3 we should move
to https.
-Sravan
From:Ed Merks <ed.merks@xxxxxxxxx>
Sent: 08 January 2020 11:22
To: platform-dev@xxxxxxxxxxx
Subject: [EXTERNAL] Re: [platform-dev] 4.15 M1 milestone
week reminders
Noopur,
Please, please revert the changes
made
to do http -> https conversion in the license text of all the
*.product
files that was done in this Bugzilla:
h
We're back to having bogus license
variants
yet again:
https://download.eclipse.org/oomph/archive/reports/download.eclipse.org/eclipse/updates/4.15-I-builds/index.html
Please do not drop a build
that
is in this state into SimRel 2020-03 for M1.
Regards,
Ed
On
07.01.2020 16:57, Noopur Gupta wrote:
Hi
all,
As
mentioned in the reminders e-mail:
After
Monday 18:00 ET, no feature work or unrelated fixes are
allowed -- only
regression fixes.
Please
avoid releasing patches that are not important for that
milestone after
Monday, 18:00 ET.
For
example, here's the git log of the changes that went in
after I20200106-1805
and some of these could have been avoided:
https://download.eclipse.org/eclipse/downloads/drops4/I20200107-0600/gitLog.php
Regards,
Noopur
-----
Original message -----
From: "Noopur Gupta" <noopur_gupta@xxxxxxxxxx>
Sent by: platform-releng-dev-bounces@xxxxxxxxxxx
To: platform-dev@xxxxxxxxxxx,
eclipse-dev@xxxxxxxxxxx,
equinox-dev@xxxxxxxxxxx,
platform-releng-dev@xxxxxxxxxxx
Cc:
Subject: [EXTERNAL] [platform-releng-dev] 4.15 M1 milestone
week reminders
Date: Fri, Jan 3, 2020 9:50 AM
Hi
all,
Next week is the milestone week for 4.15 M1.
Monday:
Last day of development (and even then, no "big changes").
After
Monday 18:00 ET, no feature work or unrelated fixes are
allowed -- only
regression fixes.
Tuesday: All-day test pass. Nobody should develop or fix
anything.
Literally spend the entire day testing.
Wednesday:
Fix day with a focus on fixing regressions found during the
test day (Tuesday).
No unrelated fixes. Review and thoroughly test all commits.
- The last Wednesday build is the release candidate every
team signs
off on Thursday.
- The "New and Noteworthy" entries are due on
Wednesday
evening:
Git repo: ssh://git.eclipse.org/gitroot/www.eclipse.org/eclipse/news.git
Gerrit: ssh://git.eclipse.org:29418/www.eclipse.org/eclipse/news.git
Live website: https://www.eclipse.org/eclipse/news/4.15/
Thursday:
Sign-off after re-testing, or at least confirming no changes
have been
made to your component's code since the last time the
component was tested
well.
Friday:
Build is officially declared and made available.
- The master branch stays closed until the milestone is
officially released.
(That is, it is not enough that your component has signed
off.)
Wishing
you all a very Happy New Year 2020!
Thanks
& Regards,
Noopur
_______________________________________________
platform-releng-dev mailing list
platform-releng-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or
unsubscribe
from this list, visit
https://www.eclipse.org/mailman/listinfo/platform-releng-dev
_______________________________________________
platform-dev
mailing list
platform-dev@xxxxxxxxxxx
To
change your delivery options, retrieve your password, or
unsubscribe from
this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev
_______________________________________________
platform-dev
mailing list
platform-dev@xxxxxxxxxxx
To
change your delivery options, retrieve your password, or
unsubscribe from
this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev
_______________________________________________
platform-dev mailing list
platform-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or
unsubscribe
from this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev_______________________________________________
platform-dev mailing list
platform-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or
unsubscribe
from this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev
_______________________________________________
platform-dev mailing list
platform-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev