-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Pre-commit signature database integrity check #1
Comments
I modified the script provided by urlhaus for twinclams, I will attach, I added a variable to easily replace with your db, and added randomised tmp folder, and made it FreeBSD compatible, will likely need adjusted on the mktemp command syntax again for linux. It could be further improved if you provided hashes then the hashes could be compared with downloaded db. Note also I removed the chown commands, as this script should be run as clamav user natively not by root. |
@chrcoluk Thanks for your reply, but I don't see how the script relates to my original question? The script downloads twinclams.ldb (something Fangfrisch already does, and in a more advanced manner at that) and verifies the integrity of the downloaded file. What I am inquiring about is a QA check after an updated DB file is generated and before the resulting file is committed to GitHub. |
I apologise, I thought you meant after the file is downloaded but before it is activated in clamav. You could still check the file using the same method before committing using git cli. |
I was hoping that me opening this ticket would gently nudge the authors to add some quality assurance in a CI process. One option would be to commit changes into a Git branch, have a CI step perform a verification like the one your script uses, and only merge the changes into the master branch if the CI verification succeeds. |
Greetings. In reference to the following issue a user filed for Fangfrisch, I would like to know if there is a mechanism in place which verifies the signature database's integrity before changes are committed? Of course consumers of your data should perform additional checks themselves, but I think it would be useful if TwinWave as the producer also performed checks. Thanks.
The text was updated successfully, but these errors were encountered: