Project

General

Profile

Bug #13962

Change http://unicode.org to https

Added by MSP-Greg (Greg L) about 2 years ago. Updated almost 2 years ago.

Status:
Assigned
Priority:
Normal
Target version:
-
ruby -v:
ruby 2.5.0dev (2017-10-01 trunk 60085) [x64-mingw32]
[ruby-core:83074]

Description

I believe downloads from unicode.org can be done via https.

See attached patch.

Thank you.


Files

unicode.org.patch (435 Bytes) unicode.org.patch http -> https MSP-Greg (Greg L), 10/01/2017 08:09 PM

Related issues

Related to Ruby master - Misc #13974: Make sure Unicode files are only downloaded once, not repeatedly, for continuous integrationClosedActions
Related to Ruby master - Bug #13918: Appveyor failure - svn 59961 Use https instead of ftp for libffi downloadingAssignedActions

Associated revisions

Revision 61145
Added by duerst (Martin Dürst) almost 2 years ago

switch from http to https for Unicode data file downloads
(patch from MSP-Greg (Greg L), this closes issue #13962)

Revision 61145
Added by duerst (Martin Dürst) almost 2 years ago

switch from http to https for Unicode data file downloads
(patch from MSP-Greg (Greg L), this closes issue #13962)

Revision 61145
Added by duerst (Martin Dürst) almost 2 years ago

switch from http to https for Unicode data file downloads
(patch from MSP-Greg (Greg L), this closes issue #13962)

History

Updated by duerst (Martin Dürst) about 2 years ago

MSP-Greg (Greg L) wrote:

I believe downloads from unicode.org can be done via https.

Yes, that seems to be the case. Let me check with my contacts at the Unicode Consortium to see what they prefer (in particular for large data downloads).

Updated by shevegen (Robert A. Heiler) about 2 years ago

Secure our emojis! \o/

Updated by MSP-Greg (Greg L) about 2 years ago

shevegen (Robert A. Heiler) wrote:

Secure our emojis! \o/

Yeah, I've lost a few nights' sleep worrying about that...

I've got a patch to tool/downloader.rb that outputs the file size and URI, and I noticed it doing a local build. I think it's just good practice that all downloads are done via https, regardless of the 'threat potential' of the files.

Updated by duerst (Martin Dürst) about 2 years ago

  • Assignee set to duerst (Martin Dürst)

Updated by duerst (Martin Dürst) about 2 years ago

Just an intermediate report: HTTPS is available only since about a week, and the Unicode Consortium wants to check things a bit more before the availability is officially confirmed and announced. I'll wait until that time.

#6

Updated by duerst (Martin Dürst) about 2 years ago

  • Related to Misc #13974: Make sure Unicode files are only downloaded once, not repeatedly, for continuous integration added

Updated by normalperson (Eric Wong) about 2 years ago

duerst@it.aoyama.ac.jp wrote:

Just an intermediate report: HTTPS is available only since
about a week, and the Unicode Consortium wants to check things
a bit more before the availability is officially confirmed and
announced. I'll wait until that time.

Regardless of HTTPS or not; can we keep known-good
SHA-256/384/512/whatever signature(s) of the to-be-downloaded
files in our repository and validate the downloaded result?

IIRC, MiTM HTTPS proxies exist, and the CA system is still
vulnerable.

Updated by duerst (Martin Dürst) about 2 years ago

normalperson (Eric Wong) wrote:

Regardless of HTTPS or not; can we keep known-good
SHA-256/384/512/whatever signature(s) of the to-be-downloaded
files in our repository and validate the downloaded result?

IIRC, MiTM HTTPS proxies exist, and the CA system is still
vulnerable.

Unicode is currently looking at adding checksums. We should definitely integrate these into our process when they are available.

Also, please note that while the Unicode files get downloaded when compiling from scratch, we actually process them and commit the result into our repository (e.g. enc/unicode/10.0.0/casefold.h and enc/unicode/10.0.0/name2ctype.h). So any fishy stuff would quickly be detected if it generated diffs for these files.

#9

Updated by duerst (Martin Dürst) almost 2 years ago

  • Status changed from Open to Closed

Updated by hsbt (Hiroshi SHIBATA) almost 2 years ago

  • Status changed from Closed to Assigned
#11

Updated by hsbt (Hiroshi SHIBATA) almost 2 years ago

  • Related to Bug #13918: Appveyor failure - svn 59961 Use https instead of ftp for libffi downloading added

Also available in: Atom PDF