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" <jo...@pobox.com>: > 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@lists.dyne.org > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
