CVE-2023-7008 Christmas drama notes

Tue Dec 26 00:11:25 UTC 2023

Hello systemd users and developers,

I have experienced something in issue #25676 [1], which has been closed 
and I am not allowed to comment there anymore. But the experience I had 
there were so terrible, I feel a need to comment a little bit.

I were accused I did something on purpose and were unwilling to 
cooperate. I don't think that is true.

Yes, I have sent a request to our security team to review RH bugzilla 
bug #2222261 [2], because I felt systemd team fail to own the problem 
reported to them appropriately. That were on day 2003-07-12, 15:38. No, 
it were NOT at 7th of December.

This was the text I have sent:

    Hi Security team,

    can you please evaluate bug
    https://bugzilla.redhat.com/show_bug.cgi?id=2222261, whether it is
    deserves own CVE? It contains DNSSEC support, but it can be
    trivially made into serving unsigned content even on signed zones
    data. It does not crash, but allows DNS spoofing.

    Unforunately that were reported publicly on upstream:

    https://github.com/systemd/systemd/issues/25676

    /Is it just a bug or vulnerability? /

That were somehow end of my role. Just a day after that Lukáš Nykrýn 
commented new bug [3], acknowledging they knew about the issue. I have 
told them I consider it important. It were received and waited for 6 
months without any visible progress and 6 days ago, the ticket for it 
has changed and CVE-2023-7008 were assigned to it. Yes, I admit the 
timing were far from ideal, because it happened few days before 
Christmas Eve, where I think most of involved people has holidays. Not 
anything I had any influence on. Including me, I were at that time on 
vacation for two weeks already. It were done by person living in India, 
possibly not aware how bad the time for the change is now.

Why I have not been helpful in adding note it is happens only with 
DNSSEC=yes? Because with DNSSEC=no it is not a single bit safer, as it 
might appear. In unfixed versions on-path attacker can insert any 
response to your DNS cache, regardless DNSSEC setting you have. Of 
course, with DNSSEC=no or DNSSEC=allow-downgrade that is common and 
expected and not a vulnerability. But is it better or more secure? Of 
course not, not a single bit! With recently fixed versions, only 
DNSSEC=yes prevents bogus responses.

Yet, I were accused to have abused something. I did not. But I would 
like to thank Luca for removing me from systemd organization. Yes, none 
of my proposed commits have been never been merged. I have received 
limited rights to be able to mark selected issues with tags like 
downstream/rhel or downstream/fedora, so those issues can be 
prioritized. In order to help systemd team prioritize important fixed to 
systemd-resolved for RHEL, given I possess higher DNS expertise than 
they do (my opinion without a proof). I am glad I were removed.

It is very surprising how poisonous atmosphere I have found in such very 
important project in open source operating systems, as is the *systemd*. 
I admit I have been warned by my former manager to not expect any 
positive negotiations from systemd people, because more people failed 
before me, but I have tried. But I would not recommend anyone to even 
try to collaborate on systemd, if they may disagree with anyone. I have 
never met more toxic and unhelpful behavior from upstream maintainers 
than on systemd. Not in my 7 years I work on different RHEL components. 
I now understand why flame wars about systemd vs other process managers 
were always that emotional. I don't think there are important technical 
deficiencies, but the communication style I have met here is plain terrible.

For my whole 7 years I have been working in Red Hat, I have not met more 
frustrating upstream than at systemd. I had quite friendly discussion 
with our people working on systemd at Brno or from Poland. But for 
reason unknown to me, I struggled quite much with other people in the 
project, most often Lennart himself. Especially on issues discussions.

It may look I hate everything systemd, that is far from correct. I think 
systemd service manager is great tool, as is for example systemd-nspawn. 
But systemd-resolved is full of unnecessary bugs and strange design 
choices nobody is willing to fix. If they are willing, they get fixed so 
fast.

I don't want to be connected with systemd project in any way anymore. I 
would be ashamed to be connected with it. I would like to thank Evgeny 
Vereshchagin for standing on my side, I value it very much. Link to Code 
of Conduct [4] made me laugh. It seems it were just copied from some 
random other project, where they truly meant what is written in it.

I will still report issues in systemd if I found them. I consider it my 
unpleasant and worthless duty, because it seems they are ignored anyway. 
If they are fixed, that is usually done in a way I consider wrong. 
systemd-resolved is included as a default installed DNS cache in Fedora, 
that is why I am willing to do offer some help. Bad mistake in my 
opinion, but even that deserves to have issues to be known, reported 
(and ignored). I will try to minimize my reports to unemotional facts as 
much as I will able to.

I think I deserve an apology from Luca, but I doubt I will receive some.

Thank you for reading it so far,

Happy new year everyone and less drama in it!

Best Regards,
Petr Menšík

1. https://github.com/systemd/systemd/issues/25676
2. https://bugzilla.redhat.com/show_bug.cgi?id=2222261
3. https://bugzilla.redhat.com/show_bug.cgi?id=2222672#c3
4. https://github.com/systemd/systemd/blob/main/docs/CODE_OF_CONDUCT.md

-- 
Petr Menšík
Software Engineer, RHEL
Red Hat,https://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20231226/84b3b36d/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0x4931CA5B6C9FC5CB.asc
Type: application/pgp-keys
Size: 9098 bytes
Desc: OpenPGP public key
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20231226/84b3b36d/attachment-0001.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20231226/84b3b36d/attachment-0001.sig>