You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently we have download() function, and therefore e.g. mbedTLS. If you never update Julia, on e.g. macOS (which has no libsll), then the TLS/SSL library will get outdated, eventually insecure.
There's a solution, update Julia, e.g. with juliaup, but you need to do it manually, and it will not affect already running Julia programs.
If you never download (or update) from your Julia (or Julia-made binary app), then this is not a problem, but most apps (potentially) will, and currently download() is part of the API (and if not your program, then you with Pkg).
There needs just be a will to a) check if an update to Downloads.jl is needed (or some core package behind it such as LibCURL_jll.jl), and b) the package, or even some updated part of it, downloaded, c) and patched in at runtime better.
On some systems, e.g. Windows, the system TLS/SLL IS used, but it's not possible on all, e.g. macOS. In the modern world all apps seemingly (and operating systems), need to have some auto-update.
Since currently download() is part of the API, and just to download one file at a time, then I suggest Downloads.download() be allowed to take a list of files to download, trivially implemented serially (later with much faster HTTP/3), and NOT having it in Base Julia, only the stdlib Downloads, hopefully weans people of Base. Then it may help with Julia 2.0 migration and where the auto-update should reside, in Base or in Downloads stdlib.
There are other potential security issues, e.g. the already solved BiDi parser issue. For now this issue is only focused on download/internet issues, also unclear it would be easy to update the parser (let alone at runtime). Other d) such issues, could be implemented later, or discussed in a follow-up.
Linux has OpenSLL too, so it's not a problem, rather we use your own (statically linked?). Simply using what the OS provides on all operating systems, might just resolve this issue (except for d), that is). What happens when OpenSLL is upgraded on Linux? Do you need to restart the OS, or might it be possible to use it updated in an already running app?
Currently we have download() function, and therefore e.g. mbedTLS. If you never update Julia,
on e.g. macOS (which has no libsll), then the TLS/SSL library will get outdated, eventually insecure.There's a solution, update Julia, e.g. with juliaup, but you need to do it manually, and it will not affect already running Julia programs.
If you never download (or update) from your Julia (or Julia-made binary app), then this is not a problem, but most apps (potentially) will, and currently download() is part of the API (and if not your program, then you with Pkg).
There needs just be a will to a) check if an update to Downloads.jl is needed (or some core package behind it such as LibCURL_jll.jl), and b) the package, or even some updated part of it, downloaded, c) and patched in at runtime better.
On some systems, e.g. Windows, the system TLS/SLL IS used, but it's not possible on all, e.g. macOS. In the modern world all apps seemingly (and operating systems), need to have some auto-update.
Since currently download() is part of the API, and just to download one file at a time, then I suggest Downloads.download() be allowed to take a list of files to download, trivially implemented serially (later with much faster HTTP/3), and NOT having it in Base Julia, only the stdlib Downloads, hopefully weans people of Base. Then it may help with Julia 2.0 migration and where the auto-update should reside, in Base or in Downloads stdlib.
There are other potential security issues, e.g. the already solved BiDi parser issue. For now this issue is only focused on download/internet issues, also unclear it would be easy to update the parser (let alone at runtime). Other d) such issues, could be implemented later, or discussed in a follow-up.
#45856
The text was updated successfully, but these errors were encountered: