Cc'ing Ralf for information, since he's been acting as maintainer for D-Bus-on-Windows.

Ralf: I don't think D-Bus on Windows is suitable for use as a security boundary or has security support (e.g. Bug #35311), and there is no system bus on Windows (which is the part that's security-sensitive on Unix), so I'm not proposing to add you to the security contact list at this stage.

Agreed on all points.

This sounds reasonable, although in practice I suspect we'll end up escalating issues very quickly to existing lists like distros@vs.openwall.org.

*** Bug 68011 has been marked as a duplicate of this bug. ***

(In reply to comment #1)
> Cc'ing Ralf for information, since he's been acting as maintainer for
> D-Bus-on-Windows.
> 
> Ralf: I don't think D-Bus on Windows is suitable for use as a security
> boundary or has security support (e.g. Bug #35311), and there is no system
> bus on Windows (which is the part that's security-sensitive on Unix), so I'm
> not proposing to add you to the security contact list at this stage.

I'ts okay for now. If there are real world requests or uses case for that, we will see.

(In reply to comment #4)
> *** Bug 68011 has been marked as a duplicate of this bug. ***

I opened this bug, because this bugs is open over a month and noone from the fdo admin team seems to feel responsible to handle fdo infrastructure change requests. How could this project be maintained well, if the basic settings could not be changed ? 

I never got such experiences from the kde admin team, they were very responsive all the time.

Ping?

If there are any problems with my plan from the sysadmin side, please say. It seems the D-Bus maintainers all agree with me.

(In reply to comment #0)
>   Create a Bugzilla group for the
>   security contacts (like the existing Telepathy one)

This seems to exist now. The rest of my requested changes would still be useful.

(In reply to comment #0)
> Here is what I'd ideally like: please implement or discuss. See also Bug
> #57752, Bug #58996, Bug #61434, Bug #63401 which are similar.

Hello sysadmins, here is your bi-monthly reminder that any or all of the changes in Comment #0 would be greatly appreciated.

(In reply to comment #0)
> * Create a mailing list dbus-security@lists.freedesktop.org with
>   restricted membership, unrestricted posting and restricted
>   archives (or even no archives).

Done. Archives are disabled.

>   Subscribe those of the D-Bus maintainers with an interest in its security,
>   including at least:
> 
>   * Simon McVittie (core, dbus-glib, dbus-python; Collabora, Debian)
>   * Colin Walters (core, dbus-glib; Red Hat, GNOME)
>   * Thiago Macieira (core, QtDBus; Intel, KDE)

Subscribed these three for now.

> * Create either a mailing list dbus-bugs@lists.freedesktop.org or
>   an invalid pseudo-account that does not actually receive email
>   (like the @gnome.bugs addresses used on bugzilla.gnome.org),
>   and make it the QA contact for all dbus components except security.

dbus@maint.invalid is this contact.

>   Maintainers will be encouraged to "watch" this address on Bugzilla

Maintainers, please watch that address.

OK, done :-)

> * For the components without a single obvious owner (core, GLib),
>   set the default assignee to the dbus-bugs list too. java, perl,
>   python can keep their current default assignees.

Done

> * Delete the dbus/doc Bugzilla component. It was meant to mean a
>   Telepathy-like introspection-based format for documentation, but that
>   project didn't go anywhere, and everyone thinks it means the
>   documentation and specification in dbus.git, which can just be dbus/core.

Done, all bugs moved to dbus/core

> * Delete the dbus/Qt Bugzilla component. QtDBus bugs have been tracked on
>   the Qt bug tracker for about 7 years.

Not deleted, but closed for new bugs

> * Create a 'security' Bugzilla component for embargoed
>   security bugs

No real need to do this, dbus@maint.invalid is enough. Bugmail for security bugs will go to watchers of dbus@maint.invalid if and only if the watcher is allowed to see the bug.