https://bugzilla.redhat.com/show_bug.cgi?id=1756582 --- Comment #13 from Christopher Engelhard <ce@xxxxxxx> --- Sorry for the delay, work intruded. Also, thanks again for the time & effort you put into this. - Just to clarify, afaik the packages linked on the sshguard website are not built/maintained by upstream, though the debian package might be derived from their 'debian' branch. - Regarding 1.1, is there something similar to Arch's base-devel group, i.e. a set of packages that forms a standard build environment and is thus assumed to be present at buildtime and thus not listed explicitly? Anything using a configure script is likely to require coreutils and diffutils for example, but I don't usually see them as builddeps. spec: https://gitlab.com/lcts-rpm/sshguard/raw/sshguard-2.4.0-10/sshguard.spec diff: https://gitlab.com/lcts-rpm/sshguard/compare/sshguard-2.4.0-9...sshguard-2.4.0-10 srpm: https://copr-be.cloud.fedoraproject.org/results/lcts/sshguard/fedora-rawhide-x86_64/01045896-sshguard/sshguard-2.4.0-10.fc32.src.rpm 1.1) Additional dependencies. fixed. coreutils - 'echo' is used in /usr/sbin/sshguard diffutils - 'diff' and 'cmp' are used at buildtime (in 'configure' and 'ylwrap', respectively), see question above fillup - not needed. opensuse-specific dependency, I don't know what they use it for. grep - grep is used by /usr/sbin/sshguard openssh - not needed. People might in fact want to monitor e.g. ftp on a host without (a need for) ssh so I'd say it's bad to include this as a dependency. If ssh is missing/not running, the configs if unmodified will cause sshguard to monitor an empty log, which it is perfectly happy to do 1.2) %{?systemd_requires} fixed - nice, learned something new. 2.1) the upstream package has better structured docs. fixed: %{_pkgdocdir}/sshguard/ |- CONTRIBUTING.rst |- README.rst |- examples/ |- sshguard.conf.sample |- whitelistfile.example 2.2) /var/lib/sshguard/db ownership - used by the blacklist feature in the opensuse package, but not expected or created by sshguard on its own - not upstream's suggested path for the blacklist, they put it directly in /var/lib/sshguard/. According to the spec .../db is an opensuse default - see 2.4 2.3) better config file fixed - I adapted examples/sshguard.conf.sample, which is extensively commented 2.4) white/blacklisting I decided to set up the package so that it is prepared for this feature, but leaves it disabled. That way, a user can simply uncomment the relevant lines in the config file without further configuration - added /etc/sshguard.whitelist containing only commented instructions for use - added /var/lib/sshguard as package-owned dir - preset blacklist file to /var/lib/sshguard/blacklist, which will be created by sshguard if bl is enabled. It's not owned by the package, so RPM will delete the folder if the user didn't enable it, but retain the blacklist file if they did 2.5) net.sshguard.plist correct, removed 2.6) prefix the directory you pack with "%dir" fixed 3) simclist I haven't heard back yet. 4) CI testing It's a bit convoluted right now: - 'make check' already checks that all log parsing / pattern matching is working as expected - GitLab CI (config: https://gitlab.com/lcts-rpm/sshguard/blob/master/.gitlab-ci.yml) tests installation and basic functionality - set up minimal docker installations of the various official CentOS & Fedora images on docker hub - build & install the (sub-)package(s) - test that systemctl/service start|stop|status works without issues - lint the packages - sshguard-testing repo on copr tests that the build also works on other architectures - I have a tiny cloud server that uses those test builds and checks that the package is safe to use (for 'checks', read: it installs & uses the test build and I test if I can lock myself out etc.) GitLab CI is triggered by commits, test builds on copr by commits to master, test server updates via dnf-automatic. It should not be too difficult to integrate all that into a single pipeline - I only use copr+gitlab ci because the latter only does x86_64. Simulating an attack programmatically is certainly possible. If ssh is available, one could probably just try to log into localhost with fake credentials to trigger a block. I'll have to test that a bit. I'll have a look at fedora's CI ... it uses ansible, so that's a plus already ... -- You are receiving this mail because: You are on the CC list for the bug. You are always notified about changes to this product and component _______________________________________________ package-review mailing list -- package-review@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to package-review-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/package-review@xxxxxxxxxxxxxxxxxxxxxxx
