Hi, My few smallcoins, responding to each of the proposed outcomes (even if they were intended to be mutually-exclusive...) are:
A) Educating contributors that retaining control of their signing keys is important seems valuable -- it seems OK to provide a few illustrative examples of situations where relinquishing or losing control of keys could be problematic, and the reasons why. B) To follow the security vulnerability disclosure model: it seems OK to indicate that a given vendor is problematic for a specific, communicable reason -- and beneficial to contact them first to indicate the concern and ask whether they're aware of a problem and to check whether they're willing-and/or-able to mitigate that. C) If the risk is vendor capture of key material, then a similar concern should probably be about vendors who provide functionality that could lock contributors into their ecosystem for any reason. In other words: if the concern is about behavioural coercion or that an entity may behave in future in ways that a key author might not intend, then I'd argue that it's not only the author's key material, but also the output communication styles and abilities allowed by the vendor that should be questioned. So: it's fine for a vendor to do something to help Debian, but it should be in a way that any other vendor can implement, based on a public, ideally DFSG-compliant, specification. Regards, James
