I wanted to announce a new Fedora Project that will span several distro
releases and outline the reasons why we are starting this project. I believe
this issue affects the whole Open Source Community. But don't think anyone
has explained all the issues.
The basic problem is that users want to have high quality, tested crypto that
can meet any certifications that the user wishes to deploy into, is easy to
manage, and works seamlessly across all applications.
Wouldn't it be neat if you could obtain a digital certificate from a CA using
Firefox, and then immediately turn around and use it to ssh to another
machine? Wouldn't it be nice to be able to turn off SSL2 in a central control
panel, and be guaranteed that all apps on your desktop obey that decision?
Wouldn't it be cool if every app needing crypto noticed that you inserted a
smart card, and immediately took advantage of it for operations like signing
email or setting up IPSec connections?
What prevents this is two problems: lack of tested crypto engine and the
proliferation of crypto into many packages. In order to deploy Fedora into
some environments like government or financial settings, you have to have a
crypto engine that passes FIPS 140-2. This certification ensures that the
crypto is correct for the algorithms tested.
The other problem is that there are dozens of packages that implement their
own version of crypto functions. If they make a mistake in one, the others
need to be checked to see if they copied the same bug. Because they are all
implemented separately, no sharing of keys, algorithm selection, or other
configuration data is possible.
The current state of certified crypto is that OpenSSL has passed a level 1
certification on a version that Red Hat has never shipped and therefore
unusable. Then there is NSS which is certified regularly at level 2. A level
1 crypto cert means that its good for use in Single User Mode, while level 2
means its good for multi-user mode. I'm not aware of any other FIPS
certifications of crypto contained within Fedora. So its down to these two.
So, if we want to make crypto easier to manage and enable Fedora's use in
these environments, that leaves us with a choice to make. We looked at
OpenSSL which has been supported well in the community, but it seems to have
a flaw that makes it unsuitable. For some applications like openssh, it draws
the crypto boundary inside the application. Openssh has to handle raw crypto
keys. This means that not only does OpenSSL need FIPS certification, but
openssh does, too.
If the crypto boundary was completely contained within the library and the
library has been FIPS 140-2 certified, many applications will gain the cert
just by linking to it. Its that simple. The only requirement is to follow the
system security policy. Nss only allows applications to have a handle to a
crypto session and the keys are not accessible to the application.
What we'd like to do in order to enable certified crypto is to update some
applications so that they can link against either OpenSSL or NSS. For Fedora,
we would then set the configure option to use NSS. We only want to do 2-3
packages for Fedora 8 and then some more in Fedora 9. We've already converted
some apps, like pam_pkcs11. Apache has mod_nss. We've built some tools to
help with enabling NSS by using an an abstraction library that presents some
of OpenSSL's API for easy conversion, while allowing other upstream users to
continue to use other libraries. Now we want to expand the effort and bring
other packages on-board.
Linux has a plethora of applications which use encryption technologies. Most
of these applications use encryption as a minor part the the application's
main functionality, just as it uses name service, file system services, etc.
Getting these applications on single toolkit will allow new encryption
technologies (like pkix, new crypto algorithms, etc.) to be added without
adding a burden on each of the many applications that use crypto.
We're looking for people interested in enabling NSS in their packages and
feeding the changes upstream.
For those unfamiliar with NSS, its the Secure Sockets library in FireFox.
There are already several applications using it such as Thunderbird and
evolution. More information about it can be found here:
For more information about this Fedora Project, please see:
Some developer resources:
And a comparison of crypto libraries:
When i try to compile a lib in rawhide i obtain this error in configure
section whereas there is no problem in F-7 :
checking for gcc option to produce PIC... -fPIC
checking if gcc PIC flag -fPIC works... yes
checking if gcc static flag -static works... yes
checking if gcc supports -c -o file.o... yes
checking whether the gcc linker (/usr/bin/ld) supports shared
checking whether -lc should be explicitly linked in... no
checking dynamic linker characteristics... cat: ld.so.conf.d/*.conf: No
such file or directory
Someone could help me to solve this ?
Can please someone kick the sources file from icewm...
[oliver@gosa icewm]$ file sources
sources: gzip compressed data, from Unix, last modified: Tue Aug 7
07:12:36 2007, max compression
[oliver@gosa icewm]$ gunzip -c sources | tar tfv -|tail
-rw-rw-r-- mark/mark 1004 2007-08-07 07:12 icewm-1.2.32/lib/winoptions
-rw-rw-r-- mark/mark 1241 2007-08-07 07:12
-rw-rw-r-- mark/mark 268 2007-08-07 07:12 icewm-1.2.32/sysdep.os2
-rw-r--r-- mark/mark 4281 2007-08-07 07:12 icewm-1.2.32/Makefile.in
-rwxrwxr-x mark/mark 5603 2007-08-07 07:12 icewm-1.2.32/install-sh
-rw-rw-r-- mark/mark 3424 2007-08-07 07:12 icewm-1.2.32/icewm.spec
-rw-rw-r-- mark/mark 577 2007-08-07 07:12 icewm-1.2.32/icewm.lsm
-rw-rw-r-- mark/mark 607 2007-08-07 07:12 icewm-1.2.32/aclocal.m4
-rwxrwxr-x mark/mark 416280 2007-08-07 07:12 icewm-1.2.32/configure
-rw-rw-r-- mark/mark 4509 2007-08-07 07:12 icewm-1.2.32/Makefile
Maybe I can do that myself, but if so, I would like to get permission to
do so first!