> > EPEL retired the ELOG package for security reason
>
> no, this is not what happened, we (I) requested removal of elog packages from epel, debian and ubuntu because they had obsolete pre-cve (insecure)
> versions that should not be used. they were very pleasant, quick and efficient dealing with this. (but obviously they could not retroactively
> remove elog from old versions of ubuntu and debian).
Yep i remind now. Finally the result was the same :-(
if CVEs had been fixed in repo, you should make a new official ELOG version and update download site with tarball, .exe and RPMS. Almost End-users do not use git repo...
> we opted to not reclaim ownership of these packages (original person who created these packages had drifted away) because
> none of us know how to create debian packages and all of us (speaking for myself) know how much PITA is building RPM packages.
> plus I do not know if Stefan has access to el8 and el9 machines (I do not, we are moving to ubuntu/debian wholesale).
I spent one hour yesterday to install almalinux in VM on my laptop, clone repo, rebuild ELOG RPM, install the new rpm and start elogd.
You should have several VM on a shield for that :-P
> I recommend building elog from git sources. it is simple, two commands (git clone + make) vs one command (rpm install),
> it ensures you always have the latest version available, it is easy to update (git pull + make) and you do not
> get any surprise updates (from nightly apt update/upgrade).
The problem of building ELOG is that it needs a development machine with C++ and dependencies installed. This is not present (or forbidden) in production machine/VM...
End users need simple package (rpm/pkg/*) to install it as all other products, with the confidence that this package has been testing...
Also, "git clone and make" should be surprising, as the devs use a particular environment that should be different from user's one.
The future is maybe something more universal as Flatpak/SNAP/...
Btw thanks for ELOG program and support.
Bye
Laurent |