RFC: deprecating crypto usage in secret-service
chanslor at icloud.com
Wed Oct 7 20:55:13 UTC 2020
I (nobody) posit that backward compatibility takes a back seat to security, especially for low level systems; that xdg is most useful when all its components achieve widespread adoption; that nobody has ever foreseen the eventual problem with a vulnerability where "you're already screwed anyway;" and that the sooner a backwards-incompatible change is implemented, the less painful the transition will be.
But I'm no expert on dbus, or the system's guts in general, for that matter. Just a concerned citizen and user of xdg specs.
> On Sep 1, 2020, at 5:23 AM, Simon McVittie <smcv at collabora.com> wrote:
>> On Sun, 30 Aug 2020 at 22:34:24 -0600, Thayne wrote:
>> How about having some way to signal to D-Bus that a message is
>> sensitive so should be stored in non-swappable memory?
> Sorry, this is unlikely to be implementable. dbus-daemon (or dbus-broker
> or whatever other message bus implementation is in use) cannot know
> what flags a message has until it has already received at least part of
> the message, at which point it's very likely to be too late to put that
> message in non-swappable memory.
> The message bus is already relatively complex, and I would prefer not to
> add additional platform-specific complexity by trying to prevent certain
> messages from being swapped out.
> The design of D-Bus is such that clients can cause the message bus to
> allocate large amounts of memory, and this cannot be prevented without
> dropping messages on the floor, which is not something that clients
> can generally detect or recover from. (Yes, this is a design flaw;
> unfortunately, solving this would not be a backwards-compatible change,
> and D-Bus' single most important feature is interoperability). As a
> result, asking for message bus features that involve much-more-limited
> resources like locked memory pages is unlikely to succeed.
> xdg mailing list
> xdg at lists.freedesktop.org
More information about the xdg