Ad Widget

Collapse

Agent2 must die die die

Collapse
X
 
  • Time
  • Show
Clear All
new posts
  • otheus
    Member
    • Mar 2009
    • 53

    #1

    Agent2 must die die die

    Sadly, the subject is not in jest. I appreciate all the incredible effort put into this sub-project. But it was the wrong direction to go in, it was the wrong architecture, it was the wrong language. While I can assume many of its devs have spent years of their life on this project, and I mourn their wasted efforts, I must stand up and say what has been on my mind for 5 years. Hopefully, I'm not too late with this message.

    I fully realize that this message will come across as inflammatory and engender a "who the hell is this guy?" sentiment. The fact that I only come around here every 7 years to pass judgement, speaks ill of me for sure. Please be assured, I have this project's interests at heart: I've been a user and fan since v1.2 (of Zabbix, not agent2).

    If you don't understand what my complaint is: consider the timing. What else is happening in OSS communities right now? March/April 2024 may be remembered as the month OSS changed forever.

    If you still don't understand what my complaint is, I'll give you the hint I discovered from ZA2v3: the project imports untrusted code from untrusted projects without any hint of certification, code-review, or auditing of the upstream dependencies, many of which have their own dependencies. In ca 2018, I saw at least 2 bugs in upstream code that made the code vulnerable. There are 51 named projects on which ZA2 depends, and many of these may have other dependencies. The fact that hashes are used to lock in these versions only means a tagged version cannot be spoofed. Anyone familiar with the recent developments knows such hashes represent the very minimum of safety.

    If you still don't understand what my complaint is: then simply heed my advice: do NOT under ANY circumstances use or rely on zabbix-agent2.

    Normally, I would ask "what steps have been taken to mitigate...." such and such. But it's sisyphean task: It doesn't matter. The architecture is simply not suitable. Golang is not suitable. A modularized system built in a static language such as Rust, or an improvement over the original Agent's loadable module system is what is needed to address the core issues. I don't claim to have the definitive answer about the right choice, but I can at least be sure about the wrong one.

    Also: I recommend anyone who responds here be circumspect in their wording.
    Last edited by otheus; 03-04-2024, 15:35.
  • otheus
    Member
    • Mar 2009
    • 53

    #2
    I should amend my statement about "wrong language". There's nothing _inherently_ wrong with Golang. Rather, it's not _suitable_ for such a program as the agent. The Agent should be considered a component of an embedded system: it should absolutely not use the latest anything. Golang was built by Google for the purpose of rapid development of fast programs that could re-use code easily. Code re-use _is_ the main problem here. I would love to use the agent, as its performance is better than the nest of shell scripts I currently use in conjunction with zabbix-agent1. Using shared-libs with agent1 is a bit painful given the build process requirements.
    Last edited by otheus; 03-04-2024, 16:24.

    Comment

    • cyber
      Senior Member
      Zabbix Certified SpecialistZabbix Certified Professional
      • Dec 2006
      • 4807

      #3

      Originally posted by otheus
      If you don't understand what my complaint is: consider the timing. What else is happening in OSS communities right now? March/April 2024 may be remembered as the month OSS changed forever.
      Care to elaborate? Not everyone follows "OSS world"...
      I think I understand, where you are aiming, but all of it looks like a panicky cry without much explanations...

      Comment

      Working...