RFC: deprecating crypto usage in secret-service

[Daiki Ueno]

Thank you for the comments.

"Thomas Kluyver" <thomas at kluyver.me.uk> writes:

> It's not clear to me that using file descriptors fulfils the same goal
> as the encryption mechanism. The secret service spec [1] suggests that
> the goal is for swappable memory to contain encrypted (rather than
> plaintext) secrets. Passing the secret over a separate channel
> wouldn't seem to do that - though I guess there would be one fewer
> copy of the data, as the bus daemon doesn't see it.

I think both endpoints (gnome-keyring and libsecret, for example)
already have protection against that using mlock, while as you say, with
the current "plain" mechanism, the D-Bus daemon can leak the data into
the swap because it has no knowledge about which part of the traffic
should be considered as confidential.

> Approaching it from another angle, what threat would this protect
> against which could otherwise steal data from D-Bus over unix sockets?
> I think it would have to be something which can listen to another
> connection but not connect itself, but I don't know of a scenario
> where that's possible.

To my understanding, once the data has been written to a file
descriptor, it is copied into the kernel space, and cannot leak into
swappable memory until it is read by the user space program.  As D-Bus
already provides a way to transfer FD between the peers, we don't need
to care about listen or connect.

> Passing file descriptors is only possible over Unix sockets, as far as
> I know, so it wouldn't be usable on Windows, though I don't know how
> big a concern that is.

I guess we probably should check how Unix sockets are implemented in
WSL at least.

Regards,
-- 
Daiki Ueno