No bugs known, a short list of things fixed and changed moving from 0.1.3 to 0.1.4. 0.1.4 was pushed to the Gentoo portage tree, so the user base will grow - not much, I'm sure, since tripwire has a small audience in the first place.
# Fixed twsetup.sh vs. mktwpol.cfg priority bug
# - added (-f) "Force print to STDOUT" switch to mktwpol.sh
# - added (-p) user changeable MKTWPOL_CMD_LINE in twsetup.sh
# -- default is mktwpol.sh -f
# mktwpol.sh: Removed (-v) verbose switch
# (-q) quiet switch no longer stifles progress display
# twsetup.sh: added (-b) bypass plain-text policy text generator
# twsetup.sh catches errors in creating encrypted policy file
# mktwpol.sh tests for /var/db/pkg installed packages database
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Not really a bug, but talk about a "Duh" moment. Got rid of the "Do you want to update tripwire" prompt (which appeared after the policy text was generated), for a user who asserted "-u" on the command line. Of course I want to update the tripwire database, I put "-u" on the command line.
I got rid of the "-q" Quiet switch too. It only "made sense" in the -u mode, and I can't see a situation where a person would want to do that with no output. If that does exist, the user will figure out what and how to redirect to /dev/null.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Long story short, too clever by half. mktwpol.sh has long used "source" to read mktwpol.cfg, and get alternate RULENAME[] arrays, as well as operating preferences. So, come time to make a big splash, I get wrapped up in protecting a few variables from being changed (TW_CFG, mostly), and changed the method of getting stuff out of mktwpol.cfg from "source" to "eval." A week later it dawns on me that this is a security risk, for one thing (not that sourcing isn't), so I start hacking.
I hadn't testing the "eval" method with a mktwpol.cfg file that included a few RULENAME[] assignments, and when I did, well, let's say it was a massive failure.
I figure the bug doesn't affect anybody, because nobody is using the mktwpol.cfg file function - at least not to read in RULENAME[] arrays.
But, I'm going to put out a 0.1.5 soon, so the thing at least works as advertised - like it used to. Also added is a test for permissions 600 on the mktwpol.cfg file. If mktwpol.cfg is in the tripwire config directory, and it's permissions aren't 600, the script dies with a complaint, and describes the cure.
Sorry for all flurry of garbage.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
No bugs known, a short list of things fixed and changed moving from 0.1.3 to 0.1.4. 0.1.4 was pushed to the Gentoo portage tree, so the user base will grow - not much, I'm sure, since tripwire has a small audience in the first place.
# Fixed twsetup.sh vs. mktwpol.cfg priority bug
# - added (-f) "Force print to STDOUT" switch to mktwpol.sh
# - added (-p) user changeable MKTWPOL_CMD_LINE in twsetup.sh
# -- default is
mktwpol.sh -f# mktwpol.sh: Removed (-v) verbose switch
# (-q) quiet switch no longer stifles progress display
# twsetup.sh: added (-b) bypass plain-text policy text generator
# twsetup.sh catches errors in creating encrypted policy file
# mktwpol.sh tests for /var/db/pkg installed packages database
Not really a bug, but talk about a "Duh" moment. Got rid of the "Do you want to update tripwire" prompt (which appeared after the policy text was generated), for a user who asserted "-u" on the command line. Of course I want to update the tripwire database, I put "-u" on the command line.
I got rid of the "-q" Quiet switch too. It only "made sense" in the -u mode, and I can't see a situation where a person would want to do that with no output. If that does exist, the user will figure out what and how to redirect to /dev/null.
Long story short, too clever by half. mktwpol.sh has long used "source" to read mktwpol.cfg, and get alternate RULENAME[] arrays, as well as operating preferences. So, come time to make a big splash, I get wrapped up in protecting a few variables from being changed (TW_CFG, mostly), and changed the method of getting stuff out of mktwpol.cfg from "source" to "eval." A week later it dawns on me that this is a security risk, for one thing (not that sourcing isn't), so I start hacking.
I hadn't testing the "eval" method with a mktwpol.cfg file that included a few RULENAME[] assignments, and when I did, well, let's say it was a massive failure.
I figure the bug doesn't affect anybody, because nobody is using the mktwpol.cfg file function - at least not to read in RULENAME[] arrays.
But, I'm going to put out a 0.1.5 soon, so the thing at least works as advertised - like it used to. Also added is a test for permissions 600 on the mktwpol.cfg file. If mktwpol.cfg is in the tripwire config directory, and it's permissions aren't 600, the script dies with a complaint, and describes the cure.
Sorry for all flurry of garbage.