移出 sysimage
JuliaLang:master ← JuliaLang:kc/sparse_sysiamge
已打开 11:08PM - 18 Feb 22 UTC
cc @ViralBShah
```jl
julia> @time using SparseArrays
1.821477 seconds (2… .71 M allocations: 300.647 MiB, 0.32% compilation time)
julia> @time using SuiteSparse
0.242231 seconds (228.92 k allocations: 18.472 MiB, 40.21% compilation time)
julia> @time using Statistics
0.002257 seconds (4.08 k allocations: 428.594 KiB)
```
移除标准库
JuliaLang:master ← JuliaLang:kc/remove_delimited_files
已打开 12:48PM - 01 Jun 22 UTC
Requires https://github.com/JuliaLang/Pkg.jl/pull/3097 and https://github.com/Ju… liaRegistries/General/pull/61457
Fixes #44663
This is being planned not just DelimitedFiles , but also Statistics and the sparse ecosystem . In my opinion, there are several benefits:
Allow broader participation in these packages from contributors
Faster bugfixing and upgrades without having to wait for whole Julia release cycles
Make them less special and allow for alternatives to evolve, or become more flexible (e.g. we want to support many new sparse data types and solvers in a first class way)
Consolidate capabilities in certain ecosystems (e.g. basic stats is spread out across too many packages like Statistics.jl, StatsBase.jl etc., and it is complex for new users to navigate - not to mention it is difficult to maintain)
Various things are being planned to make this non-breaking, and more are discovered as we go forward:
The spun off packages will be 1.x.y version numbers so that there is no API breakage.
With Project and Manifest files, the stdlibs are already dependencies
Updating Pkg and related code to make this smooth .
_Originally posted by @ViralBShah in remove DelimitedFiles from being an stdlib by KristofferC · Pull Request #45540 · JuliaLang/julia · GitHub
题外话： Unicode 标准库感觉也符合移除的标准。CRC32c, LibGit2, SHA, TOML, UUIDs 这几个实际上是 Pkg 的依赖，当作标准库也比较勉强。
反过来说指定包作为标准库的坏处之一就是：为了兼容性，不方便升级版本。
已打开 05:47AM - 06 Jan 22 UTC
已关闭 06:44PM - 27 Feb 23 UTC
upstream
security
There have been several references to these security advisories for mbedtls in t… he issues / PRs in past few months. I'm not sure if they have received the needed attention since security advisory was not obvious in the title and there are no replies on the previous posts.
To make the issue clearer, I have produced the text of the advisories below.
# Local side channel attack on RSA
https://tls.mbed.org/tech-updates/security-advisories/mbedtls-security-advisory-2021-07-1
## Vulnerability
The Montgomery curves Curve25519 and Curve448, also known as x25519 and x448 when used for Diffie-Hellman, were designed to minimize the number of checks an implementation needs to do for secure use.
In particular, validity of the peer's public key needs not be checked, as long as the underlying multi-precision (bignum) arithmetic is constant-time. This is not the case in Mbed TLS, but validity checks were still skipped, so an attacker could exploit special inputs (low-order points) in order to cause variations in timing and memory access patterns that would in turn leak information about the private key.
## Impact
An attacker with access to precise enough timing and memory access information (for example, able to execute arbitrary code and sharing a memory cache with the victim) can recover the private keys used in static Diffie-Hellman with x25519 and x448.
## Resolution
Affected users will want to upgrade to Mbed TLS 3.0.0, 2.27.0 or 2.16.11 depending on the branch they're currently using.
# Local side channel attack on static Diffie-Hellman with Montgomery curves
https://tls.mbed.org/tech-updates/security-advisories/mbedtls-security-advisory-2021-07-2
## Vulnerability
The modular exponentiation operation in RSA uses a sliding window algorithm, with a memory access pattern that depends on the bits of the secret key.
Exponent blinding is used as a counter-measure: it prevents an attacker from correlating informations gathered on successive operation, but researchers found a way to recover enough information by observing a single operation, therefore by-passing this counter-measure.
## Impact
An attacker with access to precise enough timing and memory access information (typically an untrusted operating system attacking a secure enclave such as SGX or the TrustZone secure world) can recover the private keys used in RSA.
## Resolution
Affected users will want to upgrade to Mbed TLS 3.0.0, 2.27.0 or 2.16.11 depending on the branch they're currently using.
# Prior References
https://github.com/JuliaLang/julia/issues/42634
https://github.com/JuliaLang/julia/pull/42311#issuecomment-998867938
# Potential double-free after an out of memory error
https://tls.mbed.org/tech-updates/security-advisories/mbedtls-security-advisory-2021-12
## Vulnerability
If mbedtls_ssl_set_session() or mbedtls_ssl_get_session() were to fail with MBEDTLS_ERR_SSL_ALLOC_FAILED (in an out of memory condition), then calling mbedtls_ssl_session_free() and mbedtls_ssl_free() in the usual manner would cause an internal session buffer to be freed twice, due to two structures both having valid pointers to it after a call to ssl_session_copy().
## Impact
An attacker could potentially trigger the out of memory condition, and therefore use this bug to create memory corruption, which could then be further exploited or targetted.
## Resolution
Affected users will want to upgrade to Mbed TLS 3.1.0, 2.28.0 or 2.16.12 depending on the branch they're currently using.
## Work-around
Either do not call mbedtls_ssl_session_free() (which will unfortunately cause a memory leak) or set the mbedtls_ssl_session field ticket to NULL manually, in the case where either mbedtls_ssl_set_session() or mbedtls_ssl_get_session() returns MBEDTLS_ERR_SSL_ALLOC_FAILED.
2 个赞