Closed gyro666 closed 1 month ago
I'm seeing a warning about this when installing the package in ubuntu too.
Hi @gyro666 and @diasjorge,
We are aware of the problem you have mentioned and we know that it may have been an inconvenience for you. A solution has already been applied to solve this problem after the 4.9.0 release. Simply execute again the command
sudo apt-get update
and check that the repository metadata is correctly added using the command
apt-cache policy | grep -A3 'wazuh.com'
The result of executing that command should look something like the following taking into account that the system may change depending on your system version and distribution:
500 https://packages.wazuh.com/4.x/apt stable/main amd64 Packages
release o=4.x/apt stable,a=stable,n=stable,l=4.x/apt stable,c=main,b=amd64
origin packages.wazuh.com
500 https://mirrors.edge.kernel.org/ubuntu jammy-security/multiverse amd64 Packages
release v=22.04,o=Ubuntu,a=jammy-security,n=jammy,l=Ubuntu,c=multiverse,b=amd64
origin mirrors.edge.kernel.org
where you can see that the labels are correctly specified with 4.x/apt stable
.
If you have any further questions or need additional guidance, feel free to ask.
Hi @hossam1522
thanks for clarifying the situation. I'm more at ease knowing that you are aware. Also thanks for the info on how to fix it.
Still note that there are environments that use orchestration to make changes on many machines at once or just keep CI/CD lights on and having the idempotent states include having the 'apt update' as part of them. Now occasional change if announced is not of a big issue. Let's say once in 6months but unannounced can be a problem as it breaks the normal operation.
Now my current choices are either to blindly accept the changes ... which is kind of dangerous move as I would then blindly accept any change on the source of security oriented software, or to react every time it breaks when someone jumps on me saying "hey there is something wrong".
I'm quite paranoid when it comes to supply attack possibility as it became a target of choice in recent time. I check the repo keys locally and every change has to be verified manually before accepted. Lucky this does not happen too often so it's fine when it does. (once a year)
Now yes I can make a local mirrored repo and then have more control of the events like this but since it unusually don't happen please be aware that either announce this changes or state when you are expecting to make them as it causes ripple effect downstream.
With that said, and for my decision how to address this issue further, can you elaborate just a tiny bit more on what exactly means that issue will be solved after 4.9.0 release?
I've noticed yesterday that repo went back (breaking the previously accepted change)
E: Repository 'https://packages.wazuh.com/4.x/apt stable InRelease' changed its 'Label' value from '. stable' to '4.x/apt stable'
Now that is OK since I just accepted "blindly" the change in a not so critical systems and not actual production but it broke operation there once more.
so any info are you expecting more changes and if possible when?
Hi @gyro666,
That change was an unintentional change and we fixed it shortly after it appeared. The change you pointed out
E: Repository 'https://packages.wazuh.com/4.x/apt stable InRelease' changed its 'Label' value from '. stable' to '4.x/apt stable'
is the one it should be after it was fixed to restore the original value.
There will be no further changes, but in case there were any, we will notify the community in advance so you can adapt and avoid problems. For the moment, everything will remain as it is.
If you have any further questions or need additional guidance, please do not hesitate to ask.
the following has nothing to do with the Debian packages but it does with the Debian package repo. change breaks automated updates:
if we run it interactively
there are changes to Release file in repo. Be aware that by doing so any already installed Debian system will break automated update (update NOT upgrade) steps. The changes cause the exit status of the update step a non zero value causing any subsequent steps to fail.
This also is known to cause some GUI based package managers to throw random unspecified errors that are hard to follow unless one fails back to console and using apt cmd.
Now I can't find anywhere if this change was on purpose or accidental but here it is for someone to confirm and acknowledge that breaking the automated updates was deliberate and not a supply chain attack :)
details: used repo info: