libera/#devuan/ Monday, 2018-10-29

stevelittAlright, let me try ceres again...00:52
gnarfacestevelitt: stuff is gonna be different enough that old configs in your home directory can cause userspace damage that may look just like a broken system until you purge the old configs (VLC is a frequent offender in this regard, but hardly the only one)01:04
gnarfacein general it might be safer to upgrade from a headless, minimal ascii install than something you've already worked to configure the user environment for01:05
gnarfacethe version of Xorg in there isn't even compatible with the same range of NVidia drivers, i don't think01:05
saptech when dragging a url to folder im getting error 'Failed to create a link for the URL'01:35
saptechany idea what's going on with it?01:36
XenguyMaybe it's an existing bug, or one that still needs to be reported?01:38
saptechmy first time noticing this happening01:40
furrymcgeehow can devuan used as freeipa-server the package is missing in the repository10:12
negevopenssl 1.1.1 seems to cause issues with some stuff10:39
negevi can't find anywhere on the system with either 1.1.0f or 1.1.110:40
negevit's not referenced in the openssl.cnf or in ldd output for phantomjs10:40
* man_in_shack flails10:45
man_in_shackgot me my bluray discs playing over iscsi10:45
man_in_shacknot dvds because fuck css encryption shit10:45
rrqngev: how about
negevrrq: i saw that but i don't really understand it10:47
rrqsuggests that you set OPENSSL_CONF to pinpoint your openssl.cnf10:48
negevbut i only have one openssl.cnf anyway10:49
negevhow would that help?10:49
gnarfaceman_in_shack: the libdvdcss2 from works for general purpose10:50
negevah, using the openssl.cnf from manually compiled openssl 1.1.1 seems to work10:50
man_in_shackgnarface: yah but tgt seems to have trouble reading the encrypted packets and passing that over to libdvdcss :)10:51
gnarfaceyou sure you didn't just forget libdvdnav4?10:51
man_in_shacklet me doublecheck10:52
man_in_shackyah it's installed10:52
man_in_shackdoes look like it's tgt's fault10:53
man_in_shackso what i doing is running a remote X server with vlc in10:54
man_in_shackcos the 10 year old core2 duo can handle that10:54
plasma41Good Morning17:01
_abc_Hi. Is the patched xorg alredy in the devuan updates package stream for ascii? I find it confusing that I have to ask about this knowing "upstream" is always official debian...17:07
plasma41What patch is this?17:08
_abc_#2: I lol'd at the thought Poettering may end up wearing a suit to work. IBM bought Red Hat. I am curious how these two cultures will clash. They are like fire and water.17:08
_abc_plasma41: the security patch for the bug which permits overwriting any system file by a user starting xorg with crafted log file list.17:08
plasma41I hadn't heard about that bug17:09
_abc_ well now you have17:09
_abc_devuan ascii has xorg 1.19.2 and is vulnerable.17:11
_abc_ interview with Poettering, in German. In the 1st 2 minutes he says systemd is hopefully better since "we tried to get the best parts of the Apple OS init system, and from Solaris's sms". Tried. And still trying. Right.17:16
_abc_I find it super amusing he's now an IBM employee.17:16
nemoI thought that bug was embargoed to allow distros to fix17:16
nemosurely debian would have done so?17:16
_abc_I think IBM made one project on someone's "knee" once in it's history, with no ties attached and no control over developers. That was the IBM PC project, as I read it.17:16
_abc_nemo: Do you auto update? I don't.17:17
nemo$ ls -l /usr/bin/Xorg17:17
nemo-rwxr-xr-x 1 root root 274 Oct 14  2017 /usr/bin/Xorg17:17
nemonot suid17:17
nemono idea when it stopped being suid17:17
nemomaybe never was17:17
nemo_abc_: that's what pissed off the BSD  folks since they would have dropped that on theirs had they been alerted17:18
nemo_abc_: I imagine for most setups running X without suid is a pretty sensible default. so could have been that way for years17:18
nemoactually surprised BSD didn't do that17:18
nemo_abc_:  gentoo's page on this dates back to 201417:19
_abc_The hole is indeed 2 years old.17:27
_abc_Xorg stopped being suid a long time ago but that does not change things. Try ps -auxwf and look for xorg in the tree.17:28
_abc_On my ascii Xorg is executed by slim and runs as root17:28
_abc_The config files which are partly user specifiable at start time can be modified by the user to make Xorg log to key system files instead, and clobber them.17:29
nemo_abc_: ah you're right. crud.17:30
nemo_abc_: well I know about the age of the hole and the risk, I just assumed suid :/17:30
nemodidn't think they'd be running a wrapper helper17:30
_abc_Again: non suid Xorg running since 1.17, bug since 1.1917:30
_abc_It does not matter what they run while the philosophy of the Xorg is to accept config files added by the executing user anywa.17:31
_abc_y as root.17:31
nemoum... what's that "Again" about? how are we contradicting17:31
nemoyou're right about the root thing. it's just surprising since I thought they were trying to get rid of that, as the phoronix article notes17:32
_abc_The setsuid Xorg binary is no longer setsuid since 1.17. The current bug appeared in 1.1917:33
_abc_Back to IBM bearhugging RH:
nemoyeah, I'm just confused as to why they would remove setuid and still run Xorg as root17:33
nemothat seems to totally defeat purpose17:33
_abc_IBM ceo said that the new merge will "change the way container runners work". I am curious. Usually IBM does not lob tasty morsels towards M$.17:34
_abc_nemo: it is executed by the login manager which acts as a wrapper.17:34
_abc_slim in my case17:34
nemo_abc_: yeah. that is obv. I don't get the WHY 😝17:35
nemoclearly debian does NOT have the CVE fixed in 1.19 ☹17:35
nemothere's no evidence of it anywhere in the changelog apart from 1.2017:36
nemoat least it's "just" local ☹17:36
nemonot that that helps multiuser setups at all17:36
_abc_chnagelog for 1.19.2-6 seems to imply a lot of OTHER holes were also present and sanitized with that release.17:37
_abc_And I am not on that, but I am willing to bet that that is the upgrade path for 1.19.2 on ascii17:37
nemo_abc_: hmmm17:37
nemo_abc_: do you think since it was a security bug the CVE was not mentioned in the changelog?17:38
nemoit was embargoed and all17:38
nemoso 1.20 only shows it due to being post-announce..17:38
muepso is Xorg installed with suid in Debian? my impression is that it is without suid17:38
nemomuep: it's without suid yes. the confusing part (to me) is why the login manager would still run it as root, instead of user privs17:39
nemoor a restricted account for the actual login manager itself17:39
nemo_abc_: I guess the only way to know for sure would be for me to debsrc my existing .deb and actually check the affected area17:39
_abc_dpkg -l xserver-xorg -> 1:7.7+19 ?!17:39
muepnemo: AFAIK it is just the traditional way to have the login manager running as root17:40
muepit will still launch the desktop session processes with an unprivileged account when someone logs in17:40
_abc_muep: Xorg is not suid but it's manager calls it up as root17:40
nemomuep: does that actually insulate against this bug? seems unlikely17:41
nemomuep: and why trust X that much - why not just drop all privs17:41
* nemo shrugs17:41
muepnemo: do you udnerstand how the bug works?17:41
_abc_How does one list the actual installed version of the deb not of the contents?17:41
muepdpkg -l somepackage17:42
nemomuep: so... I read the announcements, but my knowledge of X itself? nowhere near good enough to know how one might exploit it17:42
nemomuep: besides the mentioned commandline17:42
_abc_I just did that. But the actual version of Xorg is sussed out by: sudo Xorg -version17:42
_abc_And THAT is 1.19.2 here17:42
nemomuep: X is a big tangled mess to me, and would not surprise me at all if that module loading can be done in some API or X protocol thingy and not just commandline17:43
_abc_Specifically: xorg-server 2:1.19.2-1+deb9u217:43
_abc_Why did debian have to add new and unconnected package versioning and hide the actual program's versions?17:43
muepnemo: my impression is that the problem is not because X runs as root. as usual with SUID binaries, the problem is the automatic transition from a non-privileged user to a privileged one, combined with the privileged process doing wrong things when the unprivileged caller provides suitable input17:44
_abc_Do you see how *useful* being able to see the actual program version is now? Looking in aptitude or whatever?17:44
muep_abc_: that is 1.19 isn't it?17:44
nemoyeah. I don't get what he's talking about... 1.19.2-1+deb9u217:45
_abc_muep: which "that". The deb package isn't. It's 1:7.7+1917:45
nemowhere typically everything past the dash is debian's stuff17:45
nemo_abc_: xserver-xorg-core17:45
nemo_abc_: the other one is  presumably17:46
_abc_At least you are right in that xserver-xorg does not provide Xorg, -core does.17:46
nemo_abc_: xorg folks have their own separate server versioning so makes sense debian would use it too17:47
muep_abc_: ah, I did not notice that other one. but yep it seems that has some version for the X server and other version numbers for other things they release alongside it17:47
nemomuep: mentioned right in that 7.7 release announce actually, 1.12 server release17:47
_abc_muep: yes, so I was barking up the wrong tree, sort of.17:47
muepbut really I do not see how you would use the setup with login manager running as root, to exploit this bug17:48
nemoaaanyway. fetching deb-src of xserver-xorg-core 1.19.2-1+deb9u2 would end all the speculation ☺17:48
nemomuep: I have nooooo idea, but I'm also don't know a ton about just what X exposes where - my familiarity with its internals is low enough that I'd rather be patched or the server dropping privs ☺17:49
muepat least the trivial case of an unprivileged user being able to launch the privileged X server process with arbitrary cmdline args is not available17:49
nemomuep: but yes, if it is ONLY commandline then no suid avoids17:49
muepnemo: you do not need to understand internals at all to understand this bug17:49
nemomuep: I understand the bug just fine. what I don't know is if that's the only pathway17:49
nemothat was my only point17:49
nemoor let's say, I read the diff and the explanation of how it was fail.17:50
muepof course there may be some other bugs in which make it a good idea to run it as non-root17:50
nemonot gonna go further than that on the understanding part ☺17:50
nemomuep: well given how many times the word CVE shows up in … ☺17:51
muepbut this currently famous one does not look like it would be an issue unless suid is used17:51
nemoor in  at least17:52
_abc_You can't really run any xserver as non root, it's a misnomer. Parts of it run as non root, but the core always runs as root, it interfaces with the hardware directly.17:52
_abc_I wonder if upgrading Xorg will break anything directly and immediately.17:52
muepon my desktop it runs as muep17:53
nemo_abc_: well... the gentoo guide for running X as root solves that, it seems, by adding trusted gui users to a group with the hardware access17:53
_abc_Yes nemo but eventually it runs as root... essentially it's peeking and poking kernel memory at a level at which it can do anything once penetrated.17:54
muepI don't think it is really a misnomer. It can delegate the HW access to the kernel, which is the traditional way to do I/O in non-graphics contexts17:54
nemo_abc_: what seriously?17:54
nemo_abc_: got a source for that?17:54
_abc_muep: do you have an accelerated server?17:54
_abc_The docs say non accel server runs as root, accel runs as user if it can17:55
nemo_abc_: an accelerated server is still accessing video memory through a relatively restricted interface, even if it is direct access17:55
_abc_Also are you on ascii?17:55
muepI do not quite know what you mean by accelerated server17:55
nemoI'm kinda astonished at the X "poking at kernel memory" thing17:55
muepI have pretty good opengl support here17:55
_abc_nemo: non vesa etc?17:55
_abc_Anyway I was quoting what I read.17:56
nemo_abc_: could you link me to where you read that?17:56
muepI think the kernel does provide my processes a fairly low-level access to video hardware17:56
_abc_I think I am quoting 20 year old stuff when it did indeed run as root and had no silicon enforced access maps.17:56
nemomuep: yeah but that's a bit different than kernel memory17:57
nemomuep: by that standard webgl is a major security hole (and IMO it is)17:57
nemoit's just a different level of fail is all17:57
_abc_Iirc x86 had no silicon enforced memory access maps for processes running in kernel space.17:57
_abc_Unlike ioperm which limits such access for ports etc.17:58
nemoand anyway, that gentoo guide seems to suggest debian could avoid the running as root if they really wanted to17:58
muepI was not talking about kernel memory at all. but I would expect that there are vulnerabilities which would allow a nominally unprivileged but still video-capably application to bypass protections of the OS17:58
nemonot super surprising since even the login manager could just be a more restricted user with the appropriate video device access17:58
nemoassuming login managers even need acceleration17:58
_abc_kernel memory and video memory are one and the same when on a shared memory system17:58
nemomuep: yeah. there were a fair # of said problems in earlier days of webgl17:58
muepbut it does not mean that it is running as root, unless you consider that in presence of bugs every unprivileged process is actually a root process17:58
nemomuep: nowdays they sanitise shaders aggressively in part due to that17:58
_abc_Accelerated ones have separate video memory and there you can talk about not being able to poke in kernel memory with a video driver, in theory.17:59
nemomuep: in part due to just crashing graphics card due to web page being not-fun17:59
_abc_Technically my current system is accelerated (puny, 10 year old) nvidia but uses shared memory.17:59
nemofor a long while despite CORS protection on some cards you could read arbitrary textures from webgl O_o17:59
nemoI remember when supporting hedgewars we'd sometimes get users reporting corruption in Hedgewars graphics18:00
nemothey'd send us screenshots...18:00
nemoit was parts of their UI showing up in game textures O_o18:00
nemothat is, a texture ID we thought we had legitimate was... not...18:00
muepthere used to be a stage where most of our graphics drivers would barely be able to run correctly written programs18:01
nemothe problem with webgl and video cards is kind of a rerun of the problem with web fonts - hooking remote access into tools that tended to trust their inputs18:01
nemoand then shocker, hey, suddenly a ttf can corrupt freetype..18:01
nemono wonder noscript blocks them by default. and that's not even getting into the insanity with ring 0 font parsing in windows18:02
nemomuep: these days I think all the browsers feed the shaders into ANGLE first...18:03
nemobut, yeah, still...18:03
_abc_Meanwhile, systemd kernel components process dhcp v6 and look at the cute bug they got just now...18:04
mueps/kernel/network config tool/18:04
nemoin all fairness, the dhcp bug is in a piece that's not standard deploy... yet...18:04
nemobut yeah, the code quality is apparently not great18:04
nemo_abc_: did you read this one?
muepit has some good guidance. I often try to steer people away from the packed struct pattern18:06
_abc_Not that Java style serialization is better in any way. Fortunately I do not deal with any of this usually.18:08
nemomuep: speaking of alignment tangentially, and debian, and, well hedgewars from above graphics chat ...18:08
nemomuep: we've been broken on 32 bit debian for a year now thanks to freepascal and SDL2 ☹18:08
nemotook us a while to realise what was going on18:09
_abc_nemo: heh.18:09
muep_abc_: you mean that buf[0] * 256 + buf[1] ? I think it is way better. for one, it works pretty much the same in pretty much any language that you might be using18:09
_abc_muep: unless you're on big endian arm or mips probably18:10
_abc_muep: Which machinesdo exist.18:10
muep_abc_: how so?18:10
muepthat bit is for unserializing, not serializing18:10
_abc_I'm guessing it would matter?18:10
muepit specifically would not matter18:11
_abc_One hopes.18:11
muepno need to hope. because you write your code to pick the bytes always in the same order18:11
_abc_I think the htoni() ntohi() functions were not created for nothing.18:11
nemo  if you guys happen to use freepascal for anything for some reason ☺18:11
nemoworkaround for now will be to use the pas2c thing unc0rr wrote long ago to compile using clang instead for next debian 32 bit release - long-term we're just gonna use rust18:12
muepthey are a different way to approach the problem, but like the writer of that article, I would prefer code that just naturally does the same things regardless of endianness18:12
nemomuep: well. there's also the question of why the hell are they constantly writing new code for crap that's existed for decades18:12
nemomuep: would make sense if it was implemented in, oh, node.js 😉18:12
nemothey being systemd...18:13
muepthis would always read the number as big-endian, regardless of HW architecture: some_number = buf[0] * 256 + buf[1]18:13
_abc_Poettering said in his interview linked above that he will take over the world, unifiy all linuxes, and they will be all faster and better due to him18:13
nemo_abc_: heh. even if he was joking about unifying all linuxes under his control, it's probably a joke that's revealing18:14
_abc_And that will create pax aeterna (my comment)18:14
_abc_He was not joking.18:14
_abc_it's not his fault, the voices in his head tell him what to do...18:15
nemoPax Æternum ?18:15
nemomy latin conjugation is nonexistent but I looked that one up out of curiosity18:15
_abc_The hubris of any non institutionalized individual claiming everyone else on this planet is wrong in anno domini 2011 is absolutely remarkable from a medical point of view.18:15
_abc_Technically I do not look these things up since my local language is Romance and Latin based.18:16
_abc_And the modern version of that saying is pace eterna.18:17
ejrso ibm is going to buy red hat - i guess that makes corporatisation of systemd even less unavoidable18:51
cirdanejr: depends. i would hope ibm is smart enough to shitcan that trash20:23
muepto me it does not seem like RH is doing all systemd development20:32
Digitglimpsing at linked in another chan with the words "hurd is dead", i get the impression "pfff.  debiand propblems."  and maybe, hurd's fine devuan-wise.  ?  i mean, even if dormant and lacking manpower, still, nothing impeding, right?22:08
pankeriniI think GuixSD will be the first full-fledged GNU/Hurd distribution and they don't even use systemd.22:17
Centurion_DanDigit: sure... we may even take up the port one of these days...23:11

Generated by 2.17.0 by Marius Gedminas - find it at!