Re: [Rkhunter-users] New release please
Brought to you by:
dogsbody
Menu
▾
▴
Re: [Rkhunter-users] New release please
|
From: John D. <jwa...@gm...> - 2023-11-28 05:38:21
|
Hi John & Mark, I'd also like to give a vote of thanks to John Horne for his efforts on the rkhunter project. Personally I "retired" almost 10 years ago now so it's unlikely that I'd be able to take on the project. Obviously we do need some young blood if rkhunter is to continue. Mark, you've included comments I made long ago, & I was no longer confused after a conversation with John Horne around that time & the fedora people doing a build. I am about to update a machine to FC39, so I'll see what effect that has. Currently FC38 is at rkhunter-1.4.6-21.fc38.noarch. The bug I originally reported in fedora bugzilla was, https://bugzilla.redhat.com/show_bug.cgi?id=1851620 & it ends with, Fixed In Version: rkhunter-1.4.6-10.fc34 rkhunter-1.4.6-10.fc33 -> rkhunter-1.4.6-10.fc34 rkhunter-1.4.6-10.fc33 rkhunter-1.4.6-10.fc32 If John Horne does make a new release can we include the version number at the start of the /usr/bin/rkhunter shell script & some historical commentary? (What's there now is dated 2017!) Cheers John On Mon, 2023-11-27 at 09:35 -0500, Mark Stosberg wrote: > > I found that the note you don't plan to support rkhunter going forward: > https://sourceforge.net/p/rkhunter/support-requests/74/ > > Thank you for the time you put into rkhunter and supporting it for as long as you did. It's completely fair for someone else to pick up the maintenance torch at this point. > > As you mention in that message, version 1.4.7 is stable. Given that, could you be willing to make a final release from what's in Sourceforge? > > Doing so would be an opportunity to add a clear note to the changelog that you no longer plan to maintain it, adding a call for new maintainers there. That may get the attention of some people who didn't find the maintenance status note in the bug tracker or this mailing list. > > Mark > > On Thu, Mar 2, 2023 at 11:12 AM Mark Stosberg <ma...@ri...> wrote: > > > so I'm confused as to what's going on. (I'm not a developer on it) > > > > > > > > > > Can anyone shed light? > > > > > > > > > Distros distribute patched versions of software. So when you see a version of rkhunter-1.4.6-18, that means they've made 18 releases of the 1.4.6. You reported a bug about this to Fedora in 2020, and Fedora released a fix for it in their 1.4.6-10 release. > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1851620 > > > > Independently, the bug was discovered and reported by a Ubuntu user to their bug tracker in 2021, but never fixed in Ubuntu releases: > > https://bugs.launchpad.net/debian/+source/rkhunter/+bug/1911014 > > > > That's why we are both using "1.4.6", yet you have the fix in your RPM, but I don't have it on Ubuntu. Instead, I've now written a bit of Ansible code for my internal team to apply the patch that's in the rkhunter repo for this issue until the next release is made. > > > > It would be a lot less work overall if the fix was in an official release, rather than having people using various distributions finding and patching the independently in downstream packages or in private corporate repos. > > > > Here's the patch I applied: > > > > +--- a/files/rkhunter > > ++++ b/files/rkhunter > > +@@ -18422,20 +18422,49 @@ > > + > > + > > + # > > ++ # Where possible we will use the 'sshd -T' command to obtain SSH > > ++ # configuration values. The command will handle any configuration > > ++ # sub-directories as well as 'Match' clauses. If the command is > > ++ # not available, then we simply use the old method of checking > > ++ # the main configuration file. > > ++ # > > ++ > > ++ USE_SSHDT=0 > > ++ SSHD_CMD=`find_cmd sshd` > > ++ > > ++ if [ -n "${SSHD_CMD}" ]; then > > ++ ${SSHD_CMD} -T >/dev/null 2>&1 > > ++ test $? -eq 0 && USE_SSHDT=1 > > ++ fi > > ++ > > ++ if [ $USE_SSHDT -eq 1 ]; then > > ++ display --to LOG --type INFO FOUND_CMD 'sshd' "${SSHD_CMD} -T" > > ++ fi > > ++ > > ++ # > > + # Now we check some of the configuration options. > > + # > > + # First we check for allowed root access. > > + # > > + > > +- RKHTMPVAR=`grep -i '^[ ]*PermitRootLogin[ =]' "${SSH_CONFIG_FILE}" 2>/dev/null | tail ${TAIL_OPT}1` > > +- > > +- if [ -n "${RKHTMPVAR}" ]; then > > +- # > > +- # Get the value that has been set. > > +- # > > +- > > +- RKHTMPVAR2=`echo ${RKHTMPVAR} | sed -e 's/^[^ =]*[ ]*=*[ ]*\([^ #]*\).*$/\1/' | tr '[:upper:]' '[:lower:]'` > > +- > > ++ RKHTMPVAR="" > > ++ RKHTMPVAR2="" > > ++ > > ++ if [ $USE_SSHDT -eq 1 ]; then > > ++ RKHTMPVAR2=`${SSHD_CMD} -T -C user=root,host=* 2>/dev/null | ${AWK_CMD} '{ IGNORECASE=1; if (/^PermitRootLogin /) print tolower($2); }' 2>/dev/null` > > ++ else > > ++ RKHTMPVAR=`grep -i '^[ ]*PermitRootLogin[ =]' "${SSH_CONFIG_FILE}" 2>/dev/null | tail ${TAIL_OPT}1` > > ++ > > ++ if [ -n "${RKHTMPVAR}" ]; then > > ++ # > > ++ # Get the value that has been set. > > ++ # > > ++ > > ++ RKHTMPVAR2=`echo ${RKHTMPVAR} | sed -e 's/^[^ =]*[ ]*=*[ ]*\([^ #]*\).*$/\1/' | tr '[:upper:]' '[:lower:]'` > > ++ fi > > ++ fi > > ++ > > ++ if [ -n "${RKHTMPVAR2}" ]; then > > + if [ "${RKHTMPVAR2}" = "${ALLOW_SSH_ROOT_USER}" ]; then > > + test "${RKHTMPVAR2}" = "no" && RKHTMPVAR="NOT_ALLOWED" || RKHTMPVAR="ALLOWED" > > + display --to SCREEN+LOG --type PLAIN --result ${RKHTMPVAR} --color GREEN --log-indent 2 --screen-indent 4 SYSTEM_CONFIGS_SSH_ROOT > > +@@ -21050,6 +21080,8 @@ > > + ALLOW_SSH_PROT_V1=0 > > + ALLOW_SSH_ROOT_USER="" > > + SSH_CONFIG_DIR="" > > ++# This SSH option is only set within the program. > > ++USE_SSHDT=0 > > + > > + # These syslog options can only be set in the configuration file. > > + ALLOW_SYSLOG_REMOTE_LOGGING=0 > > > > > > > > > > > > > > > > > > > > > > On Wed, 2023-03-01 at 15:32 -0500, Mark Stosberg wrote: > > > > > > > > Hello, > > > > > > > > I was just tracking down a warning was getting "PermitRootLogin No" errors, > > > > and found the the bug was found in 2020 and long ago patched upstream but not > > > > released. It looks like there have been a lot of updates since 1.4.6 and a new > > > > release would be welcome. Thanks. > > > > > > > > > > The version I'm using (Fedora 37) has a build date of Sat 23 Jul 2022 11:24:32 > > > (the RPM package rkhunter-1.4.6-18) & does include the changes I suggested to > > > check the /etc/ssh/sshd_config.d/* files. (unless I changed myself, but I > > > thought a fixed version was distributed in fedora) > > > > > > Sadly the /usr/bin/rkhunter script itself does not have a version number/date > > > in it that would allow relatively easy comparison to the sourceforge version, > > > which still seems to have a modified date of, 2018-02-20 which seems very old! > > > (https://sourceforge.net/projects/rkhunter/files/) & not consistent with changes > > > that are obviously there (my change suggestion was mid 2020) > > > > > > Yet there are changes shown in the Project activity, > > > (https://sourceforge.net/projects/rkhunter/) > > > so I'm confused as to what's going on. (I'm not a developer on it) > > > > > > Can anyone shed light? > > > Would it be possible to have the version number in the header of the > > > /usr/bin/rkhunter script? (for consistency?) > > > > > > & is there an easy way to prompt fedora to release a new version? > > > > > > > Mark > > > > _______________________________________________ > > > > Rkhunter-users mailing list > > > > Rkh...@li... > > > > https://lists.sourceforge.net/lists/listinfo/rkhunter-users > > > > > > > > > -- > > Mark Stosberg (he/him) > > Director of Systems & Security > > ma...@ri... | 765.277.1916 > > https://www.rideamigos.com > > Changing the way the world commutes. > > > > > -- > Mark Stosberg (he/him) > Director of Systems & Security > ma...@ri... | 765.277.1916 > https://www.rideamigos.com > Changing the way the world commutes. > > _______________________________________________ > Rkhunter-users mailing list > Rkh...@li... > https://lists.sourceforge.net/lists/listinfo/rkhunter-users |