Is updating dependencies frequently still good advice?
-
If you don't update the risk is being exposed to a vulnerability that was already fixed.
The risk of updating frequently is getting a supply chain attack before whatever means could mitigate that
-
Obviously, the real solution is to embrace Team NIH
-
When security kicked up a fuss about this I used to fire back asking if the security hole had been patched or is it that the static analysis they’re using hasn’t investigated the new version yet. Usually ran them off for a while.
-
How long does it take you to vet your dependencies and changes to them? How often can you do that? Guess that would determine how often you should update.
-
@sockpuppet7 said in Is updating dependencies frequently still good advice?:
If you don't update the risk is being exposed to a vulnerability that was already fixed.
The risk of updating frequently is getting a supply chain attack before whatever means could mitigate that
We're Doomed!
-
@cvi said in Is updating dependencies frequently still good advice?:
How long does it take you to vet your dependencies and changes to them? How often can you do that? Guess that would determine how often you should update.
I think it might take a while
List with 1209 dependencies
├── async-openai v0.19.1 │ ├── async-convert v1.0.0 │ │ └── async-trait v0.1.79 (proc-macro) │ │ ├── proc-macro2 v1.0.79 │ │ │ └── unicode-ident v1.0.12 │ │ ├── quote v1.0.35 │ │ │ └── proc-macro2 v1.0.79 (*) │ │ └── syn v2.0.55 │ │ ├── proc-macro2 v1.0.79 (*) │ │ ├── quote v1.0.35 (*) │ │ └── unicode-ident v1.0.12 │ ├── backoff v0.4.0 │ │ ├── futures-core v0.3.30 │ │ ├── getrandom v0.2.12 │ │ │ └── cfg-if v1.0.0 │ │ ├── instant v0.1.12 │ │ │ └── cfg-if v1.0.0 │ │ ├── pin-project-lite v0.2.13 │ │ ├── rand v0.8.5 │ │ │ ├── rand_chacha v0.3.1 │ │ │ │ ├── ppv-lite86 v0.2.17 │ │ │ │ └── rand_core v0.6.4 │ │ │ │ └── getrandom v0.2.12 (*) │ │ │ └── rand_core v0.6.4 (*) │ │ └── tokio v1.36.0 │ │ ├── bytes v1.6.0 │ │ ├── mio v0.8.11 │ │ │ └── windows-sys v0.48.0 │ │ │ └── windows-targets v0.48.5 │ │ │ └── windows_x86_64_msvc v0.48.5 │ │ ├── num_cpus v1.16.0 │ │ ├── parking_lot v0.12.1 │ │ │ ├── lock_api v0.4.11 │ │ │ │ └── scopeguard v1.2.0 │ │ │ │ [build-dependencies] │ │ │ │ └── autocfg v1.1.0 │ │ │ └── parking_lot_core v0.9.9 │ │ │ ├── cfg-if v1.0.0 │ │ │ ├── smallvec v1.13.2 │ │ │ └── windows-targets v0.48.5 (*) │ │ ├── pin-project-lite v0.2.13 │ │ ├── socket2 v0.5.6 │ │ │ └── windows-sys v0.52.0 │ │ │ └── windows-targets v0.52.4 │ │ │ └── windows_x86_64_msvc v0.52.4 │ │ ├── tokio-macros v2.2.0 (proc-macro) │ │ │ ├── proc-macro2 v1.0.79 (*) │ │ │ ├── quote v1.0.35 (*) │ │ │ └── syn v2.0.55 (*) │ │ └── windows-sys v0.48.0 (*) │ ├── base64 v0.21.7 │ ├── bytes v1.6.0 │ ├── derive_builder v0.12.0 │ │ └── derive_builder_macro v0.12.0 (proc-macro) │ │ ├── derive_builder_core v0.12.0 │ │ │ ├── darling v0.14.4 │ │ │ │ ├── darling_core v0.14.4 │ │ │ │ │ ├── fnv v1.0.7 │ │ │ │ │ ├── ident_case v1.0.1 │ │ │ │ │ ├── proc-macro2 v1.0.79 (*) │ │ │ │ │ ├── quote v1.0.35 (*) │ │ │ │ │ ├── strsim v0.10.0 │ │ │ │ │ └── syn v1.0.109 │ │ │ │ │ ├── proc-macro2 v1.0.79 (*) │ │ │ │ │ ├── quote v1.0.35 (*) │ │ │ │ │ └── unicode-ident v1.0.12 │ │ │ │ └── darling_macro v0.14.4 (proc-macro) │ │ │ │ ├── darling_core v0.14.4 (*) │ │ │ │ ├── quote v1.0.35 (*) │ │ │ │ └── syn v1.0.109 (*) │ │ │ ├── proc-macro2 v1.0.79 (*) │ │ │ ├── quote v1.0.35 (*) │ │ │ └── syn v1.0.109 (*) │ │ └── syn v1.0.109 (*) │ ├── futures v0.3.30 │ │ ├── futures-channel v0.3.30 │ │ │ ├── futures-core v0.3.30 │ │ │ └── futures-sink v0.3.30 │ │ ├── futures-core v0.3.30 │ │ ├── futures-executor v0.3.30 │ │ │ ├── futures-core v0.3.30 │ │ │ ├── futures-task v0.3.30 │ │ │ └── futures-util v0.3.30 │ │ │ ├── futures-channel v0.3.30 (*) │ │ │ ├── futures-core v0.3.30 │ │ │ ├── futures-io v0.3.30 │ │ │ ├── futures-macro v0.3.30 (proc-macro) │ │ │ │ ├── proc-macro2 v1.0.79 (*) │ │ │ │ ├── quote v1.0.35 (*) │ │ │ │ └── syn v2.0.55 (*) │ │ │ ├── futures-sink v0.3.30 │ │ │ ├── futures-task v0.3.30 │ │ │ ├── memchr v2.7.1 │ │ │ ├── pin-project-lite v0.2.13 │ │ │ ├── pin-utils v0.1.0 │ │ │ └── slab v0.4.9 │ │ │ [build-dependencies] │ │ │ └── autocfg v1.1.0 │ │ ├── futures-io v0.3.30 │ │ ├── futures-sink v0.3.30 │ │ ├── futures-task v0.3.30 │ │ └── futures-util v0.3.30 (*) │ ├── rand v0.8.5 (*) │ ├── reqwest v0.11.27 │ │ ├── base64 v0.21.7 │ │ ├── bytes v1.6.0 │ │ ├── encoding_rs v0.8.33 │ │ │ └── cfg-if v1.0.0 │ │ ├── futures-core v0.3.30 │ │ ├── futures-util v0.3.30 (*) │ │ ├── h2 v0.3.25 │ │ │ ├── bytes v1.6.0 │ │ │ ├── fnv v1.0.7 │ │ │ ├── futures-core v0.3.30 │ │ │ ├── futures-sink v0.3.30 │ │ │ ├── futures-util v0.3.30 (*) │ │ │ ├── http v0.2.12 │ │ │ │ ├── bytes v1.6.0 │ │ │ │ ├── fnv v1.0.7 │ │ │ │ └── itoa v1.0.10 │ │ │ ├── indexmap v2.2.6 │ │ │ │ ├── equivalent v1.0.1 │ │ │ │ ├── hashbrown v0.14.3 │ │ │ │ │ ├── ahash v0.8.11 │ │ │ │ │ │ ├── cfg-if v1.0.0 │ │ │ │ │ │ ├── getrandom v0.2.12 (*) │ │ │ │ │ │ ├── once_cell v1.19.0 │ │ │ │ │ │ └── zerocopy v0.7.32 │ │ │ │ │ │ [build-dependencies] │ │ │ │ │ │ └── version_check v0.9.4 │ │ │ │ │ └── allocator-api2 v0.2.16 │ │ │ │ └── serde v1.0.197 │ │ │ │ └── serde_derive v1.0.197 (proc-macro) │ │ │ │ ├── proc-macro2 v1.0.79 (*) │ │ │ │ ├── quote v1.0.35 (*) │ │ │ │ └── syn v2.0.55 (*) │ │ │ ├── slab v0.4.9 (*) │ │ │ ├── tokio v1.36.0 (*) │ │ │ ├── tokio-util v0.7.10 │ │ │ │ ├── bytes v1.6.0 │ │ │ │ ├── futures-core v0.3.30 │ │ │ │ ├── futures-sink v0.3.30 │ │ │ │ ├── pin-project-lite v0.2.13 │ │ │ │ ├── tokio v1.36.0 (*) │ │ │ │ └── tracing v0.1.40 │ │ │ │ ├── log v0.4.21 │ │ │ │ │ └── value-bag v1.8.1 │ │ │ │ ├── pin-project-lite v0.2.13 │ │ │ │ ├── tracing-attributes v0.1.27 (proc-macro) │ │ │ │ │ ├── proc-macro2 v1.0.79 (*) │ │ │ │ │ ├── quote v1.0.35 (*) │ │ │ │ │ └── syn v2.0.55 (*) │ │ │ │ └── tracing-core v0.1.32 │ │ │ │ └── once_cell v1.19.0 │ │ │ └── tracing v0.1.40 (*) │ │ ├── http v0.2.12 (*) │ │ ├── http-body v0.4.6 │ │ │ ├── bytes v1.6.0 │ │ │ ├── http v0.2.12 (*) │ │ │ └── pin-project-lite v0.2.13 │ │ ├── hyper v0.14.28 │ │ │ ├── bytes v1.6.0 │ │ │ ├── futures-channel v0.3.30 (*) │ │ │ ├── futures-core v0.3.30 │ │ │ ├── futures-util v0.3.30 (*) │ │ │ ├── h2 v0.3.25 (*) │ │ │ ├── http v0.2.12 (*) │ │ │ ├── http-body v0.4.6 (*) │ │ │ ├── httparse v1.8.0 │ │ │ ├── httpdate v1.0.3 │ │ │ ├── itoa v1.0.10 │ │ │ ├── pin-project-lite v0.2.13 │ │ │ ├── socket2 v0.5.6 (*) │ │ │ ├── tokio v1.36.0 (*) │ │ │ ├── tower-service v0.3.2 │ │ │ ├── tracing v0.1.40 (*) │ │ │ └── want v0.3.1 │ │ │ └── try-lock v0.2.5 │ │ ├── hyper-rustls v0.24.2 │ │ │ ├── futures-util v0.3.30 (*) │ │ │ ├── http v0.2.12 (*) │ │ │ ├── hyper v0.14.28 (*) │ │ │ ├── rustls v0.21.10 │ │ │ │ ├── log v0.4.21 (*) │ │ │ │ ├── ring v0.17.8 │ │ │ │ │ ├── cfg-if v1.0.0 │ │ │ │ │ ├── getrandom v0.2.12 (*) │ │ │ │ │ ├── spin v0.9.8 │ │ │ │ │ │ └── lock_api v0.4.11 (*) │ │ │ │ │ └── untrusted v0.9.0 │ │ │ │ │ [build-dependencies] │ │ │ │ │ └── cc v1.0.90 │ │ │ │ ├── rustls-webpki v0.101.7 │ │ │ │ │ ├── ring v0.17.8 (*) │ │ │ │ │ └── untrusted v0.9.0 │ │ │ │ └── sct v0.7.1 │ │ │ │ ├── ring v0.17.8 (*) │ │ │ │ └── untrusted v0.9.0 │ │ │ ├── tokio v1.36.0 (*) │ │ │ └── tokio-rustls v0.24.1 │ │ │ ├── rustls v0.21.10 (*) │ │ │ └── tokio v1.36.0 (*) │ │ ├── ipnet v2.9.0 │ │ ├── log v0.4.21 (*) │ │ ├── mime v0.3.17 │ │ ├── mime_guess v2.0.4 │ │ │ ├── mime v0.3.17 │ │ │ └── unicase v2.7.0 │ │ │ [build-dependencies] │ │ │ └── version_check v0.9.4 │ │ │ [build-dependencies] │ │ │ └── unicase v2.7.0 (*) │ │ ├── once_cell v1.19.0 │ │ ├── percent-encoding v2.3.1 │ │ ├── pin-project-lite v0.2.13 │ │ ├── rustls v0.21.10 (*) │ │ ├── rustls-native-certs v0.6.3 │ │ │ ├── rustls-pemfile v1.0.4 │ │ │ │ └── base64 v0.21.7 │ │ │ └── schannel v0.1.23 │ │ │ └── windows-sys v0.52.0 (*) │ │ ├── rustls-pemfile v1.0.4 (*) │ │ ├── serde v1.0.197 (*) │ │ ├── serde_json v1.0.114 │ │ │ ├── itoa v1.0.10 │ │ │ ├── ryu v1.0.17 │ │ │ └── serde v1.0.197 (*) │ │ ├── serde_urlencoded v0.7.1 │ │ │ ├── form_urlencoded v1.2.1 │ │ │ │ └── percent-encoding v2.3.1 │ │ │ ├── itoa v1.0.10 │ │ │ ├── ryu v1.0.17 │ │ │ └── serde v1.0.197 (*) │ │ ├── sync_wrapper v0.1.2 │ │ ├── tokio v1.36.0 (*) │ │ ├── tokio-rustls v0.24.1 (*) │ │ ├── tokio-util v0.7.10 (*) │ │ ├── tower-service v0.3.2 │ │ ├── url v2.5.0 │ │ │ ├── form_urlencoded v1.2.1 (*) │ │ │ ├── idna v0.5.0 │ │ │ │ ├── unicode-bidi v0.3.15 │ │ │ │ └── unicode-normalization v0.1.23 │ │ │ │ └── tinyvec v1.6.0 │ │ │ │ └── tinyvec_macros v0.1.1 │ │ │ └── percent-encoding v2.3.1 │ │ └── winreg v0.50.0 │ │ ├── cfg-if v1.0.0 │ │ └── windows-sys v0.48.0 (*) │ ├── reqwest-eventsource v0.4.0 │ │ ├── eventsource-stream v0.2.3 │ │ │ ├── futures-core v0.3.30 │ │ │ ├── nom v7.1.3 │ │ │ │ ├── memchr v2.7.1 │ │ │ │ └── minimal-lexical v0.2.1 │ │ │ └── pin-project-lite v0.2.13 │ │ ├── futures-core v0.3.30 │ │ ├── futures-timer v3.0.3 │ │ ├── mime v0.3.17 │ │ ├── nom v7.1.3 (*) │ │ ├── pin-project-lite v0.2.13 │ │ ├── reqwest v0.11.27 (*) │ │ └── thiserror v1.0.58 │ │ └── thiserror-impl v1.0.58 (proc-macro) │ │ ├── proc-macro2 v1.0.79 (*) │ │ ├── quote v1.0.35 (*) │ │ └── syn v2.0.55 (*) │ ├── secrecy v0.8.0 │ │ ├── serde v1.0.197 (*) │ │ └── zeroize v1.7.0 │ ├── serde v1.0.197 (*) │ ├── serde_json v1.0.114 (*) │ ├── thiserror v1.0.58 (*) │ ├── tokio v1.36.0 (*) │ ├── tokio-stream v0.1.15 │ │ ├── futures-core v0.3.30 │ │ ├── pin-project-lite v0.2.13 │ │ └── tokio v1.36.0 (*) │ ├── tokio-util v0.7.10 (*) │ └── tracing v0.1.40 (*) ├── backoff v0.4.0 (*) ├── chrono v0.4.35 │ ├── num-traits v0.2.18 │ │ └── libm v0.2.8 │ │ [build-dependencies] │ │ └── autocfg v1.1.0 │ ├── serde v1.0.197 (*) │ └── windows-targets v0.52.4 (*) ├── dotenv v0.15.0 ├── image v0.25.1 │ ├── bytemuck v1.15.0 │ ├── byteorder v1.5.0 │ ├── color_quant v1.1.0 │ ├── exr v1.72.0 │ │ ├── bit_field v0.10.2 │ │ ├── flume v0.11.0 │ │ │ └── spin v0.9.8 (*) │ │ ├── half v2.4.0 │ │ │ └── cfg-if v1.0.0 │ │ ├── lebe v0.5.2 │ │ ├── miniz_oxide v0.7.2 │ │ │ ├── adler v1.0.2 │ │ │ └── simd-adler32 v0.3.7 │ │ ├── rayon-core v1.12.1 │ │ │ ├── crossbeam-deque v0.8.5 │ │ │ │ ├── crossbeam-epoch v0.9.18 │ │ │ │ │ └── crossbeam-utils v0.8.19 │ │ │ │ └── crossbeam-utils v0.8.19 │ │ │ └── crossbeam-utils v0.8.19 │ │ ├── smallvec v1.13.2 │ │ └── zune-inflate v0.2.54 │ │ └── simd-adler32 v0.3.7 │ ├── gif v0.13.1 │ │ ├── color_quant v1.1.0 │ │ └── weezl v0.1.8 │ ├── image-webp v0.1.1 │ │ ├── byteorder v1.5.0 │ │ └── thiserror v1.0.58 (*) │ ├── num-traits v0.2.18 (*) │ ├── png v0.17.13 │ │ ├── bitflags v1.3.2 │ │ ├── crc32fast v1.4.0 │ │ │ └── cfg-if v1.0.0 │ │ ├── fdeflate v0.3.4 │ │ │ └── simd-adler32 v0.3.7 │ │ ├── flate2 v1.0.28 │ │ │ ├── crc32fast v1.4.0 (*) │ │ │ └── miniz_oxide v0.7.2 (*) │ │ └── miniz_oxide v0.7.2 (*) │ ├── qoi v0.4.1 │ │ └── bytemuck v1.15.0 │ ├── ravif v0.11.5 │ │ ├── avif-serialize v0.8.1 │ │ │ └── arrayvec v0.7.4 │ │ ├── imgref v1.10.1 │ │ ├── loop9 v0.1.5 │ │ │ └── imgref v1.10.1 │ │ ├── quick-error v2.0.1 │ │ ├── rav1e v0.7.1 │ │ │ ├── arg_enum_proc_macro v0.3.4 (proc-macro) │ │ │ │ ├── proc-macro2 v1.0.79 (*) │ │ │ │ ├── quote v1.0.35 (*) │ │ │ │ └── syn v2.0.55 (*) │ │ │ ├── arrayvec v0.7.4 │ │ │ ├── av1-grain v0.2.3 │ │ │ │ ├── anyhow v1.0.81 │ │ │ │ ├── arrayvec v0.7.4 │ │ │ │ ├── log v0.4.21 (*) │ │ │ │ ├── nom v7.1.3 (*) │ │ │ │ ├── num-rational v0.4.1 │ │ │ │ │ ├── num-bigint v0.4.4 │ │ │ │ │ │ ├── num-integer v0.1.46 │ │ │ │ │ │ │ └── num-traits v0.2.18 (*) │ │ │ │ │ │ └── num-traits v0.2.18 (*) │ │ │ │ │ │ [build-dependencies] │ │ │ │ │ │ └── autocfg v1.1.0 │ │ │ │ │ ├── num-integer v0.1.46 (*) │ │ │ │ │ └── num-traits v0.2.18 (*) │ │ │ │ │ [build-dependencies] │ │ │ │ │ └── autocfg v1.1.0 │ │ │ │ └── v_frame v0.3.8 │ │ │ │ ├── aligned-vec v0.5.0 │ │ │ │ └── num-traits v0.2.18 (*) │ │ │ ├── bitstream-io v2.2.0 │ │ │ ├── cfg-if v1.0.0 │ │ │ ├── itertools v0.12.1 │ │ │ │ └── either v1.10.0 │ │ │ │ └── serde v1.0.197 (*) │ │ │ ├── libc v0.2.153 │ │ │ ├── log v0.4.21 (*) │ │ │ ├── maybe-rayon v0.1.1 │ │ │ │ ├── cfg-if v1.0.0 │ │ │ │ └── rayon v1.10.0 │ │ │ │ ├── either v1.10.0 (*) │ │ │ │ └── rayon-core v1.12.1 (*) │ │ │ ├── new_debug_unreachable v1.0.6 │ │ │ ├── noop_proc_macro v0.3.0 (proc-macro) │ │ │ ├── num-derive v0.4.2 (proc-macro) │ │ │ │ ├── proc-macro2 v1.0.79 (*) │ │ │ │ ├── quote v1.0.35 (*) │ │ │ │ └── syn v2.0.55 (*) │ │ │ ├── num-traits v0.2.18 (*) │ │ │ ├── once_cell v1.19.0 │ │ │ ├── paste v1.0.14 (proc-macro) │ │ │ ├── profiling v1.0.15 │ │ │ │ └── profiling-procmacros v1.0.15 (proc-macro) │ │ │ │ ├── quote v1.0.35 (*) │ │ │ │ └── syn v2.0.55 (*) │ │ │ ├── simd_helpers v0.1.0 (proc-macro) │ │ │ │ └── quote v1.0.35 (*) │ │ │ ├── thiserror v1.0.58 (*) │ │ │ └── v_frame v0.3.8 (*) │ │ │ [build-dependencies] │ │ │ └── built v0.7.1 │ │ ├── rayon v1.10.0 (*) │ │ └── rgb v0.8.37 │ │ └── bytemuck v1.15.0 │ ├── rayon v1.10.0 (*) │ ├── rgb v0.8.37 (*) │ ├── tiff v0.9.1 │ │ ├── flate2 v1.0.28 (*) │ │ ├── jpeg-decoder v0.3.1 │ │ └── weezl v0.1.8 │ ├── zune-core v0.4.12 │ └── zune-jpeg v0.4.11 │ └── zune-core v0.4.12 ├── indoc v2.0.5 (proc-macro) ├── json v0.12.4 ├── markdown v1.0.0-alpha.16 │ └── unicode-id v0.3.4 ├── reqwest v0.12.1 │ ├── base64 v0.21.7 │ ├── bytes v1.6.0 │ ├── encoding_rs v0.8.33 (*) │ ├── futures-core v0.3.30 │ ├── futures-util v0.3.30 (*) │ ├── h2 v0.4.3 │ │ ├── bytes v1.6.0 │ │ ├── fnv v1.0.7 │ │ ├── futures-core v0.3.30 │ │ ├── futures-sink v0.3.30 │ │ ├── futures-util v0.3.30 (*) │ │ ├── http v1.1.0 │ │ │ ├── bytes v1.6.0 │ │ │ ├── fnv v1.0.7 │ │ │ └── itoa v1.0.10 │ │ ├── indexmap v2.2.6 (*) │ │ ├── slab v0.4.9 (*) │ │ ├── tokio v1.36.0 (*) │ │ ├── tokio-util v0.7.10 (*) │ │ └── tracing v0.1.40 (*) │ ├── http v1.1.0 (*) │ ├── http-body v1.0.0 │ │ ├── bytes v1.6.0 │ │ └── http v1.1.0 (*) │ ├── http-body-util v0.1.1 │ │ ├── bytes v1.6.0 │ │ ├── futures-core v0.3.30 │ │ ├── http v1.1.0 (*) │ │ ├── http-body v1.0.0 (*) │ │ └── pin-project-lite v0.2.13 │ ├── hyper v1.2.0 │ │ ├── bytes v1.6.0 │ │ ├── futures-channel v0.3.30 (*) │ │ ├── futures-util v0.3.30 (*) │ │ ├── h2 v0.4.3 (*) │ │ ├── http v1.1.0 (*) │ │ ├── http-body v1.0.0 (*) │ │ ├── httparse v1.8.0 │ │ ├── itoa v1.0.10 │ │ ├── pin-project-lite v0.2.13 │ │ ├── smallvec v1.13.2 │ │ ├── tokio v1.36.0 (*) │ │ └── want v0.3.1 (*) │ ├── hyper-tls v0.6.0 │ │ ├── bytes v1.6.0 │ │ ├── http-body-util v0.1.1 (*) │ │ ├── hyper v1.2.0 (*) │ │ ├── hyper-util v0.1.3 │ │ │ ├── bytes v1.6.0 │ │ │ ├── futures-channel v0.3.30 (*) │ │ │ ├── futures-util v0.3.30 (*) │ │ │ ├── http v1.1.0 (*) │ │ │ ├── http-body v1.0.0 (*) │ │ │ ├── hyper v1.2.0 (*) │ │ │ ├── pin-project-lite v0.2.13 │ │ │ ├── socket2 v0.5.6 (*) │ │ │ ├── tokio v1.36.0 (*) │ │ │ ├── tower v0.4.13 │ │ │ │ ├── futures-core v0.3.30 │ │ │ │ ├── futures-util v0.3.30 (*) │ │ │ │ ├── pin-project v1.1.5 │ │ │ │ │ └── pin-project-internal v1.1.5 (proc-macro) │ │ │ │ │ ├── proc-macro2 v1.0.79 (*) │ │ │ │ │ ├── quote v1.0.35 (*) │ │ │ │ │ └── syn v2.0.55 (*) │ │ │ │ ├── pin-project-lite v0.2.13 │ │ │ │ ├── tokio v1.36.0 (*) │ │ │ │ ├── tower-layer v0.3.2 │ │ │ │ ├── tower-service v0.3.2 │ │ │ │ └── tracing v0.1.40 (*) │ │ │ ├── tower-service v0.3.2 │ │ │ └── tracing v0.1.40 (*) │ │ ├── native-tls v0.2.11 │ │ │ └── schannel v0.1.23 (*) │ │ ├── tokio v1.36.0 (*) │ │ ├── tokio-native-tls v0.3.1 │ │ │ ├── native-tls v0.2.11 (*) │ │ │ └── tokio v1.36.0 (*) │ │ └── tower-service v0.3.2 │ ├── hyper-util v0.1.3 (*) │ ├── ipnet v2.9.0 │ ├── log v0.4.21 (*) │ ├── mime v0.3.17 │ ├── native-tls v0.2.11 (*) │ ├── once_cell v1.19.0 │ ├── percent-encoding v2.3.1 │ ├── pin-project-lite v0.2.13 │ ├── rustls-pemfile v1.0.4 (*) │ ├── serde v1.0.197 (*) │ ├── serde_json v1.0.114 (*) │ ├── serde_urlencoded v0.7.1 (*) │ ├── sync_wrapper v0.1.2 │ ├── tokio v1.36.0 (*) │ ├── tokio-native-tls v0.3.1 (*) │ ├── tower-service v0.3.2 │ ├── url v2.5.0 (*) │ └── winreg v0.50.0 (*) ├── rocket v0.5.0 │ ├── async-stream v0.3.5 │ │ ├── async-stream-impl v0.3.5 (proc-macro) │ │ │ ├── proc-macro2 v1.0.79 (*) │ │ │ ├── quote v1.0.35 (*) │ │ │ └── syn v2.0.55 (*) │ │ ├── futures-core v0.3.30 │ │ └── pin-project-lite v0.2.13 │ ├── async-trait v0.1.79 (proc-macro) (*) │ ├── atomic v0.5.3 │ ├── binascii v0.1.4 │ ├── bytes v1.6.0 │ ├── either v1.10.0 (*) │ ├── figment v0.10.15 │ │ ├── pear v0.2.9 │ │ │ ├── inlinable_string v0.1.15 │ │ │ ├── pear_codegen v0.2.9 (proc-macro) │ │ │ │ ├── proc-macro2 v1.0.79 (*) │ │ │ │ ├── proc-macro2-diagnostics v0.10.1 │ │ │ │ │ ├── proc-macro2 v1.0.79 (*) │ │ │ │ │ ├── quote v1.0.35 (*) │ │ │ │ │ ├── syn v2.0.55 (*) │ │ │ │ │ └── yansi v1.0.1 │ │ │ │ │ [build-dependencies] │ │ │ │ │ └── version_check v0.9.4 │ │ │ │ ├── quote v1.0.35 (*) │ │ │ │ └── syn v2.0.55 (*) │ │ │ └── yansi v1.0.1 │ │ │ └── is-terminal v0.4.12 │ │ │ └── windows-sys v0.52.0 (*) │ │ ├── serde v1.0.197 (*) │ │ ├── toml v0.8.12 │ │ │ ├── serde v1.0.197 (*) │ │ │ ├── serde_spanned v0.6.5 │ │ │ │ └── serde v1.0.197 (*) │ │ │ ├── toml_datetime v0.6.5 │ │ │ │ └── serde v1.0.197 (*) │ │ │ └── toml_edit v0.22.9 │ │ │ ├── indexmap v2.2.6 (*) │ │ │ ├── serde v1.0.197 (*) │ │ │ ├── serde_spanned v0.6.5 (*) │ │ │ ├── toml_datetime v0.6.5 (*) │ │ │ └── winnow v0.6.5 │ │ └── uncased v0.9.10 │ │ └── serde v1.0.197 (*) │ │ [build-dependencies] │ │ └── version_check v0.9.4 │ │ [build-dependencies] │ │ └── version_check v0.9.4 │ ├── futures v0.3.30 (*) │ ├── indexmap v2.2.6 (*) │ ├── log v0.4.21 (*) │ ├── memchr v2.7.1 │ ├── multer v2.1.0 │ │ ├── bytes v1.6.0 │ │ ├── encoding_rs v0.8.33 (*) │ │ ├── futures-util v0.3.30 (*) │ │ ├── http v0.2.12 (*) │ │ ├── httparse v1.8.0 │ │ ├── log v0.4.21 (*) │ │ ├── memchr v2.7.1 │ │ ├── mime v0.3.17 │ │ ├── spin v0.9.8 (*) │ │ ├── tokio v1.36.0 (*) │ │ └── tokio-util v0.7.10 (*) │ │ [build-dependencies] │ │ └── version_check v0.9.4 │ ├── num_cpus v1.16.0 │ ├── parking_lot v0.12.1 (*) │ ├── pin-project-lite v0.2.13 │ ├── rand v0.8.5 (*) │ ├── ref-cast v1.0.22 │ │ └── ref-cast-impl v1.0.22 (proc-macro) │ │ ├── proc-macro2 v1.0.79 (*) │ │ ├── quote v1.0.35 (*) │ │ └── syn v2.0.55 (*) │ ├── rocket_codegen v0.5.0 (proc-macro) │ │ ├── devise v0.4.1 │ │ │ ├── devise_codegen v0.4.1 (proc-macro) │ │ │ │ ├── devise_core v0.4.1 │ │ │ │ │ ├── bitflags v2.5.0 │ │ │ │ │ ├── proc-macro2 v1.0.79 (*) │ │ │ │ │ ├── proc-macro2-diagnostics v0.10.1 (*) │ │ │ │ │ ├── quote v1.0.35 (*) │ │ │ │ │ └── syn v2.0.55 (*) │ │ │ │ └── quote v1.0.35 (*) │ │ │ └── devise_core v0.4.1 (*) │ │ ├── glob v0.3.1 │ │ ├── indexmap v2.2.6 │ │ │ ├── equivalent v1.0.1 │ │ │ └── hashbrown v0.14.3 │ │ ├── proc-macro2 v1.0.79 (*) │ │ ├── quote v1.0.35 (*) │ │ ├── rocket_http v0.5.0 │ │ │ ├── cookie v0.18.0 │ │ │ │ ├── percent-encoding v2.3.1 │ │ │ │ └── time v0.3.34 │ │ │ │ ├── deranged v0.3.11 │ │ │ │ │ └── powerfmt v0.2.0 │ │ │ │ ├── itoa v1.0.10 │ │ │ │ ├── num-conv v0.1.0 │ │ │ │ ├── powerfmt v0.2.0 │ │ │ │ ├── time-core v0.1.2 │ │ │ │ └── time-macros v0.2.17 (proc-macro) │ │ │ │ ├── num-conv v0.1.0 │ │ │ │ └── time-core v0.1.2 │ │ │ │ [build-dependencies] │ │ │ │ └── version_check v0.9.4 │ │ │ ├── either v1.10.0 │ │ │ ├── futures v0.3.30 │ │ │ │ ├── futures-channel v0.3.30 (*) │ │ │ │ ├── futures-core v0.3.30 │ │ │ │ ├── futures-io v0.3.30 │ │ │ │ ├── futures-sink v0.3.30 │ │ │ │ ├── futures-task v0.3.30 │ │ │ │ └── futures-util v0.3.30 │ │ │ │ ├── futures-core v0.3.30
-
And by updating the dependencies you may break something. And no enjoy searching for the bad bug (e.g. just not doing anything, no crash, but no expected action either...)
-
@sockpuppet7 How much is that without the repetitions?
-
@cvi said in Is updating dependencies frequently still good advice?:
@sockpuppet7 How much is that without the repetitions?
If my regexes are correct, there are 291
adler
ahash
aho-corasick
aliasable
aligned-vec
anyhow
arrayvec
async-channel
async-convert
async-executor
async-global-executor
async-io
async-lock
async-openai
async-std
async-stream
async-stream-impl
async-task
async-trait
atoi
atomic
atomic-waker
autocfg
avif-serialize
backoff
bigdecimal
binascii
bitflags
bitstream-io
block-buffer
blocking
bstr
built
bytemuck
byteorder
bytes
cc
cfg-if
chrono
chrono-tz
chrono-tz-build
concurrent-queue
const-oid
cookie
cpufeatures
crc
crc-catalog
crossbeam-channel
crossbeam-deque
crossbeam-epoch
crossbeam-queue
crossbeam-utils
crypto-common
darling
der
deranged
derivative
deunicode
devise
digest
dotenv
dotenvy
either
equivalent
errno
event-listener
event-listener-strategy
eventsource-stream
exr
fastrand
fdeflate
figment
filetime
flume
fnv
futures
futures-channel
futures-core
futures-executor
futures-intrusive
futures-io
futures-lite
futures-macro
futures-sink
futures-task
futures-timer
futures-util
generic-array
getrandom
gif
glob
globset
globwalk
half
hashbrown
hashlink
heck
hex
hkdf
hmac
http
http-body
http-body-util
httparse
httpdate
humansize
hyper
hyper-rustls
hyper-tls
hyper-util
idna
ignore
image
image-webp
imgref
indexmap
indoc
inherent
instant
io-lifetimes
ipnet
is-terminal
itertools
itoa
jpeg-decoder
json
kv-log-macro
lebe
libc
libm
log
markdown
maybe-rayon
memchr
mime
minimal-lexical
mio
multer
native-tls
nom
normpath
notify
nu-ansi-term
num-bigint
num-bigint-dig
num-conv
num-derive
num-integer
num-iter
num-rational
num-traits
ordered-float
ouroboros
overload
parking
parse-zoneinfo
paste
pear
percent-encoding
pest
phf
pin-project
pin-project-internal
pin-project-lite
pin-utils
piper
png
polling
powerfmt
proc-macro-error
proc-macro-error-attr
profiling
profiling-procmacros
qoi
quick-error
quote
rand
ravif
rayon
rayon-core
ref-cast
ref-cast-impl
regex
regex-automata
regex-syntax
reqwest
reqwest-eventsource
rgb
ring
rocket
rsa
rustix
rustls
rustls-native-certs
rustls-pemfile
rustls-webpki
ryu
same-file
schannel
scopeguard
sct
sea-bae
sea-orm
sea-orm-macros
sea-query
sea-query-binder
secrecy
serde
sharded-slab
signature
siphasher
slab
slug
slugify
smallvec
spin
spki
sqlformat
sqlx
sqlx-core
sqlx-mysql
stable-pattern
state
stringprep
strsim
strum
subtle
syn
tempfile
tera
thiserror
thiserror-impl
tiff
time
time-core
time-macros
tinyvec
tokio
tokio-macros
tokio-native-tls
tokio-rustls
tokio-stream
tokio-util
toml
tower
tower-layer
tower-service
tracing
tracing-attributes
tracing-core
tracing-log
tracing-subscriber
try-lock
typenum
ubyte
ucd-trie
uncased
unic-char-property
unic-char-range
unic-common
unic-segment
unic-ucd-segment
unic-ucd-version
unicase
unicode-bidi
unicode-id
unicode-ident
unicode-normalization
unicode-xid
unidecode
untrusted
url
uuid
value-bag
waker-fn
walkdir
want
weezl
whoami
winapi
winapi-util
windows-sys
windows-targets
winnow
winreg
yansi
zerocopy
zeroize
zune-core
zune-inflate
zune-jpegedit: And cargo build progress bar goes up to 525, and I dunno why the mismatch
-
-
@homoBalkanus said in Is updating dependencies frequently still good advice?:
@sockpuppet7 said in Is updating dependencies frequently still good advice?:
zune
You got me curious on it, but it was just an image library some of the dependencies bring with it
-
@sockpuppet7 Updating dependencies is still good advice.
Supply chain attacks are no different a threat than the possibility of a newer version having new vulnerabilities.
Nowadays, software tends to go out of support very quickly and we tend to have a lot of dependencies. So, we have to go back and visit our software often and there is a larger potential of something actually breaking.
The only solution is to write a lot of those automated tests that everyone picks on - the ones that do nothing but a really simple task that's expected to succeed. These are a cheap way to validate that your updated dependency actually works.
Well, that's not the only solution. We can also get off the CADT train and write code on stable platforms like .Net Framework, which has been about very stable and well supported for 20 years.
-
@sockpuppet7 said in Is updating dependencies frequently still good advice?:
If you don't update the risk is being exposed to a vulnerability that was already fixed.
The risk of updating frequently is getting a supply chain attack before whatever means could mitigate that
How frequently do you mean? Is it in an Enterprise™ context, or one where always having the latest of ALL THE THINGS is preferred?
-
@loopback0 yes
-
@sockpuppet7 ok then I'm going with "using Rust was never good advice, so doesn't matter how often you update it"
-
@Jaime said in Is updating dependencies frequently still good advice?:
write code on stable platforms like .Net Framework,
@loopback0 said in Is updating dependencies frequently still good advice?:
@sockpuppet7 ok then I'm going with "using Rust was never good advice, so doesn't matter how often you update it"
(╯°□°)╯︵ ┻━┻
-
@sockpuppet7 said in Is updating dependencies frequently still good advice?:
@loopback0 said in Is updating dependencies frequently still good advice?:
@sockpuppet7 ok then I'm going with "using Rust was never good advice, so doesn't matter how often you update it"
(╯°□°)╯︵ ┻━┻
Yes, you effectively trolled yourself.
-
@loopback0 said in Is updating dependencies frequently still good advice?:
Yes, you effectively trolled yourself.
Always a hazard when boomzilla interacts with boomzilla...
-
@sockpuppet7 said in Is updating dependencies frequently still good advice?:
If you don't update the risk is being exposed to a vulnerability that was already fixed.
The risk of updating frequently is getting a supply chain attack before whatever means could mitigate that
That's why we used to have stable distributions with security support. Security vulnerabilities get patched, new features don't get added to avoid bringing in new risks. Well, we still do have stable distributions, but the day when one could reasonably stick with what is available in Debian Stable are, unfortunately, long gone.
Well, we can still stick with that for the support infrastructure, like ssh, and that's a good option.
And practice defence in depth. We have devcontainers and vagrant for sandboxing development environments, and containers for limiting persistence of backdoors in servers.
-
@loopback0 said in Is updating dependencies frequently still good advice?:
@sockpuppet7 said in Is updating dependencies frequently still good advice?:
@loopback0 said in Is updating dependencies frequently still good advice?:
@sockpuppet7 ok then I'm going with "using Rust was never good advice, so doesn't matter how often you update it"
(╯°□°)╯︵ ┻━┻
Yes, you effectively trolled yourself.
I'm just kidding, you said a valid point, in a trolly way, but using a better vetted supply chain is the summary of all responses here
I guess if people that have to use something like npm the answer we got was
@dkf said in Is updating dependencies frequently still good advice?:
We're Doomed!
And I have no better advice for it
-
@cvi Vetting dependencies?
-
@Zenith said in Is updating dependencies frequently still good advice?:
@cvi Vetting dependencies?
People vetted the dependencies... and then had trouble parachuted in by system integrators who used a software artifact that turned out to be significantly different from what you would have expected from a casual glance at the repository. The major egg-on-face part of this must surely go to the people who altered the build of sshd to include a package that wasn't being properly vetted. You know, the people at Red Hat, Debian, etc.
-
@Zenith said in Is updating dependencies frequently still good advice?:
@cvi Vetting dependencies?
I've worked at two places that actually did. One of them did it fo reals, and the other one was "Did you vet this lib you want to use!?" checkbox for getting it imported into the local maven/node mirror. And I'm willing to bet that not a single library in the node side was ever vetted there. The maven ones, I know at least one was, since I did it.
At the other place, there as a proper process to vet things, and it was pretty thorough. You also needed to show that what you wanted was worth the money spent on the vetting. Most libraries are not.
Two places in decades of work, one of which was the nudge-nudge-wink-wink type of vetting.
-
@Carnage said in Is updating dependencies frequently still good advice?:
Most libraries are not.
Acutely aware of that. I bought a datagrid control library with source that really looked like what I needed. Turns out it doesn't support the Visual Studio designer. At all. Forget why, how the fuck do you develop a WinForms control like that?
-
@Jaime said in Is updating dependencies frequently still good advice?:
stable platforms like .Net Framework, which has been about very stable and well supported for 20 years.
It was just recently that Microsoft fucked this up. .Net Framework 4.8, then .Net Core, now .Net 8... - not fully compatible with each other.
And of course, with the more "modern" versions, you have to import tons of dependencies from github. While formerly you found most stuff in the framework, or well curated (ähm... keep dreaming) packages like Windows SDKs.
-
@BernieTheBernie said in Is updating dependencies frequently still good advice?:
It was just recently that Microsoft fucked this up. .Net Framework 4.8, then .Net Core, now .Net 8... - not fully compatible with each other.
Not really.
They have two parallel paths going:
- For those that want few surprises and few regression bugs, choose the more stable .Net Framework 4.8. It will continue to look like 2015, but that's what you asked for by selecting Framework over Core. Security support will continue and new version will continue to be largely backwards compatible.
- For those the want to move faster, choose .Net Core. You'll get features faster at the expense of backwards compatibility.
Of course .Net Core 8 (which is marketed as .Net 8, but is most definitely Core), is not fully compatible with any of the Framework versions. That's what it does.
For example, .Net 8 introduces a new clock abstraction: TimeProvider. In the spirit of moving fast, Microsoft is updating their classes to the new abstraction. This should provide an easier to understand and more consistent API at the expense of making some applications change a few lines.
This is only one example, there are hundreds. Microsoft did a big house cleaning in version 5, and they still haven't gotten around to bringing back some of the components that they decided to "put off until later". Microsoft.AspNetCore.HttpOverrides is one of them. It's currently marked as Deprecated on NuGet and isn't getting support, but they haven't written a replacement yet. Anyone using the older one has to either put up with an unsupported package, or switch to an alternative.
None of this is inherently bad. Anyone that chooses .Net Core, and has a security or architecture department that is on the ball, is going to have to budget time for updating frameworks, packages, code, and tooling. That may make it a poor choice for someone in a highly regulated industry who's team is composed of mostly contractors, or who can't get the budget for development time that doesn't produce business-facing results.
-
@Carnage said in Is updating dependencies frequently still good advice?:
wo places in decades of work
I'm betting one of them was Ericsson
-
@Jaime said in Is updating dependencies frequently still good advice?:
a security or architecture department that is on the ball
-
@dkf You aren't wrong. What I am seeing in the corporate world is people seeing .Net Framework vs. .Net Core as old vs. new rather than conservative vs. ever-changing. More and more teams are talking their bosses into letting them develop with .Net Core, assuming that a development platform from Microsoft will come with ten years of patches - because they always have before. The fact that Microsoft explicitly says you only get three years on even versions and 18 months on odd versions doesn't seem to dissuade them.
Half the time, these teams start on an odd numbered version and about a year into the effort, their framework is out of support. Most of them don't even bother to notice, due to the lack of the aforementioned architecture teams and security having too many other irons in the fire. So they just carry on and don't bother updating any of their dependencies, or they go in with a good intention of keeping up to date, only to learn that their entire application infrastructure is not only no longer the new-hotness (minimal APIs anyone?), but isn't supported any more. So, they blame Microsoft and just keep shipping the out-of-date software.
-
@Jaime said in Is updating dependencies frequently still good advice?:
@dkf You aren't wrong. What I am seeing in the corporate world is people seeing .Net Framework vs. .Net Core as old vs. new rather than conservative vs. ever-changing. More and more teams are talking their bosses into letting them develop with .Net Core, assuming that a development platform from Microsoft will come with ten years of patches - because they always have before. The fact that Microsoft explicitly says you only get three years on even versions and 18 months on odd versions doesn't seem to dissuade them.
Half the time, these teams start on an odd numbered version and about a year into the effort, their framework is out of support. Most of them don't even bother to notice, due to the lack of the aforementioned architecture teams and security having too many other irons in the fire. So they just carry on and don't bother updating any of their dependencies, or they go in with a good intention of keeping up to date, only to learn that their entire application infrastructure is not only no longer the new-hotness (minimal APIs anyone?), but isn't supported any more. So, they blame Microsoft and just keep shipping the out-of-date software.
On the other hand, .NET Core has three big advantages over .NET Framework in large corporate environments:
- The base implementation is cross-platform, so if you're not doing desktop work that needs to opt into a specific operating system, your code will be more portable between different server (read as: cloud) environments. And if you are doing desktop work that needs a Windows specific API, as of .NET
Core5 you have an easy way to opt into that by adding 8 characters to your project's target framework reference (-windows) - Because .NET Core was designed to be divorced from Windows, it comes with support for building a Single File Publish application (N.B. this is specific to all up applications, and if you're building class libraries to be plugins to someone else's application you're not going to be able to benefit from this). So you can just ship the build output and it will run anywhere without needing a specific framework/SDK installed in addition to your tooling.
- If you are using the Single File Publish approach as opposed to the Framework Dependent deploy (which is the recommended way, so most greenfield projects should be doing this), then you have the ability to deploy framework (SDK) updates independent of your IT team finally getting around to deploy the new version of the .NET Framework and your updates won't impact any other application on the machine that might be using a similar version of .NET.
a. Of course, this is also the drawback of doing framework independent deploys with .NET -- you're now responsible for installing and updating SDK/framework updates so that your project picks up those security updates.
- The base implementation is cross-platform, so if you're not doing desktop work that needs to opt into a specific operating system, your code will be more portable between different server (read as: cloud) environments. And if you are doing desktop work that needs a Windows specific API, as of .NET
-
@izzion said in Is updating dependencies frequently still good advice?:
The base implementation is cross-platform, so if you're not doing desktop work that needs to opt into a specific operating system, your code will be more portable between different server
... snip ...
Because .NET Core was designed to be divorced from Windows
This seems to be the well trodden "advantage". Most of us simply don't care. Windows costs more than Linux, but Windows plus support staff is about the same as Linux plus support staff for any solution less than web-scale. Most of us don't do web-scale things.
-
@izzion Also, installing .Net stuff has been just a file copy for like twenty five years now. Anyone that needs technology to help them with this is pretty helpless.
.Net Core added more complication by locking in use files more vigorously then .Net Framework did, so some of the things that have been introduced solve some of the new problems that were created.
Either way, having an image with the right framework, a container with the right framework, or a push install of the right framework are all really easy things for a competent team to pull off.
-
@sockpuppet7 said in Is updating dependencies frequently still good advice?:
I'm just kidding, you said a valid point, in a trolly way
Only because you gave a trolly response to a genuine question.
In an Enterprise world updating dependencies frequently is a different thing because updates are generally only pulling security fixes and not random "feature" updates that may or may not completely break everything. So it's very good advice.
Otherwise it might not be if frequent updates pull in significant functional changes. Better vetting of supply chain doesn't necessarily fix that.
-
@loopback0 but if you happen to get some node stuff to maintain on some big corp, would you still update frequently?
-
@sockpuppet7 The real complications come from the basic fact that upstream developers don't have infinite effort available to support backporting every security fix to every release version that anyone has ever deployed anywhere. Enterprises might want that, but it is expensive and time consuming to do, so it really isn't happening unless someone pays a lot to secure it as an actual job for a (likely mid-career) developer.
The result of that is that some security fixes are always going to end up requiring you to do a larger feature update. Maybe they need a larger rework to fix an internal architectural flaw, or maybe an insecure-by-design feature is removed and downstream has to do a larger workaround. These sorts of things happen.
We can try to avoid the worst offenders, especially those that we predict will have an unstable API, but predictions are never entirely accurate.
-
@Jaime said in Is updating dependencies frequently still good advice?:
they decided to "put off until later". Microsoft.AspNetCore.HttpOverrides is one of them.
All of
Asp.Netshould be considered near-obsolete.
Just read Microsoft's documentation and tutorials on that topic: they clearly tell you thatAsp.Netis for those who have to maintainlegacy applications.
Everything new and shiny should use rest apis and razor or blazor, they say...
-
@sockpuppet7 said in Is updating dependencies frequently still good advice?:
@loopback0 but if you happen to get some node stuff to maintain on some big corp, would you still update frequently?
Update frequently for the sake of updating? No.
I'd update as frequently as necessary to get security fixes based on how severe the issues are and how much effort is required to handle the other "features" that come along with it, or to get new "features" that are required.
I don't think stuff like npm is particularly suited for where you need software that's Enterprise/LTS and has a security-fixes-only option.
-
@Jaime said in Is updating dependencies frequently still good advice?:
@dkf You aren't wrong. What I am seeing in the corporate world is people seeing .Net Framework vs. .Net Core as old vs. new rather than conservative vs. ever-changing. [...] So, they blame Microsoft and just keep shipping the out-of-date software.
I wonder why anyone would think that?
.NET Core is the Future of .NET - .NET Blog
We introduced .NET Core 1.0 on November 2014. The goal with .NET Core was to take the learning from our experience building, shipping and servicing .NET Framework over the previous 12 years and build a better product. Some examples of these improvements are side-by-side installations (you can...
-
@LaoC said in Is updating dependencies frequently still good advice?:
I wonder why anyone would think that?
Never trust marketing. They also told us that Silverlight was the future. Everyone who believed them was left an abandoned platform just a few years later.
-
@Jaime said in Is updating dependencies frequently still good advice?:
@LaoC said in Is updating dependencies frequently still good advice?:
I wonder why anyone would think that?
Never trust marketing. They also told us that Silverlight was the future. Everyone who believed them was left an abandoned platform just a few years later.
You'd be preaching to the choir if you'd said "never trust Microsoft". Once you do decide to trust Microsoft enough to use any of their frameworks though, blaming Microsoft sounds like the logical thing to do when it turns out what Microsoft told you (in resources rather on the technical side of what corporate will base its decisions on) was bullshit.
-
@loopback0 said in Is updating dependencies frequently still good advice?:
Update frequently for the sake of updating? No.
I'm the guy at my company that determines what is required to comply with regulation and to make our customers comfortable sharing with us what they share with us.
For both, the absolute minimum that they want to hear is that we scan for vulnerable components every 30 days, address critical flaws rapidly, and get off of any unsupported component within 90 days. Of course if something turns out to be a lot of work we document the exception and create a project to track it. No one is going to sue or jail us for exceeding 90 days if something is a lot of work, but they don't want to hear that we haven't even assessed it yet at 90 days.
My industry is more heavily regulated than most, but a lot of corporate development is performed under these conditions.
I'd much rather have Microsoft waggle their finger at me for using .Net Framework than board the update train that is .Net Core. We do it some now and will do more in the future, mainly because getting supported components for .Net Framework is getting harder and harder. But I'm neither excited nor pleased about the changes.
-
@Jaime said in Is updating dependencies frequently still good advice?:
Silverlight
You'd better stayed with FlashPlayer.
-
@LaoC said in Is updating dependencies frequently still good advice?:
what Microsoft told you
Look here: https://learn.microsoft.com/en-us/lifecycle/products/microsoft-net-framework
If I had an app that was on the latest build of .Net Framework 3.5 and I was concerned about the effort to move to 4, Microsoft is giving me nearly five years from today (January 2029) of support so I can plan my move.
If I build a brand new product on .Net 8, they give me support until November 2026.
-
@BernieTheBernie said in Is updating dependencies frequently still good advice?:
@Jaime said in Is updating dependencies frequently still good advice?:
they decided to "put off until later". Microsoft.AspNetCore.HttpOverrides is one of them.
All of
Asp.Netshould be considered near-obsolete.
Just read Microsoft's documentation and tutorials on that topic: they clearly tell you thatAsp.Netis for those who have to maintainlegacy applications.
Everything new and shiny should use rest apis and razor or blazor, they say...Wait, I thought that the framework for providing any HTTP interface, including REST API, is still called Asp.Net. At least it requires aspnet (and not just plain dotnet core) runtime/sdk.
-
@Bulb said in Is updating dependencies frequently still good advice?:
is still called Asp.Net
Yes, you are correct. However, it's usually referred to as AspNetCore to differentiate it in technical contexts. And lo and behold, the reference I was referring to was a Microsoft.AspNetCore component and it part of modern rest apis, razor, and the like.
-
@Jaime … i.e. Microsoft sucks at naming.
-
@Bulb said in Is updating dependencies frequently still good advice?:
@Jaime … i.e. Microsoft sucks at naming.
The naming team wasn't allowed to get as creative as they used to be on Windows releases so they needed a new area of work. I hear the cache invalidation team has meanwhile been put to work on .НЕТ, too.
-
@LaoC what about the Off By One team?
-
@topspin said in Is updating dependencies frequently still good advice?:
@LaoC what about the Off By One team?
There are only three teams. Never heard of that one.
-
@LaoC said in Is updating dependencies frequently still good advice?:
@topspin said in Is updating dependencies frequently still good advice?:
@LaoC what about the Off By One team?
There are only three teams. Never heard of that one.
Well there is the Windows 10 team, and windows 10 is the Last Version of Windows. So I assume the Windows 11 team is really just off by one.
