main inclusion request: opencryptoki

[Dustin Kirkland ]

Binary package hint: opencryptoki

Please consider trousers for inclusion into Ubuntu main.
 * https://wiki.ubuntu.com/MainInclusionOpencryptoki

libopencryptoki-dev is a build dependency for ecryptfs-utils, which is under consideration for main:
 * Bug #247400
 * https://wiki.ubuntu.com/MainInclusionReportEcryptfsUtils

We could, perhaps, remove libopencryptoki-dev as a build dependency for ecryptfs-utils (Patch with Bug #247389). I requested that Debian do this upstream, but they disagreed. See:
 * http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=490233

libopencryptoki-dev contains support for IBM cryptographic accelerator hardware, particularly found in IBM servers.

If we include support for libopencryptoki, ecryptfs could leverage IBM cryptographic accelerator cards.

:-Dustin

[David Smith (dds)]

Dustin Kirkland <email address hidden> writes:

> Public bug reported:
>
> Binary package hint: opencryptoki
>
> Please consider trousers for inclusion into Ubuntu main.
> * https://wiki.ubuntu.com/MainInclusionOpencryptoki
>
> libopencryptoki-dev is a build dependency for ecryptfs-utils, which is under consideration for main:
> * Bug #247400
> * https://wiki.ubuntu.com/MainInclusionReportEcryptfsUtils
>
> We could, perhaps, remove libopencryptoki-dev as a build dependency for ecryptfs-utils (Patch with Bug #247389). I requested that Debian do this upstream, but they disagreed. See:
> * http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=490233
>
> libopencryptoki-dev contains support for IBM cryptographic accelerator
> hardware, particularly found in IBM servers.
>
> If we include support for libopencryptoki, ecryptfs could leverage IBM
> cryptographic accelerator cards.
>
> :-Dustin
>
> ** Affects: opencryptoki (Ubuntu)
> Importance: Undecided
> Status: New

It should be noted that libopencryptoki is also useful for using the TPM
chip found in many models of computers (including most if not all Dell
and Lenovo desktops and laptops, and many others). Having ecryptfs
support using strong hardware-based security out of the box on consumer
hardware is a good thing.

- dds

[Matthias Klose (doko)]

uses of sprintf
 - uses constants to allocate buffers in many places for logging. it looks like these functions
   are called with fixed/checked arguments.
 - many constants seem to be ad hoc and undocumented
 - e.g. usr/lib/pkcs11/cca_stdll/loadsave.c (load_token_data): fname uses a big buffer, not
   MAX_PATH_LEN (which at least is used somewhere else).
 - usr/lib/pkcs11/tpm_stdll/tpm_openssl.c: openssl_write_key/openssl_read_key: fixed buffer for filenames
 -> in many places, the constant 2048 is used for path lengths (however MAX_PATH currently is
      4096 on Linux). this should be fixed unless we are sure that all paths used do fit the fixed buffer

[Dustin Kirkland  (kirkland)]

On Tue, Jul 15, 2008 at 4:16 AM, Matthias Klose <email address hidden> wrote:
> - usr/lib/pkcs11/tpm_stdll/tpm_openssl.c: openssl_write_key/openssl_read_key: fixed buffer for filenames
> -> in many places, the constant 2048 is used for path lengths (however MAX_PATH currently is
> 4096 on Linux). this should be fixed unless we are sure that all paths used do fit the fixed buffer

I have sent the attached patch to the upstream maintainers, defining a
PATH_MAX constant, and setting it to 4096, if not already defined to
the Linux system PATH_MAX.

I'm placing it here, in case upstream delays and we need to carry this
patch ourself.

:-Dustin

[Dustin Kirkland  (kirkland)]

Matthias-

The patch I attached above has made it into the upstream version of Opencryptoki, and into an updated version in Debian unstable. Martin just sync'd version 2.2.6+dfsg-1 to Intrepid.

Please take another look and see if this addresses your concerns for promotion into Ubuntu main.

Thanks!
:-Dustin

[Matthias Klose (doko)]

the use of these undocumented constants is still a bit ugly, but afaics this shouldn't hinder promotion to main anymore.

[Martin Pitt (pitti)]

promoted