HEADS-UP: Upcoming retirement of long-term-unused packages for Rust crates

[Fabio Valentini]

Hi all,

I've been collecting data about the dependency graph of Rust packages
in Fedora for over a year now, and I would like to start the process
of removing some accumulated cruft. In particular, I've been keeping
track of which packages for *library* packages (i.e. they ship only
source code but no binaries) have been leaf packages.

List of Rust library-only packages, which no other package in Fedora
has depended on, for over a year (365 days+):

- rust-compiletest_rs
- rust-constant_time_eq
- rust-conv
- rust-counted-array
- rust-dbus-tokio
- rust-defmac
- rust-dialoguer
- rust-enumset
- rust-failure-tools
- rust-fake-simd
- rust-fbthrift_codegen_includer_proc_macro
- rust-fdlimit
- rust-hamcrest2
- rust-html2pango
- rust-imgref
- rust-ioctl-rs
- rust-lipsum
- rust-listenfd
- rust-loggerv
- rust-lzw
- rust-macro-attr
- rust-mdl
- rust-mktemp
- rust-mnt
- rust-newtype_derive
- rust-odds
- rust-osstrtools
- rust-parse_cfg
- rust-permutate
- rust-piper
- rust-podio
- rust-proc-quote-impl
- rust-process_path
- rust-progress-streams
- rust-protoc-rust
- rust-quickersort
- rust-rand_jitter
- rust-rand_os
- rust-read_input
- rust-relay
- rust-rustc_tools_util
- rust-rustdoc-stripper
- rust-rustfilt
- rust-safe-transmute
- rust-scoped-tls-hkt
- rust-serde-pickle
- rust-serial-core
- rust-sluice
- rust-smallstr
- rust-spinning_top
- rust-spmc
- rust-ssh-key-dir
- rust-stb_truetype
- rust-string_cache_shared
- rust-strings
- rust-sudo_plugin
- rust-sxd-document
- rust-synom
- rust-sysctl
- rust-tabwriter
- rust-take
- rust-timerfd
- rust-tower-test
- rust-tower-util
- rust-ucd-util
- rust-unic-ucd-category
- rust-url_serde
- rust-urlocator
- rust-utf8-ranges
- rust-watchman_client

Some of these packages are dependencies of things that will be worked
on at some point in the future (for example, packaging of GStreamer
plugins that are written in Rust), but others look very much like
accumulated cruft.

If you see a package on this list that you would like to keep for some
reason, please speak up, and I will exclude it from future dependency
graph analysis. Otherwise I will soon start retiring packages that
have been unused for over a year.

The packages that would be in the list above, but which I *know* will
get some use soon, are:

- rust-curve25519-dalek
- rust-gstreamer-audio
- rust-gstreamer-editing-services
- rust-gstreamer-player

I will probably start the cleanup process with packages for crates
that no longer have any dependent crates listed on the crates.io
registry (which is a good indicator that they are indeed obsolete),
and then continue with crates for which the longest amount of time has
passed since the last upstream release (which is "more than 5 years
ago" for some crates ...).

Fabio

[Ian McInerney]

On Tue, Nov 22, 2022 at 4:14 PM Fabio Valentini <decathorpe(a)gmail.com&gt;
wrote:

>  Hi all,
>
>  I've been collecting data about the dependency graph of Rust packages
>  in Fedora for over a year now, and I would like to start the process
>  of removing some accumulated cruft. In particular, I've been keeping
>  track of which packages for *library* packages (i.e. they ship only
>  source code but no binaries) have been leaf packages.
>
>  List of Rust library-only packages, which no other package in Fedora
>  has depended on, for over a year (365 days+):
>
>  - rust-compiletest_rs
>  - rust-constant_time_eq
>  - rust-conv
>  - rust-counted-array
>  - rust-dbus-tokio
>  - rust-defmac
>  - rust-dialoguer
>  
I was just recently thinking of packaging juliaup (
https://github.com/JuliaLang/juliaup), and it has rust-dialoguer as a
dependency, so if you can exclude it for now that would be great.

-Ian


>  - rust-enumset
>  - rust-failure-tools
>  - rust-fake-simd
>  - rust-fbthrift_codegen_includer_proc_macro
>  - rust-fdlimit
>  - rust-hamcrest2
>  - rust-html2pango
>  - rust-imgref
>  - rust-ioctl-rs
>  - rust-lipsum
>  - rust-listenfd
>  - rust-loggerv
>  - rust-lzw
>  - rust-macro-attr
>  - rust-mdl
>  - rust-mktemp
>  - rust-mnt
>  - rust-newtype_derive
>  - rust-odds
>  - rust-osstrtools
>  - rust-parse_cfg
>  - rust-permutate
>  - rust-piper
>  - rust-podio
>  - rust-proc-quote-impl
>  - rust-process_path
>  - rust-progress-streams
>  - rust-protoc-rust
>  - rust-quickersort
>  - rust-rand_jitter
>  - rust-rand_os
>  - rust-read_input
>  - rust-relay
>  - rust-rustc_tools_util
>  - rust-rustdoc-stripper
>  - rust-rustfilt
>  - rust-safe-transmute
>  - rust-scoped-tls-hkt
>  - rust-serde-pickle
>  - rust-serial-core
>  - rust-sluice
>  - rust-smallstr
>  - rust-spinning_top
>  - rust-spmc
>  - rust-ssh-key-dir
>  - rust-stb_truetype
>  - rust-string_cache_shared
>  - rust-strings
>  - rust-sudo_plugin
>  - rust-sxd-document
>  - rust-synom
>  - rust-sysctl
>  - rust-tabwriter
>  - rust-take
>  - rust-timerfd
>  - rust-tower-test
>  - rust-tower-util
>  - rust-ucd-util
>  - rust-unic-ucd-category
>  - rust-url_serde
>  - rust-urlocator
>  - rust-utf8-ranges
>  - rust-watchman_client
>
>  Some of these packages are dependencies of things that will be worked
>  on at some point in the future (for example, packaging of GStreamer
>  plugins that are written in Rust), but others look very much like
>  accumulated cruft.
>
>  If you see a package on this list that you would like to keep for some
>  reason, please speak up, and I will exclude it from future dependency
>  graph analysis. Otherwise I will soon start retiring packages that
>  have been unused for over a year.
>
>  The packages that would be in the list above, but which I *know* will
>  get some use soon, are:
>
>  - rust-curve25519-dalek
>  - rust-gstreamer-audio
>  - rust-gstreamer-editing-services
>  - rust-gstreamer-player
>
>  I will probably start the cleanup process with packages for crates
>  that no longer have any dependent crates listed on the crates.io
>  registry (which is a good indicator that they are indeed obsolete),
>  and then continue with crates for which the longest amount of time has
>  passed since the last upstream release (which is "more than 5 years
>  ago" for some crates ...).
>
>  Fabio
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct:
>  https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
>  https://lists.fedoraproject.org/archives/list/[e-mail]
>  Do not reply to spam, report it:
>  https://pagure.io/fedora-infrastructure/new_issue
>

[Kalev Lember]

Hi Fabio,

On Tue, Nov 22, 2022 at 5:14 PM Fabio Valentini <decathorpe(a)gmail.com&gt;
wrote:

>  - rust-constant_time_eq
>  
Can you leave rust-constant_time_eq out please? 'authenticator' that I'm
packaging depends on it.

-- 
Kalev

[Josh Stone]

On 11/22/22 8:13 AM, Fabio Valentini wrote:
>  List of Rust library-only packages,
>  
>  - rust-rustfilt 
This one does have a binary, a Rust equivalent to binutils' c++filt.

It's OK though -- c++filt knows Rust mangling these days, whereas
rustfilt doesn't know C++, so it wouldn't be much loss to drop it.

[Fabio Valentini]

On Tue, Nov 22, 2022 at 6:49 PM Josh Stone <jistone(a)redhat.com&gt; wrote:
>  On 11/22/22 8:13 AM, Fabio Valentini wrote:
>  > List of Rust library-only packages,
>  >
>  > - rust-rustfilt
>
>  This one does have a binary, a Rust equivalent to binutils' c++filt. 
Thanks for the responses, I've added dialoguer, constant_time_eq to
the list of things we want to keep.
I missed that rustfilt was an application, though it hasn't been
updated in over three years, and if c++filt supports Rust name
mangling now, it's not a big loss.

And ... whether you should - or should not - use cryptographic
libraries that are written in Rust is not my area of expertise, but I
think that should be brought up with the upstream projects that
consider using them, and that's kind of off-topic for this particular
thread ...

Fabio

[Fabio Valentini]

On Tue, Nov 22, 2022 at 11:24 PM Fabio Valentini <decathorpe(a)gmail.com&gt; wrote:
>  On Tue, Nov 22, 2022 at 6:49 PM Josh Stone <jistone(a)redhat.com&gt; wrote:
>  >
>  > On 11/22/22 8:13 AM, Fabio Valentini wrote:
>  > > List of Rust library-only packages,
>  > >
>  > > - rust-rustfilt
>  >
>  > This one does have a binary, a Rust equivalent to binutils' c++filt.
>
>  Thanks for the responses, I've added dialoguer, constant_time_eq to
>  the list of things we want to keep.
>  I missed that rustfilt was an application, though it hasn't been
>  updated in over three years, and if c++filt supports Rust name
>  mangling now, it's not a big loss. 
As previously announced, I have now gone ahead with this plan.
Almost all library-only Rust packages which have been unused leaf
packages in Fedora for more than ~365 days / a year / two release
cycles (full list included below) are retired now.

I looked through all packages individually, and excluded any packages that
- include applications,
- are depended on by Rust packages that are still going through package review,
- were "claimed" in this thread.

If any package was retired that should not have been, please tell me
about it (so I can figure out why I didn't categorize it correctly),
and request package un-retirement with releng ASAP (or at least within
the next 8 weeks - to avoid going through re-review).

Thanks,
Fabio

==========

Skipped packages:

rust-curve25519-dalek (pending review depends on it)
rust-gstreamer-audio (still wanted)
rust-gstreamer-editing-services (still wanted)
rust-gstreamer-player (still wanted)
rust-rand_jitter (0.1 compat package still needed)
rust-rand_os (0.1 compat package still needed)
rust-tower-test (still wanted)
rust-tower-util (still wanted)
rust-partial-io (still wanted)

Retired packages:

rust-ar
rust-average
rust-bigdecimal
rust-blake2
rust-case
rust-common-path
rust-compiletest_rs
rust-conv
rust-counted-array
rust-cstr_core
rust-defmac
rust-epoll
rust-failure-tools
rust-fake-simd
rust-groupable
rust-hamcrest2
rust-html2pango
rust-id-arena
rust-imgref
rust-ioctl-rs
rust-json_value_merge
rust-listenfd
rust-log-panics
rust-mustache
rust-nohash-hasher
rust-podio
rust-pretty
rust-progress-streams
rust-quicli
rust-read_input
rust-rustc_tools_util
rust-serial-core
rust-stb_truetype
rust-sysctl
rust-temporary
rust-timerfd
rust-ucd-util
rust-urlocator
rust-watchman_client

[Simo Sorce]

On Tue, 2022-11-22 at 17:13 +0100, Fabio Valentini wrote:
>  - rust-curve25519-dalek 
Asymmetric cryptography in pure rust should not be used, there is still
no support in the language for constant time operations, which means
there is a fat chance these implementations are susceptible to trivial
timing attacks.

The only caveat is if the "pure rust" implementation actually embeds
assembly optimization for modular arithmetic that are explicitly
addressing constant time computation.

I am not aware of that being the case in any rust libraries yet.

Simo.

-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc

[Josh Stone]

On 11/22/22 11:59 AM, Simo Sorce wrote:
>  On Tue, 2022-11-22 at 17:13 +0100, Fabio Valentini wrote:
> > - rust-curve25519-dalek
>  
>  Asymmetric cryptography in pure rust should not be used, there is still
>  no support in the language for constant time operations, which means
>  there is a fat chance these implementations are susceptible to trivial
>  timing attacks.
>  
>  The only caveat is if the "pure rust" implementation actually embeds
>  assembly optimization for modular arithmetic that are explicitly
>  addressing constant time computation.
>  
>  I am not aware of that being the case in any rust libraries yet. 
FWIW, they do make claims about this:

https://github.com/dalek-cryptography/curve25519-dalek/issues/157
https://github.com/dalek-cryptography/curve25519-dalek/blob/main/README.m...

>  All operations are implemented using constant-time logic (no
>  secret-dependent branches, no secret-dependent memory accesses),
>  unless specifically marked as being variable-time code. We believe
>  that our constant-time logic is lowered to constant-time assembly, at
>  least on x86_64 targets.
>  
>  As an additional guard against possible future compiler
>  optimizations, the subtle crate places an optimization barrier before
>  every conditional move or assignment. More details can be found in
>  the documentation for the subtle crate. 
We package rust-subtle as well, so that's probably a useful trail to any
crates that are claiming pure-rust constant-time cryptography.

Anyway, I'll leave it to cryptography experts to verify these claims.