cipherdyne.org

Michael Rash, Security Researcher



Software Releases    [Summary View]

« Previous | Next »

Software Release - fwsnort-1.6.2

fwsnort-1.6.2 released The 1.6.2 release of fwsnort is available for download. The most impactful change in this release is a switch to how fwsnort loads translated rules into the running iptables policy. Instead of attempting to parse the local policy and only add those rules in that appear to match protocols that the policy allows, fwsnort now loads all translated rules by default. The reasoning for this change is in the ChangeLog below. There are a few bug fixes and updates to get fwsnort working without warnings on recent versions of perl as well as an ICMP type fix for recent versions of iptables. As usual, please let me know if there are any issues.

Here is the complete fwsnort-1.6.2 ChangeLog:

  • Switched --no-ipt-sync to default to not syncing with the iptables policy. By default fwsnort attempts to match translated Snort rules to the running iptables policy, but this is tough to do well because iptables policies can be complex. And, before fwsnort switched to the iptables-save format for instantiating the policy, a large set of translated rules could take a really long time to make active within the kernel. Finally, many Snort rules restrict themselves to established TCP connections anyway, and if a restrictive policy doesn't allow connections to get into the established state for some port let's say, then there is little harm in having translated Snort rules for this port. Some kernel memory would be wasted (small), but no performance would be lost since packets won't be processed against these rules anyway. The end result is that the default behavior is now to not sync with the local iptables policy in favor of translating and instantiating as many rules as possible.
  • Replaced Net::IPv4Addr with the excellent NetAddr::IP module which has comprehensive support for IPv6 address network parsing and comparisons.
  • Moved the fwsnort.sh script and associated files into the /var/lib/fwsnort/ directory. This was suggested by Peter Vrabec.
  • Bug fix for recent versions of iptables (such as 1.4.12) where the icmp match requires --icmp-type to be set - some Snort rules look for a string to match in icmp traffic, but don't also specify an icmp type.
  • Bug fix for 'qw(...) usage as parenthesis' warnings for perl > 5.14
  • Removed the ExtUtils::MakeMaker RPM build requirement from the fwsnort.spec file. This is a compromise which will allow the fwsnort RPM to be built even if RPM doesn't or can't see that ExtUtils::MakeMaker is installed - most likely it will build anyway. If it doesn't, there are bigger problems since fwsnort is written in perl. If you want to build the fwsnort RPM with a .spec file that requires ExtUtils::MakeMaker, then use the "fwsnort-require-makemaker.spec" file that is bundled in the fwsnort sources.

Software Release - psad-2.2

psad-2.2 released After a long development cycle, the 2.2 release of psad is available for download. This release adds major new functionality for the detection of malicious traffic that is delivered over IPv6 by parsing ip6tables logs. A significant portion of this capability is enabled by the excellent NetAddr::IP CPAN module that can properly handle IPv6 addresses. In addition, speed optimizations have been made that result in psad-2.2 being about 15% faster than previous releases, several bugs have been fixed (including one that caused compile time warnings on recent versions of perl), and a comprehensive test suite has been added. psad-2.2 is a stepping stone to the upcoming psad-3.0 release that will include support for both PF and ipfw firewalls running on *BSD systems. Quite a bit of this work has already been done in the openbsd_integration branch.

Here is an excerpt of the psad-2.2 ChangeLog:

  • Added support for detection of malicious traffic that is delivered via IPv6. This is accomplished by parsing ip6tables log messages - these are in a slightly different format than the iptables log messages. Here is an example:

    Mar 17 13:39:13 linux kernel: [956932.483644] DROP IN=eth0 OUT= MAC=00:13:46:3a:41:36:00:1b:b9:76:9c:e4:86:dd SRC=2001:0db8:0000:f101:0000:0000:0000:0002 DST=2001:0db8:0000:f101:0000:0000:0000:0001 LEN=80 TC=0 HOPLIMIT=64 FLOWLBL=0 PROTO=TCP SPT=50326 DPT=993 WINDOW=5760 RES=0x00 SYN URGP=0

    Detection of malicious IPv6 traffic can be disabled via a new ENABLE_IPV6_DETECTION config variable.
  • For ICMP6 traffic, added protocol validation for ICMP6 type/code combinations.
  • Added a new test suite in the test/ directory to validate psad run time operations (scan detection, signature matching, and more). To support this, a new '--install-test-dir' option was added to the install.pl script. Once this is executed, the test suite can be run via the test-psad.pl script in the test/ directory.
  • Added a new MAX_SCAN_IP_PAIRS config variable to allow psad memory usage to be constrained by restricting the number of unique IP pairs that psad This is useful for when psad is deployed on systems with little memory, and is best utilized in conjunction with disabling ENABLE_PERSISTENCE so that old scans will also be deleted (and thereby making room for tracking new scans under the MAX_SCAN_IP_PAIRS threshold).
  • Bug fix for 'qw(...) usage as parenthesis' warnings for perl > 5.14
  • Bug fix that caused psad to emit the following:

    Undefined subroutine &main::LOG_DAEMON called at ./psad line 10071.

    This problem was noticed by Robert and reported on the psad mailing list.
  • Bug fix for ICMP packet handling where psad would incorrectly interpret ICMP port unreachable messages as UDP packets because the UDP specifics are included in the iptables log message. This bug was first reported by Lukas Baxa to the Debian maintainers and was followed up by Franck Joncourt: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=596240 An example ICMP log message that exposed the bug is included below:

    Sep 8 18:04:26 baxic kernel: [28241.572876] IN_DROP IN=wlan0 OUT= MAC=00:1a:9f:91:df:ae:00:21:27:e8:0a:a0:08:00 SRC=10.0.0.138 DST=192.168.1.103 LEN=96 TOS=0x00 PREC=0xC0 TTL=254 ID=63642 PROTO=ICMP TYPE=3 CODE=3 [SRC=192.168.1.103 DST=10.0.0.138 LEN=68 TOS=0x00 PREC=0x00 TTL=0 ID=22458 PROTO=UDP SPT=35080 DPT=33434 LEN=48 ]
The complete psad-2.2 ChangeLog can be found here via the psad gitweb interface.

Software Release - fwknop-2.0

fwknop-2.0 released After a long development cycle, fwknop-2.0 has been released. This is the first production release of the fully re-written C version of fwknop, and is the culmination of an effort to provide Single Packet Authorization to multiple open source firewalls, embedded systems, mobile devices, and more. On the "server" side, supported firewalls now include iptables on Linux, ipfw on FreeBSD and Mac OS X, and pf on OpenBSD. The fwknop client is known to run on all of these platforms, and also functions on Windows systems running under Cygwin. There is also an Android client, and a good start on a iPhone client as well. On a personal note, I wish to thank Damien Stuart for a heroic effort to port most of the original perl code over to C. Also, several other people have made significant contributions including Jonathan Bennet, Max Kastanas, Sebastien Jeanquier, Ozmart, and others. If there are any issues, please get in touch with me directly or send an email to the fwknop mailing list.

Update 01/03: Both libfko library that powers much of fwknop operations and the fwknop client can be compiled as native Windows executables. In addition, there are perl and python bindings to libfko as well.

Update 01/07: Damien Stuart has built RPM files for fwknop on RHEL5, RHEL6, Fedora 15, 16, and 17 and for other architectures the Fedora koji build system can produce.

Software Release - fwknop-2.0rc5

fwknop-2.0rc5 released The 2.0rc5 candidate release of fwknop is available for download. There may be a few tweaks to the code before the official 2.0 release is made, but this is pretty close as-is. Significant development work has gone into fwknop since the 2.0rc4 release, and adds some major new functionality as well as fixing a few bugs. Here is a summary of the changes:

iPhone fwknop client: Max Kastanas has contributed an iPhone port of the fwknop client. He had already contributed on Android client, so the iPhone was the next natural step! We're looking for a maintainer of the iPhone code so that eventually it can be made available through the App Store. If you have iPhone development experience and are interested in taking this on, please contact me.

PF firewall support on OpenBSD: For quite a while now fwknop has brought Single Packet Authorization support to iptables firewalls on Linux and ipfw firewalls on FreeBSD and Mac OS X systems. The 2.0rc5 release now introduces support for the PF firewall on OpenBSD systems. By interfacing with the pfctl command, fwknop creates new rules to access a protected service (such as SSHD) to a PF anchor. Rules are deleted out of a running anchor with pfctl -a <anchor> -f - with the expired rule(s) removed. There is support in the fwknop test suite (see the test/ directory in the fwknop-2.0rc5 sources) to validate fwknop operations on OpenBSD systems, and if there are any issues please let me know.

Expiring SPA keys: With large SPA deployments where many different encryption keys - either Rijndael or GPG keys - are used to service lots of external users, key management can become somewhat of a burden. This feature allows an expiration date to be set in the access.conf file on a per-key basis. Any SPA packet received for an expired key is ignored by fwknopd. This feature was suggested by ozmart from the fwknop mailing list.

FORCE_NAT mode: For iptables firewalls, a new FORCE_NAT mode has been implemented that works as follows: for any valid SPA packet, force the requested connection to be NAT'd through to the specified (usually internal) IP and port value. This is useful if there are multiple internal systems running a service such as SSHD, and you want to give transparent access to only one internal system for each stanza in the access.conf file. This way, multiple external users can each directly access only one internal system per SPA key.

lsof launcher: The fwknop lsof launcher (extras/fwknop-launcher/fwknop-launcher-lsof.pl) is a lightweight daemon that allows the user to not have to manually run the fwknop client when attempting to gain access to a service that is protected by via fwknopd. This is accomplished by checking the output of lsof to look for pending connections in the SYN_SENT state, which (usually) indicate that a remote firewall is blocking the attempted connection. At this point, the launcher executes the fwknop client with the --get-key arg (so the user must place the key in the local filesystem) to generate an SPA packet for the attempted connection. The remote fwknopd daemon will reconfigure the firewall to allow temporary access, and this usually happens fast enough that the original connection attempt will then succeed as TCP retries to establish the connection. The idea for this was originally for a pcap-based connection watcher by Sebastien Jeanquier.

Several other changes and small fixes have been made as well. The fwknop test suite supports running all tests through the excellent valgrind project, and this enabled several memory handling issues to be found and corrected.

fwknop is released under the GPL version 2, and the complete fwknop-2.0rc5 ChangeLog can be found here via the fwknop gitweb interface.

Software Release - fwsnort-1.6

fwsnort-1.6 released The 1.6 release of fwsnort is available for download. This is a fairly significant release that adds support for the Snort fast_pattern keyword, makes enhancements to the --QUEUE and --NFQUEUE modes, supports the conntrack module for connection tracking, adds support for case-insensitive pattern matches using the --icase argument to the iptables string match extension, and several other things. The Snort fast_pattern keyword allows the rule author to influence the order in which Snort tries to match a pattern against network traffic. When multiple patterns are included in a rule, Snort usually tries to match the longest pattern first reasoning that the longest pattern is probably the least likely to trigger a match and therefore the remaining pattern searches would not have to be performed. But, there are times when the rule author would like to explicitly ask Snort to match on a particular pattern first, and the fast_pattern keyword is the mechanism that makes this possible. Because iptables matches are evaluated in order and a failing match short circuits a rule, fast_pattern support with the string match extension is possible through proper ordering in the iptables rule. Here is an example Snort rule from Emerging Threats with the fast_pattern keyword applied to the forth pattern: alert tcp $EXTERNAL_NET $HTTP_PORTS -> $HOME_NET any (msg:"ET WEB_CLIENT Possible Internet Explorer srcElement Memory Corruption Attempt"; flow:established,to_client; file_data; content:"document.createEventObject"; distance:0; nocase; content:".innerHTML"; within:100; nocase; content:"window.setInterval"; distance:0; nocase; content:"srcElement"; fast_pattern; nocase; distance:0; classtype:attempted-user; reference:url,www.microsoft.com/technet/security/bulletin/ms10-002.mspx; reference:url,tools.cisco.com/security/center/viewAlert.x?alertId=19726; reference:url,www.kb.cert.org/vuls/id/492515; reference:cve,2010-0249; reference:url,doc.emergingthreats.net/2010799; reference:url,www.emergingthreats.net/cgi-bin/cvsweb.cgi/sigs/CURRENT_EVENTS/CURRENT_MSIE; sid:2010799; rev:5;) fwsnort translates this rule as follows in iptables-save format from the /etc/fwsnort/fwsnort.save file - the original iptables commands in non-save format are also available in the /etc/fwsnort/fwsnort_iptcmd.sh script: -A FWSNORT_FORWARD_ESTAB -p tcp -m tcp --sport 80 -m string --string "srcElement" --algo bm --from 82 --icase -m string --string "document.createEventObject" --algo bm --from 64 --icase -m string --string ".innerHTML" --algo bm --to 190 --icase -m string --string "window.setInterval" --algo bm --from 74 --icase -m comment --comment "sid:2010799; msg:ET WEB_CLIENT Possible Internet Explorer srcElement Memory Corruption Attempt; classtype:attempted-user; reference:url,www.microsoft.com/technet/security/bulletin/ms10-002.mspx; rev:5; FWS:1.6;" -j LOG --log-ip-options --log-tcp-options --log-prefix "SID2010799 ESTAB " Note that the srcElement string is matched first in the iptables rule even though it is the last string in the original Snort rule. With fast_pattern support, fwsnort policies should be a bit faster at run time in the in the Linux kernel. On a final note, the iptables multiport match is also supported with the fwsnort-1.6 release, so Snort rules with lists of source or destination ports (like this: "alert tcp $HOME_NET [0:20,22:24,26:138,140:444,446:464,466:586,588:901,903:1432,1434:65535] -> any any") can be translated.

The complete fwsnort-1.6 ChangeLog can be found here via the fwsnort gitweb interface.

Software Release - fwsnort-1.5

fwsnort-1.5 released The 1.5 release of fwsnort is available for download. This is a major release that moves to using the iptables-save format for instantiating the fwsnort policy, and this allows the run time for adding the fwsnort policy to the kernel to be drastically reduced. fwsnort now splices in the translated Snort rules into the iptables policy in the running kernel at the time of translation. So, any updates to the iptables policy that are made after fwsnort is executed and before fwsnort.sh is run would be lost. Hence, it is advisable to execute fwsnort.sh soon after running fwsnort. This is a reasonable tradeoff though considering the performance benefit as seen below - which gives an example of how long it takes to add an fwsnort iptables policy via the old strategy of executing one iptables command at a time vs. implementing the same policy with iptables-restore. First, fwsnort is used to translate the Snort web-misc.rules, web-cgi.rules, backdoor.rules files like so: [root@minastirith /etc/fwsnort]# fwsnort --snort-rfile web-misc.rules,web-cgi.rules,backdoor.rules --no-ipt-sync

[+] Generated iptables rules for 713 out of 754 signatures: 94.56%

[+] Logfile: /var/log/fwsnort/fwsnort.log
[+] iptables script (individual commands): /etc/fwsnort/fwsnort_iptcmds.sh

Main fwsnort iptables-save file: /etc/fwsnort/fwsnort.save

You can instantiate the fwsnort policy with the following command:

/sbin/iptables-restore < /etc/fwsnort/fwsnort.save

Or just execute: /etc/fwsnort/fwsnort.sh
The output above illustrates the changes for the fwsnort-1.5 release. All of the previous behavior in fwsnort has been preserved in the /etc/fwsnort/fwsnort_iptcmds.sh script. That is, each individual iptables command to add every fwsnort rule one by one is implemented in this script - this is analogous to how the fwsnort.sh script was built by older versions of fwsnort. But, with the 1.5 release the fwsnort.sh script now just executes the iptables-restore command against the new fwsnort.save file.

If we execute the fwsnort_iptcmds.sh script and time its execution, we get the following on my desktop system: [root@minastirith /etc/fwsnort]# time /etc/fwsnort/fwsnort_iptcmds.sh
[+] Adding backdoor rules:
Rules added: 122
[+] Adding web-cgi rules:
Rules added: 696
[+] Adding web-misc rules:
Rules added: 600
[+] Finished.

real 0m24.391s
user 0m1.560s
sys 0m11.500s
[root@minastirith /etc/fwsnort]# iptables -v -nL |wc -l
1509
So, the fwsnort policy together with the running iptables policy is about 1500 rules long, and it took over 24 seconds to add to the running kernel. Now, let's time the fwsnort.sh script instead (which is just a wrapper around the iptables-restore command): [root@minastirith /etc/fwsnort]# time /etc/fwsnort/fwsnort.sh

[+] Splicing fwsnort rules into the iptables policy...
Done.


real 0m0.121s
user 0m0.060s
sys 0m0.040s
[root@minastirith /etc/fwsnort]# iptables -v -nL |wc -l
1509
Ok, over 24 seconds to instantiate the fwsnort policy for the old strategy, and about a 10th of a second for the new strategy for a speed up of 240 times! This gets even better for an fwsnort policy with thousands of rules. Note that the number of iptables rules is the same between the two executions.

The complete ChangeLog entries are displayed below:

  • Major update to use the iptables-save format instead of the older strategy of always just executing iptables commands directly (which was very flow for large fwsnort policies). The /etc/fwsnort/fwsnort.sh script now just executes:

    /sbin/iptables-restore < /etc/fwsnort/fwsnort.save

    All fwsnort rules are now placed in the /etc/fwsnort/fwsnort.save file, but the older fwsnort.sh output (for the individual commands version) is still available at /etc/fwsnort/fwsnort_iptcmds.sh. This functionality extends to ip6tables policies as well. The fwsnort man page explain this in better detail:

    "As of fwsnort-1.5 all iptables rules built by fwsnort are written out to the /etc/fwsnort/fwsnort.save file in iptables-save format. This allows a long fwsnort policy (which may contain thousands of iptables rules translated from a large Snort signature set) to be quickly instantiated via the "iptables-restore" command. A wrapper script /etc/fwsnort/fwsnort.sh is also written out to make this easy. Hence, the typical work flow for fwsnort is to: 1) run fwsnort, 2) note the Snort rules that fwsnort was able to successfully translate (the number of such rules is printed to stdout), and then 3) execute the /etc/fwsnort/fwsnort.sh wrapper script to instantiate the policy in the running kernel."
  • Added the --rules-url argument so that the URL for updating the Emerging Threats rule set can be specified from the command line. The default is:

    http://rules.emergingthreats.net/open/snort-2.9.0/emerging-all.rules
  • Updated to automatically check for the maximum length string that the string match supports, and this is used to through out any Snort rules with content matches longer than this length.
  • Updated the iptables capabilities testing routines to add and delete testing rules to/from the custom chain 'FWS_CAP_TEST'. This maintains a a cleaner separation between fwsnort and any existing iptables policy even during the capabilities testing phase.
  • Added the --ipt-check-capabilities argument to have fwsnort test the capabilities of the local iptables firewall and exit.
  • Added the --string-match-alg argument to allow the string matching algorithm used by fwsnort to be specified from the command line. The default algorithm is 'bm' for 'Boyer-Moore', but 'kmp' may also be specified (short for the 'Knuth-Morris-Pratt' algorithm).
  • Updated to the latest complete rule set from Emerging Threats (see http://www.emergingthreats.net/).

Software Release - psad-2.1.7

psad-2.1.7 released The 2.1.7 release of psad is available for download. This release adds some relatively minor functionality to switch whois lookups to the destination IP whenever the source IP is part of a directly connected subnet. This change gives better reporting data in normal psad email alerts. The complete ChangeLog entries are displayed below. The psad-2.1.6 release was also made a few days ago, and fixes a bug that caused psad to die on some Ubuntu systems when using the Date::Calc Decode_Month() function, and it also added the --Override-config feature so that alternate configuration variables can be specified via config files besides psad.conf (implemented by Franck Joncourt).

  • (Dan A. Dickey) Added the ability to use the "ip" command from the iproute2 tools to acquire IP addresses from local interfaces. Dan's description is as follows: "...A main reason for doing this is in the case of multi-homed hosts. ifconfig sets these up on an interface using aliases, iproute2 does not. So, for a multi-homed interface (eth0 with multiple addresses), ifconfig -a only shows the first one configured and not the rest. ip addr shows all of the configured addresses...".
  • Added ENABLE_WHOIS_FORCE_ASCII to replace any non-ascii characters in whois data (which is common with whois lookups against Chinese IP addresses for example) with the string "NA". This option is disabled by default, but can be useful if errors like the following are seen upon receiving an email alert from psad:

    <<< 554 5.6.1 Eight bit data not allowed
    554 5.0.0 Service unavailable

  • Updated psad to issue whois lookups against IP addresses that are not directly connected to the local system. This is useful for example when an internal system is scanning an external destination system, and the scan is logged in the FORWARD chain. Issuing whois lookups on the internal system (frequently on RFC 1918 address space) is not usually very useful, but issuing the whois lookup against the destination system gives much more interesting data. This feature can be disabled with the new ENABLE_WHOIS_FORCE_SRC_IP variable.

Software Release - fwsnort-1.1

software release fwsnort-1.1 The 1.1 release of fwsnort is ready for download. This is a significant release that adds support for ip6tables so that SNORT ® inspection logic can be applied to IPv6 traffic within the Linux kernel. This release also includes a new feature that allows fwsnort to build perl commands interfaced with netcat that generate packet data that matches Snort rules (for those that that can be faithfully translated - see the --include-perl-triggers command line argument and associated comments within the fwsnort.sh file).

Here is the complete fwsnort-1.1 ChangeLog:

  • Added the ability to build an fwsnort policy that utilizes ip6tables instead of iptables. This allows fwsnort filtering and altering capabilities to apply to IPv6 traffic instead of just IPv4 traffic. To enable ip6tables usage, use the "-6" or "--ip6tables" command line arguments.
  • Added the --include-perl-triggers command line argument so that translated Snort rules can easily be tested. This argument instructs fwsnort to include 'perl -e print ... ' commands as comments in the /etc/fwsnort/fwsnort.sh script, and these commands can be combined with netcat to send payloads across the wire that match Snort rules.
  • Updated fwsnort to create logs in the /var/log/fwsnort/ directory instead of directly in the /var/log/ directory. The path is controlled by a new variable 'LOG_FILE' in the /etc/fwsnort/fwsnort.conf file.
  • Added several variables in /etc/fwsnort/fwsnort.conf to control paths to everything from the config file to the snort rules path. Coupled with this is the ability to create variables within path components and fwsnort will expand them (e.g. 'CONF_DIR /etc/fwsnort; CONF_FILE $CONF_DIR/fwsnort.conf').
  • Added --Last-cmd arg so that it is easy to rebuild the fwsnort.sh script with the same command line args as the previous execution.
Snort is a registered trademark of Sourcefire, Inc.

Software Release - fwknop-1.9.12

software release fwknop-1.9.12 The 1.9.12 release of fwknop is ready for download. This is a significant release that moves by default to the new libfko and the new FKO module for SPA encryption and decryption. Other new features include interface monitoring for the fwknopd daemon so it can survive administrative changes due to things like a DHCP address changes, and the ability to send SPA packets through HTTP proxies.

An excerpt from the 1.9.12 ChangeLog appears below:

  • Fully integrated the FKO module that is part of the libfko library for all SPA routines - encryption/decryption, digest calculation, replay attack detection, etc. The default is to always use the FKO module if it has been installed, but the original perl code remains intact as well just in case FKO does not exist on the local system. The libfko code can be viewed with Trac here
  • Added the ability to recover from interface error conditions, such as when fwknopd sniffs a ppp interface (say, associated with a VPN) that goes away and then is recreated. In previous versions of fwknop, this would result in the fwknopd daemon no longer able to receive SPA packets. This new functionality is controlled by five new configuration variables in the fwknop.conf file: ENABLE_INTF_CHECKS, INTF_CHECKS_INTERVAL, ENABLE_INTF_EXISTS_CHECK, ENABLE_INTF_RUNNING_CHECK, and ENABLE_INTF_BYTES_CHECK. By default, all of these checks are enabled and are run every 20 seconds by the knoptm daemon. If any check fails, then knoptm stops the fwknopd daemon once the error condition is corrected (such as when the interface comes back) so that knopwatchd will then restart it. The fwknopd daemon cannot receive packet data until the error condition is cleared (most likely except perhaps for the "RUNNING" check, but restarting the fwknopd daemon is better than not being able to access a service).
  • Updated the fwknop client to include the SPA destination before DNS resolution when sending an SPA packet over an HTTP request. This allows more flexible Apache configurations with virtual web hosts to function properly with HTTP requests that contain SPA packet data. Also updated the fwknop client to include a leading "/" in SPA packets over HTTP, and updated the fwknopd server to strip this out before attempting SPA packet decryption.
  • Updated the fwknop client to resolve external IP addresses (with the -R argument) here by default.
  • (Jonathan Bennett): Submitted patch to the fwknop client to add HTTP proxy support when sending SPA packets over HTTP. The result is a new --HTTP-proxy option that expects the proxy host to be given as "http://HOST", and it also supports the "http://HOST:PORT" notation as well.

Software Release - gpgdir-1.9.5

software release gpgdir-1.9.5 The 1.9.5 release of gpgdir is ready for download. This release adds support for decrypting files that have been encrypted with PGP (so they have the .pgp file extension). This feature was essentially implemented for free in gpgdir because GnuPG along with the GnuPG::Interface perl module can decrypt PGP-encrypted files. Here is an example: $ cd dir
$ find . -type f
./file0.pgp
./file5.pgp
./subdir2/file8.pgp
./subdir2/file7.pgp
./subdir1/file6.pgp
./file4.pgp
./file3.pgp
./file2.pgp
./file1.pgp
$ gpgdir -d .
[+] Executing: gpgdir -d .
Using GnuPG key: ABCD1234
Password:

[+] Decrypting files in directory: /home/mbr/tmp/dir
[+] Building file list...
[+] Decrypting: /home/mbr/tmp/dir/file3.pgp
[+] Decrypting: /home/mbr/tmp/dir/subdir2/file8.pgp
[+] Decrypting: /home/mbr/tmp/dir/subdir2/file7.pgp
[+] Decrypting: /home/mbr/tmp/dir/subdir1/file6.pgp
[+] Decrypting: /home/mbr/tmp/dir/file1.pgp
[+] Decrypting: /home/mbr/tmp/dir/file2.pgp
[+] Decrypting: /home/mbr/tmp/dir/file5.pgp
[+] Decrypting: /home/mbr/tmp/dir/file4.pgp
[+] Decrypting: /home/mbr/tmp/dir/file0.pgp

[+] Total number of files decrypted: 9

$ !find
find . -type f
./file4
./file3
./file5
./subdir2/file8
./subdir2/file7
./subdir1/file6
./file1
./file2
./file0
« Previous | Next »