I really wish I had paid more attention to this thread and others warning about the changes to X before attempting to upgrade to ascii. My preferred way of working is out of a console running byobu and GNU screen and starting X only when needed. This no longer works as both screen and X use virtual terminals and instead of X starting on F7-F9, it is on F1; so that the console terminal is unusable. So after hours of frustration yesterday trying to get ascii working, I gave up and today reinstalled jessie only to find that xserver-xorg-legacy had been removed from the available packages; so I had the same problem. I had been using Devuan jessie for months and was very happy with it. (I should remember not to try to fix things that are not broke.) Fortunately, I had an old Debian wheezy installation which I'm now using.

While any suggestions would be appreciated, I'm mostly just venting frustration. I know that my setup is atypical and console users won't influence the direction of X. Still....

09.06.2018, 18:52, "Joel Roth" <joelz@???>:
> Colleagues!
>
> Earlier in this thread, we learned that installing xserver-xorg-legacy
> allows you to run X the old way, as a setuid script.
>
> The default upgrade path from jessie -- in which X11 was
> setuid-only -- migrates to a new xserver-xorg in which the
> setuid mechanism is replaced. In order to run X with user
> permissions in the dist-upgrade'd environment one needs to
> pull in a stack of dependencies including dbus, polkit,
> libpam-elogind, and elogind.
>
> I think it may be a bug that in the case of my upgrade
> experience, neither xserver-xorg-legacy (a wrapper that
> enables setuid X) nor this pam stack were installed, so
> startx failed for me. Perhaps the experience is different
> with a display manager installed.
>
> I have and use dbus apps on my system, However, as far as
> I'm aware, none of these programs has root privileges.
>
> As the pam/dbus/elogind/polkit mechanism is capable of
> handing out root authority, and as all software has bugs, I
> think we _can_ anticipate that bugs that create security holes
> will be uncovered in this stack. How much scrutiny did the
> developers devote? Did anyone ever consider security at
> through the whole stack? Probably the developers of each
> component do consider security in their own code.
>
> openssl had a big hole for years, and before that debian's random
> number generator was broken. Showstopping
> holes, but the show goes on...
>
> Will someone who scrutinizes closer have a back door,
> is that likely be true for the foreseeable future?
>
> In a way, running others' code is like driving: putting
> oneself in the hands of strangers you've never met and
> might not trust for minute in person.
>
> I read about the art of "fuzzing" programs with various
> combinations of random inputs, to discover bugs such as
> buffer overflows. This technique has been used to find bugs
> and improve security in many languages. It was also used to
> find hidden instructions and other attributes of
> microprocessors.
>
> https://github.com/xoreaxeaxeax/sandsifter/blob/master/references/domas_breaking_the_x86_isa_wp.pdf
>
> I see fuzzing tools for dbus also available.
>
> I think it's an interesting security question, since the default
> state of a distribution is so influential.
>
> That PAM is finely grained, I get, so on the surface, it
> looks superior to the big club of root permissions.
>
> I'd be interested to links to any discussions of these
> topics. I see the CVEs are published, in this example,
> smb4k is being careless in arguments it passes to dbus,
> leading to an exploit.
>
> https://nvd.nist.gov/vuln/detail/CVE-2017-8849
>
> cheers
>
> --
> Joel Roth
>
> _______________________________________________
> Dng mailing list
> Dng@???
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng