Free authentic campaigner software for linux

Authentic project is a Liberty-enabled identity provider aiming to address a broad range of needs, from simple to complex setups.
Its Liberty compliance relies on Lasso, a free softaware implementation of the Liberty Alliance specifications. It is a quixote application and is commonly run inside the Apache Web server.
Main features:
Liberty conformance
While not certified itself Authentic implements Liberty protocols through the use of Lasso that has been certified as conformat to Liberty specifications in May 2005. Authentic implements every feature required by the Identity Provider Conformance Matrix.
Additionally it has several extra features; for example it can act as a proxy identity provider, redirecting requests from service providers to other identity providers; or sharing identity attributes through ID-WSF Personal Profile (with an appropriate version of Lasso).
Performance
The underlying components are quite fast and Authentic doesnt slow things down. There are no hard measure yet but a quick benchmark using ab (from Apache) yielded more than 200 requests per second on my development laptop (Centrino 1.5GHz, 1GB RAM).
Ease of Administration
Authentic has a nice and useful web administrative interface; it provides convenient identity management and log analysis. It also has its share of parameters so it adapts to different needs without any code change.
Enhancements:
- This release fixes minor but annoying issues with 0.7.0 (error display and translations).

Kye is a puzzle game which takes ideas from Sokoban and the genre of falling-rocks puzzle games. However, it includes a wider range of objects, allowing a larger variety of puzzles to be constructed.
Python Kye is a clone of the original, shareware, Kye for Windows, and is compatible with the large number of existing extra levels designed for the Windows version of Kye.
This is a clone of the original Kye, but it is a good one. I have done my best to make it as authentic to the original game as possible (and when I say my best, people who have seen PrBoom will know I take this seriously).
It mimics the original, including some of the unusual/buggy things which occur in the original game. It should be compatible with all levels for v1.0 and v2.0 of the original Windows version of Kye. Let me know if you find a level which seem not to work right.
The only respect in which it is not fully like the original is that it is slightly more predictable. In the original, timing-sensitive mechanisms in levels would sometimes break for no reason; I think the original used two separate timer objects to control the faster and slower objects, and these would sometimes drift apart.
My version does not do this; but this effect was so marginal that I doubt any levels exist which depend on it.
And, unlike Kye for Windows v2, there is no level editor in this version. But you can always edit them with a text editor ? half of the existing extra levels were made this way.
Enhancements:
- Wall auto-rounding in the editor was fixed.
- The .desktop files in the RPM were fixed.
- Code cleanups were done.

MUNGE Uid N Gid Emporium is an authentication service for creating and validating credentials. It is designed to be highly scalable for use in an HPC cluster environment.
It allows a process to authenticate the UID and GID of another local or remote process within a group of hosts having common users and groups. These hosts form a security realm that is defined by a shared cryptographic key.
Clients within this security realm can create and validate credentials without the use of root privileges, reserved ports, or platform-specific methods.
Rationale
The need for MUNGE arose out of the HPC cluster environment. Consider the scenario in which a local daemon running on a login node receives a client request and forwards it on to remote daemons running on compute nodes within the cluster. Since the user has already logged on to the login node, the local daemon just needs a reliable means of ascertaining the UID and GID of the client process. Furthermore, the remote daemons need a mechanism to ensure the forwarded authentication data has not been subsequently altered.
A common solution to this problem is to use Unix domain sockets to determine the identity of the local client, and then forward this information on to remote hosts via trusted rsh connections. But this presents several new problems. First, there is no portable API for determining the identity of a client over a Unix domain socket. Second, rsh connections must originate from a reserved port; the limited number of reserved ports available on a given host directly limits scalability. Third, root privileges are required in order to bind to a reserved port. Finally, the remote daemons have no means of determining whether the client identity is authentic.
Overview
A process creates a credential by requesting one from the local MUNGE service. The encoded credential contains the UID and GID of the originating process. This process sends the credential to another process within the security realm as a means of proving its identity. The receiving process validates the credential with the use of its local MUNGE service. The decoded credential provides the receiving process with a reliable means of ascertaining the UID and GID of the originating process. This information can be used for accounting or access control decisions.
The contents of the credential (including any optional payload data) are encrypted with a key shared by all munged daemons within the security realm. The integrity of the credential is ensured by a message authentication code (MAC). The credential is valid for a limited time defined by its time-to-live (TTL). The daemon ensures unexpired credentials are not replayed on a particular host. Decoding of a credential can be restricted to a particular user and/or group ID. The payload data can be used for purposes such as embedding the destinations address to ensure the credential is only valid on a specific host. The internal format of the credential is encoded in a platform-independent manner. And the credential itself is base64 encoded to allow it to be transmitted over virtually any transport.
Enhancements:
- A bug was fixed that caused stack corruption on AMD-64 when using Libgcrypt.

sign is a file signing and signature verification utility. Its main purpose is to be a simple and convenient extension to a tar/gz/bzip2 line of tools to check file integrity and authenticity. Its small and simple, it does just one thing and hopefully does it well.

I needed a tool to digitally sign a bunch of .tar.gz and to allow recepients of the files to easily check, unzip, untar and start enjoying the content as quickly and painlessly as possible.

There are OpenSSL, GnuPG, PGP and others and they are of course perfectly capable of file signing. OpenSSL is probably the most widely spread one and best suited for the role of being a universal signing utility. However the state of affairs is such that OpenSSL as an application is not really used for anything more than generating tarball MD5 hashes. The other packages are plain big and complex for a simple task of file integrity checking. Its like getting a professional sound editing suite instead of a dead-simple .mp3 player. The larger crypto-packages also tend to lack modularity in a sense that to get file signing working I would need to configure a handful of core, but otherwise unrelated settings first. Besides if I am not going to use anything but a signing code, the rest will be sitting there collecting dust, creating untrivial shared libraries dependencies and a general feeling of a wasted disk space.

First of all, sign is a file processing tool, it reads from the files (including stdin) and writes to the files (including stdout). It can be used to attach signatures to the files or to verify and/or strip them.

Between signing and verifying latter will account for a bulk of usage. When checking the signature, sign will check for both integrity and authenticity of the file. An integrity check is done by validating SHA-1 hash embedded into the signature, and an authenticity is ensured by checking signers credentials against a trusted list.

sign adopts OpenSSH-style authentication model, where the trust hierarchy is flat (no certificates), an authentication is done with public keys and the list of trusted keys is grown gradually on as-needed basis.

Every trusted key is associated with a file name prefix called the title. The key can be trusted for signing files, whose name start with keys title. The same key may be associated with more than one title, but not vice versa.

The signature is appended at the end of the file and it carries three bits of information - the title, the public key of the signer and the hash of all preceeding data encrypted with signers private key. The verification is performed as follows:

The filename is checked to start with a title
The hash is decrypted using the public key
The hash is compared to the locally computed value (this ensures integrity)
The title is looked up locally; if its known and associated public key is the same as in the signature, the file is deemed authentic.
Otherwise if the title is known, but the key is different, the file is considered to be signed by untrusted, impersonating party and the check fails.
And lastly, if the title is unknown, the authenticity of the file cannot be established. The user is provided with public key fingerprint, which should be manually authenticated. Then the title and the key are added to the trusted list; and subsequent signatures from the this signer for this particular title will be cleared automatically.

In order to sign files, the signing keypair must first be generated. The keypair is maintained on per-user basis and can be created by running sign with a special command-line flag. The signing process itself is as follows (give or take insignificant details):

Run the filename through a list of owned titles and find the best match. Alternately accept explicit title from the user using one of the command-line flags.
Attach the title, attach public signing key
Compute the hash, encrypt it with private signing key
Attach encrypted hash.

For details on command-line syntax and other operating parameters, please refer to a man page; an online version is here.

Off-the-Record Messaging is a Pidgin plugin that allows you to have private conversations over instant messaging by providing:
Encryption
No one else can read your instant messages.
Authentication
You are assured the correspondent is who you think it is.
Deniability
The messages you send do not have digital signatures that are checkable by a third party. Anyone can forge messages after a conversation to make them look like they came from you. However, during a conversation, your correspondent is assured
the messages he sees are authentic and unmodified.
Perfect forward secrecy
If you lose control of your private keys, no previous conversation is compromised.
Enhancements:
- Translations for English, Dutch, Spanish, French, Slovak
- Added option to not log OTR conversations
- Large messages are now fragmented transparently instead of failing
- Removed "view secure session id" and "verify fingerprint" options from the OTR button menu. Added "authenticate buddy" option in its place. This new option allows you to authenticate your buddies by entering some secret that only the two of you know, rather than by using a long user-unfriendly sequence of hex characters. [The old "verify fingerprint" dialog is still available via an "Advanced..." button from the new "authenticate buddy" dialog.]

SDLPong project is a Pong clone.
SDLPong is a Pong clone that is intended to feel "authentic", while adding additional features to extend gameplay.
In other words, SDLPong is striving to be a purists pong.
For those of you with a more contemporary outlook, other features are in the planning stage. (These features will be toggable, for those who want to play a pure pong)
How to play:
Bounce the ball back and forth, not too hard.
For more options, type ./sdlpong --help
Enhancements:
- Added transparencies spport.
- Ball is now round!
- Started menu programming.
- Removed SDL_ttf support (now you have no excuse to try this tisaak).
- Fixed Player Twos controls for a qwerty keyboard.

Americas Army is one of the five most popular action games played online. It provides players with the most authentic military experience available, from exploring the development of Soldiers in individual and collective training to their deployment in simulated missions in the War on Terror.
Americas Army: Special Forces is the follow-up to Americas Army: Operations, which was released on July 4, 2002.
In Americas Army: Special Forces, players attempt to earn Green Beret status by completing individual and collective training missions drawn from the Special Forces Assignment and Selection (SFAS) process.
Players who complete the SFAS process have the opportunity to take on elite Special Forces roles and are qualified to play in multiplayer missions with units ranging from the elite 82d Airborne Division to the 75th Ranger Regiment.
Includes the complete game Americas Army: Operations.
Main features:
- Authentic U.S. Army experience Realistic depiction of the values, units, equipment and career opportunities that make the Army the worlds premier land force continually updated to incorporate new occupations, units, technologies and adventures.
- Realistic roles Including Weapons Specialist (18B), Intelligence (18F), Engineer (18C), Communications (18E) and Combat Medic (18D).
- Challenging Green Beret training Complete training missions drawn from the SFAS process at Fort Bragg. Successfully complete SFAS and advance to Special Forces Qualification Course (Q-Course) missions to explore new Special Forces roles.
- Intense Special Forces action Intense Special Forces action Experience multiplayer missions in simulated combat environments. Take part in missions that span the capabilities of a Special Forces detachment, including unconventional warfare, direct action, surveillance and reconnaissance and Combat Search and Rescue.
- Detailed Special Forces equipment and military hardware Building on the equipment available in Americas Army: Operations, Americas Army: Special Forces adds the M4 Carbine featuring the Picatinny rail mod system for attaching laser-aiming devices and sighting systems; the MP5SD6 Remington 870 shotgun for forced entry; the AT4, a shoulder-fired anti-tank rocket and the BDM, a shoulder-fired bunker demolition munition.
- Accurate Soldier behavior Players are bound by the laws of land warfare, Army values (honor, duty and integrity) and realistic rules of engagement as they navigate challenges in teamwork-based multiplayer force vs. force operations. Mission accomplishment standings are evaluated based on team effort and adherence to a set of values and norms of conduct.