I've emailed @rtbo personally (they seem somewhat active on GitHub at least), let's see if they respond in the next two weeks. If not, we should go ahead and merge the advisory (please help remind me).

Hi,
I've honestly little time to allocate to the maintenance of rust-xcb, but I don't want it to die unmaintained either!
I can definitely share a write access to the repo.

Should be closed by rust-x-bindings/rust-xcb#283

One thing to mention is that this isn't a memory safety violation but rather an I/O safety violation. I think that may warrant tagging it with a dedicated category? It also wasn't clear to me from reading the discussions linked from that RFC whether I/O safety violations can cause undefined behavior, and thus whether this qualifies as "unsound" at all.

That's a good point, this probably doesn't qualify as unsound.

Sorry for not having a quicker response. I guess I can give my opinions (to be taken with a grain of salt).

As long as someone can respond within a reasonable amount of time to major xcb issues, I have no problem calling it maintained. It's clear to me that has been done here.

Maybe I am missing something, but the neither the Reference nor the Nomicon nor the FLS expressly state that calling foreign code in a way which causes undefined behavior in the foreign code (for whatever its definition of UB may be) to be undefined behavior in Rust. UB should cross FFI boundaries, because the opposite is absurd. That was my defense for calling this unsound: the POSIX standard says closing or using a file descriptor after close is UB, safe functions provided by xcb enable that to occur.

I/O safety is in this weird place. Its main PR landed 3 years ago, but no one ever defined what constitutes UB when using a RawFd. The functions in the standard library which takes a RawFd and return some other file-like type, BorrowedFd::borrow_raw and FromRawFd::from_raw_fd, are marked unsafe to enforce I/O safety. But with I/O safety not being "real" (in the sense that it also is not defined in any of the aforementioned places) and RawFds usage being almost completely exclusive to FFI (where misuse should be an unsoundness anyways), I/O safety never got a category. It doesn't even have a keyword somehow.

I believe the nix crate to be in the wrong, and the lack of a rigorous I/O safety definition contributing to it sticking around. The equivalent function in rustix, rustix::io::close, is marked unsafe. More broadly, I believe most "safe" functions which allow the user to provide a RawFd and do syscalls with it are unlikely to be sound. As example,

fn main() {
    let file_fd = File::create_new("hello_world.txt").unwrap();
    let raw_fd = file_fd.as_raw_fd();
    drop(file_fd);
    // This is sound, a RawFd is just a number
    println!("raw_fd: {raw_fd:?}");
    // I believe this should be undefined if it does something undefined in C.
    unsafe { libc::some_syscall(raw_fd) };
}

Finally, I've made changes to the advisory now that a fixed version is out. I have still left it with no keyword and informational = unsound since there seems to be no consensus on a more apt label.

Thanks!