Hello,

thanks for notifying us. We will need your help to fix properly those issues. Let me explain both problems...

For py2-ipaddress, there are two different backports of the Python 3.3+ ipaddress module. There's the one you picked and the one which is packaged in Debian/Kali: https://pypi.python.org/pypi/ipaddress/1.0.16

Both provide the same ipaddress module and they can't be co-installed. Thus it would be nice if you could use the version packaged in Debian (which is also the most popular on pypi and in general). I was hoping they would be compatible as they are supposed to be a backport of the same API but apparently they are not. Can you switch to "ipaddress" ?

Now there's the question of pytz. The version in Debian does not contain the zoneinfo file but it has been patched to use the zoneinfo files provided by the tzdata package (aka /usr/share/zoneinfo). If you use the pytz API properly, things should work... but you are relying on the fact there's a zoneinfo directory near the pytz/tzfile.py and this is a bad assumption to make

Can you fix your code to not make this assumption ?

I tried hardcoding zoneinfo_path in king_phisher/ics.py to /usr/share/zoneinfo to see if it helps but I still get failures related to timezone handling.

I think you should find a way to not need to parse the zoneinfo file yourself.

Let me know your thoughts.

For the postgresql support, let's discuss this once we have fixed the above issues.

So to follow up with this we've implemented changes to support your preferred ipaddress module and they have been submitted in a pull request (PR#67) which is currently waiting to be reviewed and tested.

As for the pytz issues, the files have to be accessed because the necessary information is not exposed via the pytz API. King Phisher needs to be able to extract the duration information for Day Light Savings time for different regions and in order to do that the files have to be processed manually. While implementing the feature which required this we were unable to identify a suitable Python module that provided this information. Commit e0ee0aa6ab however adds support for identifying zonefiles stored in /usr/share as a compromise.

I see the required fixes have landed in the "dev" branch. Can we safely do a new snapshot release based on dev? Or shall we rather wait the next official release?

Or do you want to provide us the minimal patches to use (or list of commits to cherry-pick) on top of the current 1.1.0 release?

We're finalizing our testing today and will be merging dev into master by the end of the day tomorrow. If possible I'd prefer to do a snapshot release based on master after that has occurred. I think that would be the easiest solution for everyone.

We finished our testing yesterday and these changes have been merged into the master branch. When ever you have the opportunity you should be good to proceed to make a snapshot release.

The only other problem we noticed and wanted to mention was that the python-gi-cairo package was missing. A separate ticket was opened for it, ID 0003054.

king-phisher 1.1.0+git20160222-0kali2 solves the problems with pytz and ipaddress (and adds the missing dependency on python-gi-cairo). The test suite is running (and passing) during the build...

Now there's the postgresql setup which is left. By default postgresql does not run on Kali and so it's difficult to do the required setup at package installation time.

We can however possibly modify king-phisher.service to add "Requires=postgresql.service" (or "Wants=postgresql.service" to make it non-fatal) and to run a script via "ExecStartPre" that would read the database configuration from the king-phisher configuration file and that would create the required user and database if they are missing.

This is something that could be integrated on your side (i.e. upstream). What do you think of this idea?

I've been looking into the postgresql support issues. What you're describing sounds like it would work. I could handle creating the database and adding the database user automatically.

The only question I have before I add this in is would it be possible for the installer to generate the connection string and place it into the server configuration file? This would also need to generate a random password. The problem I'm trying to avoid is determining when postgresql should be setup with a new user and database versus just using sqlite as it's currently configured to.

The included installation script handles the creation of the connection string in these 5 lines: https://github.com/securestate/king-phisher/blob/master/tools/install.sh#L353-L357

It's fine if you want to modify setup.sh to setup the postgresql connection string by default. We don't use it but we can replicate something similar in the postinst script (with debconf).

But the CREATE USER / CREATE DATABASE should really happen at runtime in the PreExec script like I said so that we have a way to ensure that PostgreSQL is running. You could protect all this with a check on the existence of the database...

if ! su - postgres -c "psql -l" | grep -q '^king_phisher$'; then
su postgres -c "psql -c \"CREATE USER king_phisher WITH PASSWORD '$PG_KP_PASSWORD';\"" &> /dev/null
su postgres -c "psql -c \"CREATE DATABASE king_phisher OWNER king_phisher;\"" &> /dev/null
fi

BTW I did not test my check, I think I miss some options to control the output of "psql -l" but you get the idea.

I was planning on having the server check the status of postgresql using systemctl (or upstart depending on whats available) and starting the service if it's not already running. That way the logic can be kept within Python, eliminating the need to parse the configuration file to obtain the user database name and password. It can do that while it's still running as root before it drops its privileges.

Additionally this way if the user explicitly switches back to sqlite in their configuration file the postgresql service won't be started unnecessarily .

Would that be acceptable?

Sure, but then you must do the CREATE USER and CREATE DATABASE from python too.

These changes are in the master branch now. Given only the connection string, the server will now try harder to start the PostgreSQL service via systemd and create the user and database if necessary as well.

Thanks for your patience on this.

A new version 1.2.0+git20160510-0kali1 will be in kali-rolling in few hours, (using postgresql)