Field value exclusion and / or regex pattern

[pinkforest]

e.g. #671 on potential new field target

We could say everything windows

target = ["*windows*"]

Or we could say everything except windows with a !:

target = [!"*windows*"]

All x86_64 targets

target = ["x86_64*"]

Or regex:

target = ["^x86_64.+"]

etc.

[tarcieri]

We could say everything windows

target = ["windows"]

This is possible today with affected.os = ["windows"]

Or we could say everything except windows with a !:

target = [!"windows"]

What's an example of something that would affect everything but Windows? I don't see the use case here.

All x86_64 targets

target = ["x86_64*"]

This is possible today with affected.arch = ["x86_64"]

[pinkforest]

This is possible today with affected.os = ["windows"]
This is possible today with affected.arch = ["x86_64"]

Problem is these are now separate non-linked fields and the arch should be paired to os since e.g. macos can run on arm/aarch64 and x84_64 + there are also libc differences between e.g. musl and glibc

If I can just say in one field that all windows regardless os arch - without having to specify arch are vulnerable I could do it simply this where as with affected.os I would have to specify every arch windows runs on - a list that tends to change e.g. it runs on arm now (Surface Pro X I think?)

Ergonomics wise people are also used to these target triplets when working with Rust

What's an example of something that would affect everything but Windows? I don't see the use case here.

The time crate that was in #671 it had to list every other platform out there other than windows - makes a big list

This list also is prone to change in the future:
In https://github.com/rustsec/advisory-db/blob/main/crates/time/RUSTSEC-2020-0071.md

[affected]
# any Unix-like OS
os = [
    "linux",
    "redox",
    "solaris",
    "android",
    "ios",
    "macos",
    "netbsd",
    "openbsd",
    "freebsd",
]

[pinkforest]

Also crossbeam-utils - I wonder how can we support it better:

https://github.com/rustsec/advisory-db/blob/main/crates/crossbeam-utils/RUSTSEC-2022-0041.md

[tarcieri]

The time crate that was in #671 it had to list every other platform out there other than windows - makes a big list

They were trying to list cfg(unix)-like platforms, not !windows. There are also non-Windows, non-Unix-like OSes, so !windows would not be accurate.

[pinkforest]

Well then you just say !windows and also !exclude any other non-unix instead of listing every platform out there

Would make much shorter list yes ?

If we were to think that it will be inaccurate because new os might come along -

Well it is also the case for this list which would be essentially incomplete

[tarcieri]

I think this makes a better case for a unix meta-OS which behaves like cfg(unix), rather than !windows.

Edit: more specifically these are target_family which is one of: windows, unix, or wasm

[tarcieri]

Ergonics wise people are also used to these target triplets when working with Rust

In Rust code itself, target triples are decomposed into target_arch, target_os, and target_env, similar to affected.arch and affected.os.

They're different representations of the same information.

[pinkforest]

https://doc.rust-lang.org/reference/conditional-compilation.html

Yeah target_family could make sense

How about libc differences ?

EDIT: target_env ?

[tarcieri]

That's target_env. We could potentially add affected.env.

[pinkforest]

So how about excluding target_family are we still okay ! or do we keep coming up with big lists and maintain all advisories when there is a new OS around ?

[pinkforest]

Also how would we support best something like this:
https://github.com/rustsec/advisory-db/blob/main/crates/crossbeam-utils/RUSTSEC-2022-0041.md

[tarcieri]

I'd prefer not to define a custom meta-language. If we do need some kind of selectors, I'd prefer to model them off of the ones used in e.g. Cargo.toml's [target].

I'm still not convinced we do need selectors (yet), however.

I would be OK with adding something like affected.family/affected.target_family as well.

[pinkforest]

Superceded by #699