**** BEGIN LOGGING AT Fri Jul 07 03:00:03 2017
Jul 07 04:54:17 <stryngs> Anyone here goin to DEFCON?
Jul 07 05:37:15 <Oksana> Not me. It's USA, right? Los Angeles or something? Too far away.
Jul 07 07:31:31 <Oksana> Okay, http://www.ebay.com.au/itm/172768538525 listed
Jul 07 18:06:56 <Pali> Great, systemd "not-a-bug" report got CVE!
Jul 07 18:07:05 <Pali> https://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-1000082
Jul 07 18:07:37 <parazyd> ^_^
Jul 07 18:07:49 <Pali> "not-a-bug", "closed" and locked ticket: https://github.com/systemd/systemd/issues/6237
Jul 07 18:09:08 <L29Ah> :D
Jul 07 18:09:44 <L29Ah> so it is fixed after all?
Jul 07 18:10:51 <Pali> seems not fixed, just assigned CVE
Jul 07 18:11:42 <Pali> so vulnerability would propagate to downstream customers/distributions as would be evaulated by security teams
Jul 07 18:16:26 <KotCzarny> :>
Jul 07 22:46:57 <DocScrutinizer05> Pali: (CVE) https://botbot.me/freenode/devuan/2017-07-04/?msg=88110981&page=1
Jul 07 22:47:14 <DocScrutinizer05> could say "I knew it"
Jul 07 22:49:54 <Pali> more interesting part, that CVE was assigned by Red Hat Security
Jul 07 22:50:15 <DocScrutinizer05> CVE >>systemd v233 and earlier fails to safely parse usernames starting with a numeric digit<< is incorrect
Jul 07 22:50:26 <DocScrutinizer05> LOL
Jul 07 22:51:01 <DocScrutinizer05> so that's an even more evil spin? create an incorrect CVE just to close it as NOTABUG as well then?
Jul 07 22:52:06 <Pali> technically CVE description is correct. systemd does not parse usernames with with digit correctly
Jul 07 22:52:13 <Pali> that is truth
Jul 07 22:52:20 <DocScrutinizer05> fact is (according to explanation from the poettering horse's mouth): systemd DOES parse the parameter value, but detects it's malformed and thus ignores the whole parameter
Jul 07 22:53:05 <Pali> from security point of view, this is unsafe parsing
Jul 07 22:53:09 <DocScrutinizer05> when user= parameter gets ignored, the default kicks in which is user=root
Jul 07 22:53:44 <DocScrutinizer05> yes, from security POV, but obviously not from Pezzering's POV
Jul 07 22:53:53 <DocScrutinizer05> poettering*
Jul 07 22:54:16 <DocScrutinizer05> he intentionally designed stuff that way
Jul 07 22:54:52 <DocScrutinizer05> though obviously when right side of = is incorrect MUST be another class of error than when left side of = is incorrect
Jul 07 22:55:02 <Pali> looks like some rh sec team see it differentely as poettering and assigned for it cve even poettering disagreed...
Jul 07 22:55:08 <DocScrutinizer05> in systemd it's all the same
Jul 07 22:55:37 <DocScrutinizer05> please see https://botbot.me/freenode/devuan/2017-07-04/?msg=88110981&page=1
Jul 07 22:56:09 <Pali> systemd-sysusers... bah!
Jul 07 22:56:16 <DocScrutinizer05> this is a bug in concept/design
Jul 07 22:56:25 <DocScrutinizer05> indeed X-P
Jul 07 22:57:55 <DocScrutinizer05> >>when a parameter has syntactically invalid *value* then the whole parameter is considered as "unknown". This makes extreme NONsense here since when admin writes "user=" they _never_ expect that parameter gets silently ignored because of syntactically invalid value (user="666poettering") and thus the job gets ran as default root instead<<
Jul 07 22:59:24 <Pali> I read it how it was designed, and... no comment
Jul 07 23:00:49 <DocScrutinizer05> actually that's a bug from OVERdoing sanity checks. A simple check if right side value of "user=" is an *existing user allowed for that job* would completely suffice
Jul 07 23:01:21 <DocScrutinizer05> let the system take care about users that start with a number, it's not systemd to judge if that's allowed username or not
Jul 07 23:04:04 <DocScrutinizer05> https://xkcd.com/1700/ <- systemd
Jul 07 23:14:32 <DocScrutinizer05> simply comment out that cruft bullshit syntactical check of user= *value* and everything fine
**** ENDING LOGGING AT Sat Jul 08 03:00:00 2017