Package Details: firehol 2:3.1.0-2

Git Clone URL: (read-only)
Package Base: firehol
Description: The iptables stateful packet filtering firewall builder.
Upstream URL:
Keywords: firewall iptables
Licenses: GPL
Submitter: schuay
Maintainer: SanskritFritz
Last Packager: SanskritFritz
Votes: 19
Popularity: 0.745968
First Submitted: 2013-03-15 14:51
Last Updated: 2016-12-25 09:03

Latest Comments

SanskritFritz commented on 2017-01-12 10:46

I don't know how to help you, sorry, it works here.

stenaus commented on 2017-01-12 10:22

Yes. It's there, but still does not work.
For me, the easiest and quickest solution was to replace in firehol binary:
sed -i 's|$PROGRAM_DIR/$functions_file|/usr/lib/firehol/3.1.0/$functions_file|' /usr/bin/firehol

I hope it get fixed for next update.

SanskritFritz commented on 2017-01-12 09:44

Check the PKGBUILD, you should see these lines in package():
rm "$pkgdir/usr/bin/"{vnetbuild,update-ipsets,fireqos,link-balancer,firehol}
ln -s "/usr/lib/firehol/3.1.0/vnetbuild" "$pkgdir/usr/bin/vnetbuild"
ln -s "/usr/lib/firehol/3.1.0/update-ipsets" "$pkgdir/usr/bin/update-ipsets"
ln -s "/usr/lib/firehol/3.1.0/fireqos" "$pkgdir/usr/bin/fireqos"
ln -s "/usr/lib/firehol/3.1.0/link-balancer" "$pkgdir/usr/bin/link-balancer"
ln -s "/usr/lib/firehol/3.1.0/firehol" "$pkgdir/usr/bin/firehol"

stenaus commented on 2017-01-12 09:35

@SanskritFritz Yes, downloaded just yesterday. That's the bug, yes. Using apacman, if that matters.

SanskritFritz commented on 2017-01-12 08:48

@stenaus Are you sure you are using version 2:3.1.0-2? I suspect you've hit this bug:
There is a workaround for this in pkgrel=2.

stenaus commented on 2017-01-12 08:14

Not sure if this is the right place, but does anyone else have a problem with this package?

PROGRAM_DIR points every way to /usr/bin/ which breaks Firehol 3.1.0 startup, because install.config and functions.common files exists in /usr/lib/firehol/3.1.0/ but not in /usr/bin
Also, FIREHOL_OVERRIDE_PROGRAM_DIR does not work (neither in firehol.defaults nor firehol-defaults.conf) because config file is loaded afterwards not in the beginning.

SanskritFritz commented on 2017-01-08 20:19

OK, I'm not good at this stuff, so maybe I'm completely missing the point. I think the hash in the PKGBUILD should be generated at package creation, so the user can be sure he has downloaded the same file the package creator did. Generating the hash on the downloaded file and comparing it to the hash downloaded from the same site is rather pointless in my opinion.

utsi commented on 2017-01-08 10:26

SanskritFritz, just throwing in my 2c,

I think what djmattyg007 is trying to say is that instead of using md5sums in the PKGBUILD, you should use SHA1. Though I would argue that you should use SHA512, but that is another matter of its own.
Of course you would not download the hash from the website, but you would generate it yourself and verify that it matches the website one, though if the tar was compromised so would the hash.

What hash the PKGBUILD uses does not really matter if you would include PGP signature verification of the source, since the MD5 checksum would then be effectively only a checksum for a successful download and PGP would be used for the source integrity check.

And thanks for being the package maintainer :)

SanskritFritz commented on 2017-01-06 12:51

I don't see the point. You download a program and a hash from the same site at the same time and trust the program because there is a hash next to it? Also what would you do with the hash in the PKGBUILD? Can you give me an example?

djmattyg007 commented on 2017-01-06 11:44

The Firehol developers supply a PGP detached signature for verification. This PKGBUILD should include this to ensure the source is verified.

Upstream also supplies SHA-1 hashes, which should be preferred over MD5 hashes.

All comments