--
Compared to the previous release, this version brings amongst other
changes the following:
o Support for giving interfacenames as internal/external address.
o contrib/ directory added.
o contrib/sockd-stat.awk, provides statistics based on sockd logfiles.
Contributed by Stephan Eisvogel <eisvogel@hawo.stw.uni-erlangen.de>.
o If gethostbyname() fails, treat it as if resolveprotocol was set to
fake, meaning we hope the socksserver will be able to resolve it.
Will presumably make certain dns configurations work better for
client.
See the NEWS file for a more complete list.
is to provide a powerful and extensible environment for solving
classical (pen-and-paper) ciphers, providing as much automation as
possible. Classical ciphers include common schemes like monoalphabetic
substitutions, where each letter of the alphabet is mapped to another
(usually different) letter consistently through the text. The first
version of Crank is restricting itself to these special ciphers. Other
algorithms forever devoid of Crank's attentions include Enigma, RSA,
DES, MurkelFish, or anything else invented after 1900.
NEWS:
- Due to an endianness handling problem Blowfish algorithm was not compatible
with other implementations. Now it has been corrected. If you want
to access the old algorithm used use the "blowfish-compat" module.
- Fixes in mcrypt_list_algorithms() for some systems. Bugs pointed out by
Jonathan Woolmington <jwool@ind.tansu.com.au>
- Fixes in stream mode.
- mcrypt_generic_init() no longer fails if smaller key is used. It uses
the most appropriate key size of the algorithm and pads with zeros.
- Fixes in wake algorithm (and support for IV).
- IV is now used in arcfour (arcfour-iv is now longer used).
Speedups in Arcfour.
disk all the files shared and the documents printed in a LanManager
environnement (all the Microsoft and Samba machines using LanManager
protocol to share data).
This is a proof of concept to show that LanManager (CIFS) is an
extremely insecure protocol.
It has been pointed out that there is another bug in the signature
verification code of GnuPG.
* This can easily lead to false positives *
All versions of GnuPG released before today are vulnerable!
To check a detached singature you normally do this:
gpg --verify foo.sig foo.txt
The problem here is that someone may replace foo.sig with a standard
signature containing some arbitrary signed text and its signature,
and then modify foo.txt - GnuPG does not detect this - Ooops.
The solution for this problem ist not easy and needs a change in the
semantics of the --verify command: It will not any longer be
possible to do this:
gpg --verify foo.sig <foo.txt
Instead you have to use this
gpg --verify foo.sig - <foo.txt
The difference here is that gpg sees 2 files on the command lines
and thereby knows that it should check a detached signature. We
really need this information and there is no way to avoid that
change, sorry. You should make sure that you never use the first
form, because this will lead to false positives when foo.sig is not
a detached signature - gnupg does detect the other case and warns
you, but this is not sufficient. If you use GnuPG from other
applications, please change it.
ok markus@
