<!DOCTYPE html>
<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>Hello systemd users and developers,</p>
    <p>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.</p>
    <p>I were accused I did something on purpose and were unwilling to
      cooperate. I don't think that is true.</p>
    <p>Yes, I have sent a request to our security team to review RH
      bugzilla bug #<span class="ng-scope">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.</span></p>
    <p><span class="ng-scope">This was the text I have sent:</span></p>
    <blockquote>
      <p><cite><span class="ng-scope"></span>Hi Security team,
          <br>
        </cite>
        <cite><br>
          can you please evaluate bug <a class="moz-txt-link-freetext"
            href="https://bugzilla.redhat.com/show_bug.cgi?id=2222261">https://bugzilla.redhat.com/show_bug.cgi?id=2222261</a>,
          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.
          <br>
        </cite>
        <cite><br>
          Unforunately that were reported publicly on upstream:
          <br>
        </cite>
        <cite><br>
          <a class="moz-txt-link-freetext"
            href="https://github.com/systemd/systemd/issues/25676">https://github.com/systemd/systemd/issues/25676</a>
          <br>
        </cite>
        <br>
        <i>Is it just a bug or vulnerability?
        </i></p>
    </blockquote>
    <p>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.<br>
    </p>
    <p>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.<br>
    </p>
    <p>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.</p>
    <p>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.</p>
    <p>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.<br>
    </p>
    <p>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.</p>
    <p>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 <span
        class="p-name vcard-fullname d-block overflow-hidden"
        itemprop="name">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.<br>
      </span></p>
    <p><span class="p-name vcard-fullname d-block overflow-hidden"
        itemprop="name">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.<br>
      </span></p>
    <p><span class="p-name vcard-fullname d-block overflow-hidden"
        itemprop="name">I think I deserve an apology from Luca, but I
        doubt I will receive some.<br>
      </span></p>
    <p><span class="p-name vcard-fullname d-block overflow-hidden"
        itemprop="name">Thank you for reading it so far,</span></p>
    <p><span class="p-name vcard-fullname d-block overflow-hidden"
        itemprop="name">Happy new year everyone and less drama in it!</span></p>
    <p><span class="p-name vcard-fullname d-block overflow-hidden"
        itemprop="name">Best Regards,<br>
        Petr Menšík<br>
      </span></p>
    <p>1. <a class="moz-txt-link-freetext" href="https://github.com/systemd/systemd/issues/25676">https://github.com/systemd/systemd/issues/25676</a><br>
      2. <span class="ng-scope"><a class="moz-txt-link-freetext" href="https://bugzilla.redhat.com/show_bug.cgi?id=2222261">https://bugzilla.redhat.com/show_bug.cgi?id=2222261</a><br>
        3. <a class="moz-txt-link-freetext" href="https://bugzilla.redhat.com/show_bug.cgi?id=2222672#c3">https://bugzilla.redhat.com/show_bug.cgi?id=2222672#c3</a><br>
        4.
        <a class="moz-txt-link-freetext" href="https://github.com/systemd/systemd/blob/main/docs/CODE_OF_CONDUCT.md">https://github.com/systemd/systemd/blob/main/docs/CODE_OF_CONDUCT.md</a><br>
      </span></p>
    <pre class="moz-signature" cols="72">-- 
Petr Menšík
Software Engineer, RHEL
Red Hat, <a class="moz-txt-link-freetext" href="https://www.redhat.com/">https://www.redhat.com/</a>
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB</pre>
  </body>
</html>