Free tiger software for linux

Tiger JMail is a direct replacement for Suns javamail, but with an LGPL license and fewer bugs. TJ works with both the Kaffe and Sun JVMs.
Tiger JMail is tested, maintained, and in active use. TJ works well, but theres lots of room for improvement.
Installation:
To install, just put the distribution jar file in your classpath. You can rename it to javamail.jar if you like.
Because Suns JVM uses its own javamail by default, to use Tiger JMail add this to your command line:
-Xbootclasspath/p:javamail.jar
Use the full pathname to TJs jar in place of "javamail.jar". With the Kaffe JVM just put TJ in the classpath as usual.
The jar file also contains source and docs. Source files are in the same directories as the executable class files. An open source replacement for Suns Java Activation Framework is also included.
If you want to rebuild from source, rename the jar to .zip and extract the files into a fresh directory. At a command prompt in that directory type
ant clean
ant build
See the documentation for java.mail.Session for details on TJs logging support. To generate javadocs, use
ant api
TJ is a fork of the last LGPL version of the classpathx mail project, plus critical bug fixes and enhancements. See the file docs/mail/whyforked for details. Thanks to the classpathx people for the enormous amount of work they contributed.
Enhancements:
- Fixed several bugs found by FindBugs.
- In SMTPTransport included multiline responses in last server response.
- In SMTPTransport after sending "DATA" wait for 354 response or error.
- In gnu.mail.util.UUDecoderStream.read(bytes) detected end-of-stream.
- In SMTPTransport.readServerResponse() catch server not responding.
- In Session.setDebugOut guarded against setting to null.
- Added messages to several ParseExceptions.
- In ParameterList allowed a final ; with no following AV pairs.
- In ContentType just logged bad parameter list.
- In UU[En|De]coderStream handled grave accent in place of space.
- In Application.java.getContent fixed infinite loop.
- In javax.mail.internet.MimeMessage.setContent added setHeader call.
- Added UUEncoderStream.closePart() to write suffix without closing.
- In javamail javax.mail.Session set default debugging values.
- Added Session.logException().
- Handled blank encoding in MimePartDataSource.getInputStream.
- Cleaned up java.mail.internet.InternetHeaders and handled null/blank values.
- Added timestamp and threadstamp to Session.logException.
- In MimeMessage and MimeBodyPart moved removeHeader() calls from setDataHandler() to setContent().
- In Base64InputStream fixed off-by-one and checked for invalid chars.
- Replaced old base64 code with bouncycastles.
- Removed duplicate trailing "
" in SMTPTransport.finishData().
- Added gnu.mail.util.EmbeddedFilter[In|Out]putStream and used them.
- In javax.activation.DataHandler.writeTo() added flush.
- In MimeUtility.encodeWord ascii check used getBytes(s, charset).
- In DataHandler.getInputStream() fixed deadlock.
- In MailcapCommandMap folded case for mime types.
- Changed calls fro Throwable.printStackTrace to Session.logException.
- In QPInputStream and QPOutputStream fixed MS Exchange quoted-printable and other bugs.

Geo::TigerLine::Record::B is a TIGER/Line 2003 Polygon Geographic Entity Codes: Corrections.

SYNOPSIS

use Geo::TigerLine::Record::B;

@records = Geo::TigerLine::Record::B->parse_file($fh);
@records = Geo::TigerLine::Record::B->parse_file($fh, &callback);

$record = Geo::TigerLine::Record::B->new(%fields);

$record->rt();
$record->version();
$record->file();
$record->cenid();
$record->polyid();
$record->statecq();
$record->countycq();
$record->tractcq();
$record->blockcq();
$record->aianhhfpcq();
$record->aianhhcq();
$record->aihhtlicq();
$record->aitscecq();
$record->aitscq();
$record->anrccq();
$record->concitcq();
$record->cousubcq();
$record->submcdcq();
$record->placecq();
$record->uacc();
$record->urcc();
$record->rs_b1();

This is a class representing record type B of the TIGER/Line 2003 census geographic database. Each object is one record. It also contains methods to parse TIGER/Line record type B files and turn them into objects.

This is intended as an intermediate format between pulling the raw data out of the simplistic TIGER/Line data files into something more sophisticated (a process you should only have to do once). As such, its not very fast, but its careful, easy to use and performs some verifications on the data being read.

As this class is autogenerated by mk_parsers, think before you modify this file. Its OO, so consider sub-classing instead.

Bastille Hardening program "locks down" an operating system, proactively configuring the system for increased security and decreasing its susceptibility to compromise. Bastille project can also assess a systems current state of granularly, hardening reporting on each of the security settings with which it works.
Bastille currently supports the Red Hat (Fedora Core, Enterprise, and Numbered/Classic), SUSE, Debian, Gentoo, and Mandrake distributions, along with HP-UX and Mac OS X. Bastilles focuses on letting the systems user/administrator choose exactly how to harden the operating system.
In its default hardening mode, it interactively asks the user questions, explains the topics of those questions, and builds a policy based on the users answers. It then applies the policy to the system. In its assessment mode, it builds a report intended to teach the user about available security settings as well as inform the user as to which settings have been tightened.
Why use it?
Bastille broke new ground by working to educate users about security, and help them make balanced, informed choices. Many users have found Bastilles secondary goal of educational just as useful as its primary goal of system hardening, leading some organizations to make an interactive Bastille hardening session part of their training regimen for new system administrators. In this spirit, Bastille can allow the user to run through the entire interactive portion without applying the chosen changes.
Who Uses It?
Bastille has become a vital part of the security hardening space. Its the most used hardening tool for Linux and HP-UX and is shipped by the vendor on SuSE, Debian, Gentoo and HP-UX. It is covered in all of the major books on Linux Security and has been the subject of a number of articles. Most recently, the Center for Internet Securitys Linux Hardening Guide has recommended the use of Bastille to help harden systems.
Enhancements:
- Updated for Fedora Core 5, SUSE 10, Mandriva 10.0, 10.1, 2006*, and preliminary support for Tiger.

Geo:Coder:US 1.00 offers a full-feature facility for geocoding US addresses, that is, estimating the latitude and longitude of any street address or intersection in the United States, using the TIGER/Line data set from the US Census Bureau. Geo:Coder:US uses Geo:TigerLine to parse this data, and DB_File to store a highly compressed distillation of it, and Geo:StreetAddress:US to parse addresses into normalized components suitable for looking up in its database.

You can find a live demo of this code at http://geocoder.us/. The demo.cgi script is included in eg/ directory distributed with this module, along with a whole bunch of other goodies. See Geo:Coder:US:Import for how to build your own Geo:Coder:US database.

Consider using a web service to access this geocoder over the Internet, rather than going to all the trouble of building a database yourself. See eg/soap-client.pl, eg/xmlrpc-client.pl, and eg/rest-client.pl for different examples of working clients for the rpc.geocoder.us geocoder web service.

Major Features:

1. Geo:Coder:US->geocode( $string )
   • Given a string containing a street address or intersection, return a list of specifiers including latitude and longitude for all matching entities in the database. To keep from churning over the entire database, the given address string must contain either a city and state, or a ZIP code (or both), or geocode() will return undef.
   • geocode() will attempt to normalize directional prefixes and suffixes, street types, and state abbreviations, as well as substitute TIGER/Line's idea of the "primary street name", if an alternate street name was provided instead.
   • If geocode() can parse the address, but not find a match in the database, it will return a hashref containing the parsed and normalized address or intersection, but without the "lat" and "long" keys specifying the location. If geocode() cannot even parse the address, it will return undef. Be sure to check for the existence of "lat" and "long" keys in the hashes returned from geocode() before attempting to use the values! This serves to distinguish between addresses that cannot be found versus addresses that are completely unparseable.
   • geocode() attempts to be as forgiving as possible when geocoding an address. If you say "Mission Ave" and all it knows about is "Mission St", then "Mission St" is what you'll get back. If you leave off directional identifiers, geocode() will return address geocoded in all the variants it can find, i.e. both "N Main St" and "S Main St".
   • Don't be surprised if geocoding an intersection returns more than one lat/long pair for a single intersection. If one of the streets curves greatly or doglegs even slightly, this will be the likely outcome.
   • geocode() is probably the method you want to use. See more in the following section on the structure of the returned address and intersection specifiers.
2. Geo:Coder:US->geocode_address( $string )
   • Works exactly like geocode(), but only parses addresses.
3. Geo:Coder:US->geocode_intersection( $string )
   • Works exactly like geocode(), but only parses intersections.
4. Geo:Coder:US->filter_ranges( $spec, @candidates )
   • Filters a list of address specifiers (presumably from the database) against a query specifier, filtering by prefix, type, suffix, or primary name if possible. Returns a list of matching specifiers. filter_ranges() will ignore a filtering step if it would result in no specifiers being returned. You probably won't need to use this.
5. Geo:Coder:US->find_ranges( $address_spec )
   • Given a normalized address specifier, return all the address ranges in the database that appear to cover that address. find_ranges() ignores prefix, suffix, and type fields in the specifier for search purposes, and then filters against them ex post facto. The intention for find_ranges() to find the closest match possible in preference to returning nothing. You probably want to use lookup_ranges() instead, which will call find_ranges() for you.
6. Geo:Coder:US->lookup_ranges( $address_spec, @ranges )
   • Given an address specifier and (optionally) some address ranges from the database, interpolate the street address into the street segment referred to by the address range, and return a latitude and longitude for the given address within each of the given ranges. If @ranges is not given, lookup_ranges() calls find_ranges() with the given address specifier, and uses those returned. You probably want to just use geocode() instead, which also parses an address string and determines whether it's a proper address or an intersection automatically.
7. Geo:Coder:US->find_segments( $intersection_spec )
   • Given a normalized intersection specifier, find all of the street segments in the database matching the two given streets in the given locale or ZIP code. find_segments() ignores prefix, suffix, and type fields in the specifier for search purposes, and then filters against them ex post facto. The intention for find_segments() to find the closest match possible in preference to returning nothing. You probably want to use lookup_intersection() instead, which will call find_segments() for you.
8. Geo:Coder:US->lookup_intersection( $intersection_spec )
   • Given an intersection specifier, return all of the intersections in the database between the two streets specified, plus a latitude and longitude for each intersection. You probably want to just use geocode() instead, which also parses an address string and determines whether it's a proper address or an intersection automatically.

Requirements: Perl

dbKalendar is a calendar theme for SuperKaramba that tries to mimic the Dashboard calendar widget introduced in Mac OS X 1.04 (Tiger).

It will probably never be as slick as the original, but Im trying to get it as close as possible. Goal is to have at least the same functions in dbKalender as there are in Dasboards calendar. After that has happened, perhaps integration with KOrganizer is possible.

LibTomCrypt is a comprehensive, modular, and portable cryptographic toolkit that provides developers with a vast array of well known published block ciphers, one-way hash functions, chaining modes, pseudo- random number generators, public key cryptography, and a plethora of other routines. It has been designed from the ground up to be very simple to use. It has a modular and standard API that allows new ciphers, hashes, and PRNGs to be added or removed without change to the overall end application. It features functions for easy handling and a complete user manual which has many source snippet examples.
LibTomCrypt is a fairly comprehensive, modular and portable cryptographic toolkit that provides developers with a vast array of well known published block ciphers, one-way hash functions, chaining modes, pseudo-random number generators, public key cryptography and a plethora of other routines.
LibTomCrypt has been designed from the ground up to be very simple to use. It has a modular and standard API that allows new ciphers, hashes and PRNGs to be added or removed without change to the overall end application. It features easy to use functions and a complete user manual which has many source snippet examples.
LibTomCrypt is free for all purposes under the public domain. This includes commercial use, redistribution and even branching.
Main features:
- Public domain and open source.
- Written entirely in portable ISO C source (except for things like RNGs for natural reasons)
- Builds out of the box on virtually every box. All that is required is GCC for the source to build.
- Includes a 90+ page user manual in PDF format (with working examples in it)
- Block Ciphers
- Ciphers come with an ECB encrypt/decrypt, setkey and self-test interfaces.
- All ciphers have the same prototype which facilitates using multiple ciphers at runtime.
- Some of the ciphers are flexible in terms of code size and memory usage.
- Ciphers Supported.
- Blowfish
- XTEA
- RC5
- RC6
- SAFER+
- Rijndael (aka AES)
- Twofish
- SAFER (K64, SK64, K128, SK128)
- RC2
- DES, 3DES
- CAST5
- Noekeon
- Skipjack
- Anubis (with optional tweak as proposed by the developers)
- Khazad
- Changing Modes
- Modes come with a start, encrypt/decrypt and set/get IV interfaces.
- Mode supported.
- ECB
- CBC
- OFB
- CFB
- CTR
- One-Way Hash Functions
- Hashes come with init, process, done and self-test interfaces.
- All hashes use the same prototypes for the interfaces.
- Hashes supported.
- MD2
- MD4
- MD5
- SHA-1
- SHA-224/256/384/512
- TIGER-192
- RIPE-MD 128/160
- WHIRLPOOL
- Message Authentication
- FIPS-198 HMAC (supports all hashes)
- FIPS pending OMAC1 (supports all ciphers)
- PMAC Authentication
- Message Encrypt+Authenticate Modes
- EAX Mode
- OCB Mode
- Pseudo-Random Number Generators
- Yarrow (based algorithm)
- RC4
- Support for /dev/random, /dev/urandom and the Win32 CSP RNG
- Fortuna
- SOBER-128
- Public Key Algorithms
- RSA (using PKCS #1 v2.1 and PKCS #1 v1.5)
- DH (using ElGamal signatures and simple DH encryption)
- ECC (over Z/pZ, ElGamal Signatures, simple DH style encryption)
- DSA (Users make their own groups)
- Other standards
- PKCS #1 (both v1.5 and v2.0 padding)
- PKCS #5
- ASN.1 DER for INTEGER types.
Enhancements:
- The ECC code was fixed, cleaned, and improved.
- GCM was fixed.
- UTF8 support was added to the ASN1 code.
- The documentation was improved.
- The published version of the manual is included.

Emdros is an Open-Source text database engine for storage and retrieval of analyzed or annotated text.
Emdros has a powerful query-language for asking relevant questions of the data.
Emdros has wide applicability in fields that deal with analyzed or annotated text. Application domains include linguistics, publishing, text processing, and any other fields that deal with annotated text.
Main features:
- Linguistic analyses are the primary target domain. This includes all levels of analysis, such as morphology, syntax, and discourse analysis, and even phonology to some extent.
- Publishing is also a field where Emdros can be useful. Emdros supports breaking a text down into pages, chapters, paragraphs, etc.
- Text processing may benefit from Emdros if the problem involves annotating the text.
Emdros provides a conceptual model of text which can be quite liberating to use once it has been grasped.
Meta-data may also be stored, so long as there is some textual element with which it can be associated.
Emdros is good both for corpus linguistics (large amounts of text) and for field-linguistics (smaller amounts of data).
Fixed corpora, such as Biblical texts, are good candidates for making Emdros useful. Emdros is currently being used for large databases of the Hebrew Bible.
Dictionaries are also a target possibility. Emdros supports structuring of text documents down to minute details, while not losing the big picture.
Emdros embodies a particular model of text called the EMdF model. The primary advantage over XMLs data model is that object types (such as pages and chapters) need not be hierarchically structured or embedded, but may overlap. In addition, objects (such as a clause or a phrase) need not be contiguous, but may have gaps.
Emdros can output its results in XML. The XML carries its own standalone DTD and validates with a validating parser.
Emdros architecture
Emdros fits into a software architecture as follows:
+---------------+
| Client | User-written
+---------------+
|
+---------------+
| MQL | Emdros
+---------------+
|
+---------------+
| EMdF | Emdros
+---------------+
|
+---------------+
| DB | PostgreSQL or MySQL
+---------------+
At the top, there is a client which you, the user, must write. This client will take advantage of Emdross services to provide for the needs of your particlar database domain.
Then come the two Emdros-layers: The MQL layer and the EMdF layer. The MQL layer provides an interface to the MQL language. The MQL layer automatically takes advantage of the EMdF layer, which translates the MQL queries into SQL calls to the underlying database.
The underlying database takes care of storing the data, and retrieving it as directed by the EMdF layer.
The data domain which Emdros handles is that of text. Emdros provides a certain abstraction of text that makes it ideally suited to storing and retrieving annotated text, such as linguistic analyses of a text.
These analyses can be, e.g., syntactic analyses, morphological analyses, or discourse analyses, or all of these. Phonological analyses are also supported to some extent.
Emdros is particularly useful in domains where research questions need to be asked of databases of annotated text. This would include dictionary-making, Biblical language-research (Greek or Hebrew), other linguistic research, and research on annotated text in general.
Emdros has a particular model of text called the EMdF model. Users have attested, and our experience shows, that the EMdF model can be quite liberating when dealing with text as a programmer or program designer. Thus any application that deals with annotated text will likely benefit from the Emdros and the EMdF model.
Enhancements:
- The topographic part of the language was expanded.
- A TIGER XML importer was added.
- Beta quality C# bindings were added.
- Bugfixes were made, and the regression test suite was enhanced.

Hasher is a tool to help programmers implement checksum algorithms and standard hashing into their own software.
Written entirely in C# and designed for use in the .NET Framework, Hasher providers a uniform interface to easily use any of the algorithms contained within this library in other programs.
Hasher is planned to encapsulate a wide variety of cryptographic hashing and checksum algorithms.
Focusing on compatibility, speed, and ease-of-use, Classless.Hasher currently supports over 25 different algorithms including the "basics" such as CRC, MD5, and SHA, as well as others like HAVAL, Tiger, Snefru, and Whirlpool.
Enhancements:
- Hasher rises from the dead!
- Fixed CRCStandards for CRC8 and CRC32.
- Fixed CRC handling when the Order was 64bits.
- Removed the REVERSED CRCStandards.
- Added CRCStandards for CRC64_ISO and CRC64_ECMA.
- Changed CRCStandard CRC16 to CRC16_IBM.
- Renamed CRC16_CCITT_REVERSED to CRC16_XMODEM.
- Fixed nasty bug that broke MD4, MD5, the RIPEMDs, Tiger, and the SHAs when large datasets were processed.
- Added support for creating Panama hashes.
- Fixed the NAnt build script to better support Mono and .NET v2.0.