From marco.maggi-ipsu at poste.it Fri Jan 1 11:19:49 2010 From: marco.maggi-ipsu at poste.it (Marco Maggi) Date: Fri, 01 Jan 2010 11:19:49 +0100 Subject: doc confusion in 1.4.5 about gcry_sexp_canon_len Message-ID: <87oclexh2y.fsf@rapitore.luna> The documentation of "gcry_sexp_canon_len" states: | Scan the canonical encoded @var{buffer} with implicit | length values and return the actual length this | S-expression uses. For a valid S-expression it should | never return 0. If @var{length} is not 0, the maximum | length to scan is given; this can be used for syntax | checks of data passed from outside. @var{errcode} and | @var{erroff} may both be passed as @code{NULL}. 1. What does "with implicit length values" means? 2. Is it correct to rephrase "If @var{length} is not 0, the maximum length to scan is given;" to "If @var{length} is not 0, it must be the maximum number of bytes to scan in the buffer;"? 3. "@var{errcode} and @var{erroff} may both be passed as @code{NULL}." and if they are not, what values are returned? -- Marco Maggi From wk at gnupg.org Fri Jan 1 19:07:22 2010 From: wk at gnupg.org (Werner Koch) Date: Fri, 01 Jan 2010 19:07:22 +0100 Subject: doc confusion in 1.4.5 about gcry_sexp_canon_len In-Reply-To: <87oclexh2y.fsf@rapitore.luna> References: <87oclexh2y.fsf@rapitore.luna> Message-ID: <87fx6p3did.fsf@vigenere.g10code.de> On Fri, 01 Jan 2010 11:19:49 +0100, Marco Maggi wrote: > 1. What does "with implicit length values" means? A canonical S-expression knows its own length, that is the buffer encodes its own length. > 2. Is it correct to rephrase "If @var{length} is not 0, the > maximum length to scan is given;" to "If @var{length} is > not 0, it must be the maximum number of bytes to scan in > the buffer;"? No. This length is an upper limit; much ike the second arg in snprintf. You use this is you don't know the original of the S-expression and thus it may not be correctly encoded. > 3. "@var{errcode} and @var{erroff} may both be passed as > @code{NULL}." and if they are not, what values are > returned? An error code (GPG_ERR_xxx) and the approximate byte offset from the start of the buffer where the parser found the error. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From marco.maggi-ipsu at poste.it Sun Jan 3 09:11:28 2010 From: marco.maggi-ipsu at poste.it (Marco Maggi) Date: Sun, 03 Jan 2010 09:11:28 +0100 Subject: tokenising a sexp, possible without serialisation? Message-ID: <87hbr3ip5b.fsf@rapitore.luna> Ciao, I am writing a binding for a high-level language; it would really improve my API user-friendliness to convert a Gcrypt's sexp into a sexp for the language. I would like to do it without converting first "gcry_sexp_t" to a string in canon format, but is it actually possible using the "gcry_sexp_nth_*()" functions? What I miss is a way to determine if the next item is a tag, an MPI or an "unsigned long" (using the public Gcrypt API). The attached dirty program does not work when there are MPI numbers in the sexp. TIA -------------- next part -------------- A non-text attachment was scrubbed... Name: sexp-tokens.c Type: application/octet-stream Size: 2007 bytes Desc: not available URL: -------------- next part -------------- -- Marco Maggi From Werner.Dittmann at t-online.de Sun Jan 3 14:18:35 2010 From: Werner.Dittmann at t-online.de (Werner Dittmann) Date: Sun, 03 Jan 2010 14:18:35 +0100 Subject: CMake support for gcrypt Message-ID: <4B40992B.1000103@t-online.de> All, some of my projects now support the CMake build/configuration sytsem instead or in parallel to automake/autoconf. I attach a cmake file that checks the existence of gcrypt on the system and sets the appropriate variables to compile and link your sources that require gcrypt. To use the file follow the standard CMake rules, for example: - copy the file into your project's cmake/Modules directory - use CMake's include directive to include it - call the gcr_check macro (see documentation and examples in the file) Regards, Werner -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: FindGcryptConfig.cmake URL: From marco.maggi-ipsu at poste.it Fri Jan 1 10:30:49 2010 From: marco.maggi-ipsu at poste.it (Marco Maggi) Date: Fri, 01 Jan 2010 10:30:49 +0100 Subject: typos and style in 1.4.5 doc Message-ID: <87skaqxjcm.fsf@rapitore.luna> A non-text attachment was scrubbed... Name: gcrypt.diff.0to1 Type: application/octet-stream Size: 37749 bytes Desc: not available URL: -------------- next part -------------- -- Marco Maggi From marco.maggi-ipsu at poste.it Mon Jan 4 13:30:35 2010 From: marco.maggi-ipsu at poste.it (Marco Maggi) Date: Mon, 04 Jan 2010 13:30:35 +0100 Subject: notes and fixes about the 1.4.5 docs Message-ID: <87fx6m128k.fsf@rapitore.luna> I propose the following changes to the Texinfo sources: 1. It is my understanding that the PK/AC has been deprecated for a while, so the node "AC Interface" should be moved into an appendix. 2. The "Available Symmetric Algorithms" node should be nuked and its contents moved as is to the "Available algorithms" node. 3. The documentation of "gcry_pk_genkey()" should be moved in its own section. 4. Adding some example to the pubkey chapter would really help newbies getting started with the API; no need to do something sophisticated (or even meaningful), for example (out of the test suite with minor modifications): /* pk-showoff.c */ #include #include #include int main (void) { gcry_sexp_t key_parms_sexp, key_pair_sexp; gcry_sexp_t public_key_sexp, private_key_sexp; gcry_sexp_t data_sexp, enc_sexp, dec_sexp; gcry_sexp_t signature_sexp; gcry_mpi_t data; int rc; rc = gcry_sexp_new(&key_parms_sexp, "(genkey (rsa (nbits 4:1024)) (transient-key))", 0, 1); if (rc) goto error; rc = gcry_pk_genkey(&key_pair_sexp, key_parms_sexp); if (rc) goto error; gcry_sexp_release (key_parms_sexp); public_key_sexp = gcry_sexp_find_token (key_pair_sexp, "public-key", 0); if (! public_key_sexp) goto error; private_key_sexp = gcry_sexp_find_token (key_pair_sexp, "private-key", 0); if (! private_key_sexp) goto error; gcry_sexp_release (key_pair_sexp); data = gcry_mpi_new(50); gcry_mpi_set_ui(data, 123); rc = gcry_sexp_build(&data_sexp, NULL, "(data (flags raw) (value %m))", data); if (rc) goto error; rc = gcry_pk_encrypt(&enc_sexp, data_sexp, public_key_sexp); if (rc) goto error; rc = gcry_pk_decrypt(&dec_sexp, enc_sexp, private_key_sexp); if (rc) goto error; rc = gcry_pk_sign(&signature_sexp, data_sexp, private_key_sexp); if (rc) goto error; rc = gcry_pk_verify(signature_sexp, data_sexp, public_key_sexp); if ((0 != rc) && (GPG_ERR_BAD_SIGNATURE != rc)) goto error; fprintf(stderr, "correct signature? %s\n", (0 == rc)? "yes" : "no"); gcry_mpi_release(data); gcry_sexp_release(enc_sexp); gcry_sexp_release(dec_sexp); gcry_sexp_release(signature_sexp); gcry_sexp_release(private_key_sexp); gcry_sexp_release(public_key_sexp); exit(EXIT_SUCCESS); error: fprintf(stderr, "error %s\n", gcry_strerror(rc)); exit(EXIT_FAILURE); } /* end of file */ Attached is the second (and final) part of my typos, errors, style fixes for the Texinfo source. -------------- next part -------------- A non-text attachment was scrubbed... Name: gcrypt.diff.1to2 Type: application/octet-stream Size: 7403 bytes Desc: not available URL: -------------- next part -------------- -- Marco Maggi From dkg at fifthhorseman.net Tue Jan 5 03:04:12 2010 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 04 Jan 2010 21:04:12 -0500 Subject: tokenising a sexp, possible without serialisation? In-Reply-To: <87hbr3ip5b.fsf@rapitore.luna> References: <87hbr3ip5b.fsf@rapitore.luna> Message-ID: <4B429E1C.6090503@fifthhorseman.net> Hi Marco-- On 01/03/2010 03:11 AM, Marco Maggi wrote: > I am writing a binding for a high-level language; it would > really improve my API user-friendliness to convert a > Gcrypt's sexp into a sexp for the language. I'm afraid i don't know the answer, but i'm interested in as well, as i'm currently contributing to Perl's Crypt::GCrypt, and would like to get native sexp's comfortably set up in perl too. What language are you developing bindings for? --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 891 bytes Desc: OpenPGP digital signature URL: From marco.maggi-ipsu at poste.it Tue Jan 5 08:00:51 2010 From: marco.maggi-ipsu at poste.it (Marco Maggi) Date: Tue, 05 Jan 2010 08:00:51 +0100 Subject: tokenising a sexp, possible without serialisation? In-Reply-To: marco@localhost message of "Mon\, 04 Jan 2010 21\:04\:12 -0500") References: <87hbr3ip5b.fsf@rapitore.luna> <4B429E1C.6090503@fifthhorseman.net> Message-ID: <87iqbhqbmk.fsf@rapitore.luna> "Daniel Kahn Gillmor" wrote: > On 01/03/2010 03:11 AM, Marco Maggi wrote: > >> I am writing a binding for a high-level language; it >> would really improve my API user-friendliness to convert >> a Gcrypt's sexp into a sexp for the language. > > I'm afraid i don't know the answer, but i'm interested in > as well, as i'm currently contributing to Perl's > Crypt::GCrypt, and would like to get native sexp's > comfortably set up in perl too. > > What language are you developing bindings for? Scheme. -- Marco Maggi From wk at gnupg.org Tue Jan 5 09:10:15 2010 From: wk at gnupg.org (Werner Koch) Date: Tue, 05 Jan 2010 09:10:15 +0100 Subject: tokenising a sexp, possible without serialisation? In-Reply-To: <87hbr3ip5b.fsf@rapitore.luna> References: <87hbr3ip5b.fsf@rapitore.luna> Message-ID: <87637h2crc.fsf@vigenere.g10code.de> On Sun, 03 Jan 2010 09:11:28 +0100, Marco Maggi wrote: > I am writing a binding for a high-level language; it would > really improve my API user-friendliness to convert a > Gcrypt's sexp into a sexp for the language. Right. > I would like to do it without converting first > "gcry_sexp_t" to a string in canon format, but is it > actually possible using the "gcry_sexp_nth_*()" functions? I am not sure. I suggest that you indeed first convert to a canonical s-expression and parse that one. Here is some overhead right now but eventually this will go because there are plans to a change the internal implementation to work directly on canonical s-expressions. > What I miss is a way to determine if the next item is a tag, > an MPI or an "unsigned long" (using the public Gcrypt API). There is no way to do it because the s-expressions are typeless and we don't implement display hints. Libgcrypt deduces the type of an item out of the context. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From sergi at calcurco.cat Fri Jan 8 11:52:46 2010 From: sergi at calcurco.cat (=?ISO-8859-1?Q?Sergi_Blanch_i_Torn=E9?=) Date: Fri, 8 Jan 2010 11:52:46 +0100 Subject: Data type conversions Message-ID: <80e2a3c41001080252t1a7e700vc15243ed5addc816@mail.gmail.com> Hi, As you may already read, I am trying to implement the "ECC in OpenPGP". The ecdh algorithm, that is a pubkey encryption algorithm requires a hash and a symmetric encryption in a lower level. This means, from the point of view of the data, that I have to transform 'gcry_mpi_t' data form/to 'byte*'. In the libgcrypt documentation I didn't find a method for this conversion. If there is not, now can be useful, but to propose an implementation for that I have to know something more. Maybe only reading limbs byte by byte is enough, but endian issues can come because a limb are more than one byte. Do you have any information for this conversions? Thanks. /Sergi. From wk at gnupg.org Fri Jan 8 14:12:59 2010 From: wk at gnupg.org (Werner Koch) Date: Fri, 08 Jan 2010 14:12:59 +0100 Subject: Data type conversions In-Reply-To: <80e2a3c41001080252t1a7e700vc15243ed5addc816@mail.gmail.com> References: <80e2a3c41001080252t1a7e700vc15243ed5addc816@mail.gmail.com> Message-ID: <87fx6g210k.fsf@vigenere.g10code.de> On Fri, 8 Jan 2010 11:52:46 +0100, Sergi Blanch i Torn? wrote: > means, from the point of view of the data, that I have to transform > 'gcry_mpi_t' data form/to 'byte*'. In the libgcrypt documentation I > didn't find a method for this conversion. That is easy: Use gcry_mpi_print with a suitable format specifier. Have a look at this code in gnupg/g10/build-packet.c: /* * Write the mpi A to OUT. */ static int mpi_write (iobuf_t out, gcry_mpi_t a) { char buffer[(MAX_EXTERN_MPI_BITS+7)/8+2]; /* 2 is for the mpi length. */ size_t nbytes; int rc; nbytes = DIM(buffer); rc = gcry_mpi_print (GCRYMPI_FMT_PGP, buffer, nbytes, &nbytes, a ); if( !rc ) rc = iobuf_write( out, buffer, nbytes ); else if (gpg_err_code(rc) == GPG_ERR_TOO_SHORT ) { log_info ("mpi too large (%u bits)\n", gcry_mpi_get_nbits (a)); /* The buffer was too small. We better tell the user about the MPI. */ rc = gpg_error (GPG_ERR_TOO_LARGE); } return rc; } If you don't want to put an upper limit on the size of the MPI or you want to store int in secure memory you need to allocate the buffer. gcry_mpi_aprint does this for you and automagically decides whether to allocate from the standard or the secure memory pool. See the gcrypt manual. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From sergi at calcurco.cat Fri Jan 8 20:58:36 2010 From: sergi at calcurco.cat (=?ISO-8859-1?Q?Sergi_Blanch_i_Torn=E9?=) Date: Fri, 8 Jan 2010 20:58:36 +0100 Subject: Data type conversions In-Reply-To: <87fx6g210k.fsf@vigenere.g10code.de> References: <80e2a3c41001080252t1a7e700vc15243ed5addc816@mail.gmail.com> <87fx6g210k.fsf@vigenere.g10code.de> Message-ID: <80e2a3c41001081158w16a0ef85v294cd0ae10c54290@mail.gmail.com> I see that, and I can use gcry_mpi_scan() for the other way transformation. thanks. /Sergi. On Fri, Jan 8, 2010 at 2:12 PM, Werner Koch wrote: > On Fri, 8 Jan 2010 11:52:46 +0100, Sergi Blanch i Torn? wrote: >> means, from the point of view of the data, that I have to transform >> 'gcry_mpi_t' data form/to 'byte*'. In the libgcrypt documentation I >> didn't find a method for this conversion. > > That is easy: Use gcry_mpi_print with a suitable format specifier. > Have a look at this code in gnupg/g10/build-packet.c: > > /* > ?* Write the mpi A to OUT. > ?*/ > static int > mpi_write (iobuf_t out, gcry_mpi_t a) > { > ?char buffer[(MAX_EXTERN_MPI_BITS+7)/8+2]; /* 2 is for the mpi length. */ > ?size_t nbytes; > ?int rc; > > ?nbytes = DIM(buffer); > ?rc = gcry_mpi_print (GCRYMPI_FMT_PGP, buffer, nbytes, &nbytes, a ); > ?if( !rc ) > ? ?rc = iobuf_write( out, buffer, nbytes ); > ?else if (gpg_err_code(rc) == GPG_ERR_TOO_SHORT ) > ? ?{ > ? ? ?log_info ("mpi too large (%u bits)\n", gcry_mpi_get_nbits (a)); > ? ? ?/* The buffer was too small. We better tell the user about the MPI. */ > ? ? ?rc = gpg_error (GPG_ERR_TOO_LARGE); > ? ?} > > ?return rc; > } > > If you don't want to put an upper limit on the size of the MPI or you > want to store int in secure memory you need to allocate the buffer. > gcry_mpi_aprint does this for you and automagically decides whether to > allocate from the standard or the secure memory pool. ?See the gcrypt > manual. > > > Salam-Shalom, > > ? Werner > > -- > Die Gedanken sind frei. ?Ausnahmen regelt ein Bundesgesetz. > > From crtrn13 at gmail.com Mon Jan 11 10:25:06 2010 From: crtrn13 at gmail.com (ek645) Date: Mon, 11 Jan 2010 11:25:06 +0200 Subject: ECDSA Message-ID: <48e952f41001110125r219fa602q79f1d88ecf51b515@mail.gmail.com> I have a signing function, currently implemented in OpenSSL, that i'd like to convert to libgcrypt. However I can't seem to find good docks on ECDSA - specifically the gcrypt equivalent of EC_GROUP_new_curve_GFp(), EC_POINT_set_affine_coordinates_GF2m(), EC_GROUP_set_generator(), EC_KEY_set_group(), EC_KEY_get0_group(). Any help (example?) would be great! :) Thanks! From wk at gnupg.org Mon Jan 11 12:01:38 2010 From: wk at gnupg.org (Werner Koch) Date: Mon, 11 Jan 2010 12:01:38 +0100 Subject: ECDSA In-Reply-To: <48e952f41001110125r219fa602q79f1d88ecf51b515@mail.gmail.com> References: <48e952f41001110125r219fa602q79f1d88ecf51b515@mail.gmail.com> Message-ID: <87skaczyzx.fsf@vigenere.g10code.de> On Mon, 11 Jan 2010 11:25:06 +0200, ek645 wrote: > > I have a signing function, currently implemented in OpenSSL, that i'd > like to convert to libgcrypt. However I can't seem to find good docks > on ECDSA - specifically the gcrypt equivalent of > EC_GROUP_new_curve_GFp(), EC_POINT_set_affine_coordinates_GF2m(), > EC_GROUP_set_generator(), EC_KEY_set_group(), EC_KEY_get0_group(). I don't know OpenSSL's API to ECDSA and thus I can't tell you how to replace them. The API in Libgcrypt is very different from the one in OpenSSL. Unfortunately there is not yet much code using Libgcrypt's ECDSA except for tests/benchmark.c and tests/keygrip.c. The manual gives these hints: 6.2.3 ECC key parameters ------------------------ An ECC private key is described by this S-expression: (private-key (ecc (p P-MPI) (a A-MPI) (b B-MPI) (g G-POINT) (n N-MPI) (q Q-POINT) (d D-MPI))) P-MPI Prime specifying the field GF(p). A-MPI B-MPI The two coefficients of the Weierstrass equation y^2 = x^3 + ax + b G-POINT Base point g. N-MPI Order of g Q-POINT The point representing the public key Q = dP. D-MPI The private key d All point values are encoded in standard format; Libgcrypt does currently only support uncompressed points, thus the first byte needs to be `0x04'. The public key is similar with "private-key" replaced by "public-key" and no D-MPI. If the domain parameters are well-known, the name of this curve may be used. For example (private-key (ecc (curve "NIST P-192") (q Q-POINT) (d D-MPI))) The `curve' parameter may be given in any case and is used to replace missing parameters. A public is is similar; for example: char pubkey[] = ("(public-key" " (ecdsa" " (curve secp256r1)" " (q #04C8A4CE[...]63B344#)))"); Supported curve names are listed in the manual, you may also specify the parameters as you like. You will find some working code in gnupg/sm/ and libksba/src. That code is table based and thus not easy to read. If you have specific questions, just ask. Best with code samples. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From ametzler at downhill.at.eu.org Sun Jan 17 10:04:26 2010 From: ametzler at downhill.at.eu.org (Andreas Metzler) Date: Sun, 17 Jan 2010 10:04:26 +0100 Subject: libgcrypt11/mips(el): FTBFS with gcc-4.4 References: <20091217180000.GA3567@downhill.g.la> Message-ID: Andreas Metzler wrote: > this is . Debian/unstable has recently > switched to gcc-4.4. This seems to have caused a build-failure for > libgcrypt. > cu andreas > ----- Forwarded message from Aurelien Jarno ----- > From: Aurelien Jarno > Message-ID: <20091217133201.16090.92884.reportbug at mipsel.aurel32.net> > Date: Thu, 17 Dec 2009 14:32:01 +0100 > Subject: Bug#561475: libgcrypt11/mips(el): FTBFS with gcc-4.4 > Package: libgcrypt11 > Version: 1.4.1-1 > Severity: serious > Tags: patch > Justification: fails to build from source > mpfr fails to build on mips(el) with gcc-4.4. A full build log can be > found here: > https://buildd.debian.org/fetch.cgi?pkg=libgcrypt11&arch=mipsel&ver=1.4.5-1&stamp=1260977092&file=log&as=raw > This is due to a change in GCC 4.4, the h asm constraint is not > supported anymore on mips. For more details please have a look at: > http://gcc.gnu.org/gcc-4.4/changes.html > The patch below fixes the problem by implementing the solution > recommended by the previous web page. With it libgcrypt11 builds > successfully. > --- libgcrypt11-1.4.5.orig/mpi/longlong.h > +++ libgcrypt11-1.4.5/mpi/longlong.h > @@ -714,7 +714,15 @@ extern USItype __udiv_qrnnd (); > ************** MIPS ***************** > ***************************************/ > #if defined (__mips__) && W_TYPE_SIZE == 32 > -#if __GNUC__ > 2 || __GNUC_MINOR__ >= 7 > +#if (__GNUC__ >= 5) || (__GNUC__ == 4 && __GNUC_MINOR__ >= 4) > +#define umul_ppmm(w1, w0, u, v) \ > + do { \ > + UDItype _r; \ > + _r = (UDItype) u * v; \ > + (w1) = _r >> 32; \ > + (w0) = (USItype) _r; \ > + } while (0) > +#elif __GNUC__ > 2 || __GNUC_MINOR__ >= 7 > #define umul_ppmm(w1, w0, u, v) \ > __asm__ ("multu %2,%3" \ > : "=l" ((USItype)(w0)), \ > @@ -739,7 +747,16 @@ extern USItype __udiv_qrnnd (); > ************** MIPS/64 ************** > ***************************************/ > #if (defined (__mips) && __mips >= 3) && W_TYPE_SIZE == 64 > -#if __GNUC__ > 2 || __GNUC_MINOR__ >= 7 > +#if (__GNUC__ >= 5) || (__GNUC__ == 4 && __GNUC_MINOR__ >= 4) > +typedef unsigned int UTItype __attribute__ ((mode (TI))); > +#define umul_ppmm(w1, w0, u, v) \ > + do { \ > + UTItype _r; \ > + _r = (UTItype) u * v; \ > + (w1) = _r >> 64; \ > + (w0) = (UDItype) _r; \ > + } while (0) > +#elif __GNUC__ > 2 || __GNUC_MINOR__ >= 7 > #define umul_ppmm(w1, w0, u, v) \ > __asm__ ("dmultu %2,%3" \ > : "=l" ((UDItype)(w0)), \ [...] Hello, am I currently stuck in somebody's spam filter or is there a reason why this was ignored? thanks, cu andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure' From wk at gnupg.org Mon Jan 18 17:57:04 2010 From: wk at gnupg.org (Werner Koch) Date: Mon, 18 Jan 2010 17:57:04 +0100 Subject: missing entries in libgcrypt NEWS In-Reply-To: <87eiobwv9l.fsf@mocca.josefsson.org> (Simon Josefsson's message of "Fri, 06 Nov 2009 16:03:18 +0100") References: <87eiobwv9l.fsf@mocca.josefsson.org> Message-ID: <874omj4ahr.fsf@vigenere.g10code.de> On Fri, 6 Nov 2009 16:03, simon at josefsson.org said: > I just noticed that the NEWS file (even in latest svn) is missing many > entries from stable follow-on releases (e.g., 1.2.4), which makes it > harder to search for when some new features were added. Do you mean * Rewrote gcry_mpi_rshift to allow arbitrary shift counts. from 1.2.3? On a quick check I can't find many other noteworthy items. Almost all changes are listed in the NEWS for 1.3.0 - that one is newer than 1.2.4. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From simon at josefsson.org Mon Jan 18 22:13:45 2010 From: simon at josefsson.org (Simon Josefsson) Date: Mon, 18 Jan 2010 22:13:45 +0100 Subject: missing entries in libgcrypt NEWS In-Reply-To: <874omj4ahr.fsf@vigenere.g10code.de> (Werner Koch's message of "Mon, 18 Jan 2010 17:57:04 +0100") References: <87eiobwv9l.fsf@mocca.josefsson.org> <874omj4ahr.fsf@vigenere.g10code.de> Message-ID: <87hbqjt8ty.fsf@mocca.josefsson.org> Werner Koch writes: > On Fri, 6 Nov 2009 16:03, simon at josefsson.org said: >> I just noticed that the NEWS file (even in latest svn) is missing many >> entries from stable follow-on releases (e.g., 1.2.4), which makes it >> harder to search for when some new features were added. > > Do you mean > > * Rewrote gcry_mpi_rshift to allow arbitrary shift counts. > > from 1.2.3? On a quick check I can't find many other noteworthy items. > Almost all changes are listed in the NEWS for 1.3.0 - that one is > newer than 1.2.4. No. I mean that in the current trunk (r1418) there are no NEWS entries for version 1.2.1, 1.2.2, 1.2.3, or 1.2.4 at all. There are entries for 1.2.0 but then there is bump to 1.3.0 directly. I suspect you branches 1.2.x after 1.2.0 but then forgot about forward-porting the 1.2.x NEWS entries back to the trunk NEWS file after releases. /Simon From ametzler at downhill.at.eu.org Sat Jan 23 14:47:25 2010 From: ametzler at downhill.at.eu.org (Andreas Metzler) Date: Sat, 23 Jan 2010 14:47:25 +0100 Subject: Bug#566351: libgcrypt11: should not change user id as a side effect In-Reply-To: <20100123045523.5883.159.reportbug@marvin.43-1.org> References: <20100123045523.5883.159.reportbug@marvin.43-1.org> Message-ID: <20100123134725.GA3309@downhill.g.la> On 2010-01-23 Ansgar Burchardt wrote: > the function lock_pool from src/secmem.c has the side effect of changing > user ids if real uid != effective uid. This causes strange behaviour in > other programs: > A program using libnss-ldap for querying group membership with SSL > enabled, but without nscd might suddenly change the user id when calling > getgroups (or initgroups). An example for this is the atd daemon[1]. > Regards, > Ansgar > [1] https://bugs.launchpad.net/bugs/509734 Hello, afaiui this is documented behavior: | GCRYCTL_INIT_SECMEM; Arguments: int nbytes | This command is used to allocate a pool of secure memory and thus | enabling the use of secure memory. It also drops all extra privileges | the process has (i.e. if it is run as setuid (root)). If the argument | nbytes is 0, secure memory will be disabled. The minimum amount of | secure memory allocated is currently 16384 bytes; you may thus use a | value of 1 to request that default size. cu andreas From wk at gnupg.org Mon Jan 25 10:56:17 2010 From: wk at gnupg.org (Werner Koch) Date: Mon, 25 Jan 2010 10:56:17 +0100 Subject: Bug#566351: libgcrypt11: should not change user id as a side effect In-Reply-To: <20100123134725.GA3309@downhill.g.la> (Andreas Metzler's message of "Sat, 23 Jan 2010 14:47:25 +0100") References: <20100123045523.5883.159.reportbug@marvin.43-1.org> <20100123134725.GA3309@downhill.g.la> Message-ID: <87aaw2y0ce.fsf@vigenere.g10code.de> Hi! I understand that there is sometimes the need for lifetime long suid programs. Although, I don't think that it is a sensible approach to write software this way (instead of using helpers like userv), I can add a hack to disable dropping of permissions. Ansgar, is it that what you want? Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Mon Jan 25 15:47:57 2010 From: wk at gnupg.org (Werner Koch) Date: Mon, 25 Jan 2010 15:47:57 +0100 Subject: Bug#566351: libgcrypt11: should not change user id as a side effect In-Reply-To: <87iqaqiagn.fsf@marvin.43-1.org> (Ansgar Burchardt's message of "Mon, 25 Jan 2010 22:24:24 +0900") References: <20100123045523.5883.159.reportbug@marvin.43-1.org> <20100123134725.GA3309@downhill.g.la> <87aaw2y0ce.fsf@vigenere.g10code.de> <87iqaqiagn.fsf@marvin.43-1.org> Message-ID: <87hbqaw89u.fsf@vigenere.g10code.de> On Mon, 25 Jan 2010 14:24, ansgar at 2008.43-1.org said: > Yes, that is fine with me. Changing the default may break assumptions > made by existing applications after all. Of course we will not change the default. > It would be nice if the documentation could mention that libraries that > initialize gcrypt themselves should use this hack. Otherwise the That will never happen. This is totally bogus. If an application does not properly initialize libgcrypt it is in any case a severe error. However, Libgcrypt tries to minimize the bad effects of this and thus in general it works just fine. Dropping extended privileges is a part of this. > side effect of changing user ids is "inherited" by the library (which is > what was the problem here: the changing of user ids was inherited by > libnss-ldap via openldap and gnutls). Are you trying to tell us that there is an application with dependencies to libnss, openldap and gnutls and that one is intended to be run suid? Did you audit all that code and the way the code is used to be written properly in a way that the suid-ness is not exploitable? Given how hard it is to even write a small suid application I have severe doubts about the application and whether my proposed hack makes sense at all. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From ansgar at 43-1.org Mon Jan 25 16:13:48 2010 From: ansgar at 43-1.org (Ansgar Burchardt) Date: Tue, 26 Jan 2010 00:13:48 +0900 Subject: Bug#566351: libgcrypt11: should not change user id as a side effect In-Reply-To: <87hbqaw89u.fsf@vigenere.g10code.de> (Werner Koch's message of "Mon, 25 Jan 2010 15:47:57 +0100") References: <20100123045523.5883.159.reportbug@marvin.43-1.org> <20100123134725.GA3309@downhill.g.la> <87aaw2y0ce.fsf@vigenere.g10code.de> <87iqaqiagn.fsf@marvin.43-1.org> <87hbqaw89u.fsf@vigenere.g10code.de> Message-ID: <87zl42gqtv.fsf@marvin.43-1.org> Werner Koch writes: > Are you trying to tell us that there is an application with dependencies > to libnss, openldap and gnutls and that one is intended to be run suid? > Did you audit all that code and the way the code is used to be written > properly in a way that the suid-ness is not exploitable? Yes, it is even quite simple to write such an application: Just call getgroups(), getpwent(), ... on a system that uses LDAP. If there is no caching daemon like nscd running, the application will use libnss-ldap (via glibc's Name Service Switch) which can in turn use gnutls. As the application itself does not use openldap, gnutls, or gcrypt there is no way it could initialize gcrypt. Using PAM can probably result in similar problems. Regards, Ansgar From wk at gnupg.org Mon Jan 25 16:43:11 2010 From: wk at gnupg.org (Werner Koch) Date: Mon, 25 Jan 2010 16:43:11 +0100 Subject: Bug#566351: libgcrypt11: should not change user id as a side effect In-Reply-To: <87zl42gqtv.fsf@marvin.43-1.org> (Ansgar Burchardt's message of "Tue, 26 Jan 2010 00:13:48 +0900") References: <20100123045523.5883.159.reportbug@marvin.43-1.org> <20100123134725.GA3309@downhill.g.la> <87aaw2y0ce.fsf@vigenere.g10code.de> <87iqaqiagn.fsf@marvin.43-1.org> <87hbqaw89u.fsf@vigenere.g10code.de> <87zl42gqtv.fsf@marvin.43-1.org> Message-ID: <87d40yw5ps.fsf@vigenere.g10code.de> On Mon, 25 Jan 2010 16:13, ansgar at 43-1.org said: > Yes, it is even quite simple to write such an application: Just call > getgroups(), getpwent(), ... on a system that uses LDAP. If there is no > caching daemon like nscd running, the application will use libnss-ldap > (via glibc's Name Service Switch) which can in turn use gnutls. That is a broken design. glibc should never ever allow suid processes to run code from external services it is not 100% sure they are clean. I guess libnss_files and the other standard ones might be fine, but LDAP or even LDAPS are very problematic. Such code belongs into a separate process and not into the one of an arbitrary - possible suid - application. > As the application itself does not use openldap, gnutls, or gcrypt there > is no way it could initialize gcrypt. You may consider this a featue - it indicates that there is something severly wrong with the application running on a particular system configuration. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From ansgar at 2008.43-1.org Mon Jan 25 14:24:24 2010 From: ansgar at 2008.43-1.org (Ansgar Burchardt) Date: Mon, 25 Jan 2010 22:24:24 +0900 Subject: Bug#566351: libgcrypt11: should not change user id as a side effect In-Reply-To: <87aaw2y0ce.fsf@vigenere.g10code.de> (Werner Koch's message of "Mon, 25 Jan 2010 10:56:17 +0100") References: <20100123045523.5883.159.reportbug@marvin.43-1.org> <20100123134725.GA3309@downhill.g.la> <87aaw2y0ce.fsf@vigenere.g10code.de> Message-ID: <87iqaqiagn.fsf@marvin.43-1.org> Hi, Werner Koch writes: > I understand that there is sometimes the need for lifetime long suid > programs. Although, I don't think that it is a sensible approach to > write software this way (instead of using helpers like userv), I can add > a hack to disable dropping of permissions. > > Ansgar, is it that what you want? Yes, that is fine with me. Changing the default may break assumptions made by existing applications after all. It would be nice if the documentation could mention that libraries that initialize gcrypt themselves should use this hack. Otherwise the side effect of changing user ids is "inherited" by the library (which is what was the problem here: the changing of user ids was inherited by libnss-ldap via openldap and gnutls). Regards, Ansgar From fweimer at bfk.de Tue Jan 26 08:52:21 2010 From: fweimer at bfk.de (Florian Weimer) Date: Tue, 26 Jan 2010 07:52:21 +0000 Subject: Bug#566351: libgcrypt11: should not change user id as a side effect In-Reply-To: <87d40yw5ps.fsf@vigenere.g10code.de> (Werner Koch's message of "Mon\, 25 Jan 2010 16\:43\:11 +0100") References: <20100123045523.5883.159.reportbug@marvin.43-1.org> <20100123134725.GA3309@downhill.g.la> <87aaw2y0ce.fsf@vigenere.g10code.de> <87iqaqiagn.fsf@marvin.43-1.org> <87hbqaw89u.fsf@vigenere.g10code.de> <87zl42gqtv.fsf@marvin.43-1.org> <87d40yw5ps.fsf@vigenere.g10code.de> Message-ID: <82aaw1716y.fsf@mid.bfk.de> * Werner Koch: > That is a broken design. glibc should never ever allow suid processes > to run code from external services it is not 100% sure they are clean. > I guess libnss_files and the other standard ones might be fine, but LDAP > or even LDAPS are very problematic. Such code belongs into a separate > process and not into the one of an arbitrary - possible suid - > application. The libc jas no business policing user code in this way. NSS and PAM modules already need to be SUID-safe, and there's really no way around that. A process-based solution for PAM and NSS might have been preferable, but it's rather late for that now. One side effect of dropping privileges is that some code no longer treats the process environment as tainted, leading to security issues if the process has opened descriptors while it had increased privilege. Beyond getuid() != geteuid(), there is really no good way to check for a tainted environment, alas. But the whole discussion is rather odd. I thought that access to locked memory no longer requires root privileges, no? -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra?e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From simon at josefsson.org Wed Jan 27 09:44:39 2010 From: simon at josefsson.org (Simon Josefsson) Date: Wed, 27 Jan 2010 09:44:39 +0100 Subject: Bug#566351: libgcrypt11: should not change user id as a side effect In-Reply-To: <87pr4w1jvl.fsf@marvin.43-1.org> (Ansgar Burchardt's message of "Wed, 27 Jan 2010 09:17:34 +0900") References: <20100123045523.5883.159.reportbug@marvin.43-1.org> <20100123134725.GA3309@downhill.g.la> <87aaw2y0ce.fsf@vigenere.g10code.de> <87iqaqiagn.fsf@marvin.43-1.org> <87hbqaw89u.fsf@vigenere.g10code.de> <87zl42gqtv.fsf@marvin.43-1.org> <87d40yw5ps.fsf@vigenere.g10code.de> <87pr4w1jvl.fsf@marvin.43-1.org> Message-ID: <873a1skkco.fsf@mocca.josefsson.org> Ansgar Burchardt writes: > Werner Koch writes: > >> On Mon, 25 Jan 2010 16:13, ansgar at 43-1.org said: >> >>> Yes, it is even quite simple to write such an application: Just call >>> getgroups(), getpwent(), ... on a system that uses LDAP. If there is no >>> caching daemon like nscd running, the application will use libnss-ldap >>> (via glibc's Name Service Switch) which can in turn use gnutls. >> >> That is a broken design. glibc should never ever allow suid processes >> to run code from external services it is not 100% sure they are clean. >> I guess libnss_files and the other standard ones might be fine, but LDAP >> or even LDAPS are very problematic. Such code belongs into a separate >> process and not into the one of an arbitrary - possible suid - >> application. > > It can run in a separate process if nscd (glibc's name service caching > daemon) is running. But if nscd is not installed or not running for > some reason, there is not much to do except doing the query in the same > process. Why can't the system call fail in that situation? > There are enough sensible reasons for an application using gcrypt only > indirectly (eg. applications using gnutls should not need to care which > cryptographic library is used by it, more so for applications that only > use a library like libcurl that uses gnutls, but can also use OpenSSL). I agree here though. /Simon From ansgar at 43-1.org Wed Jan 27 01:17:34 2010 From: ansgar at 43-1.org (Ansgar Burchardt) Date: Wed, 27 Jan 2010 09:17:34 +0900 Subject: Bug#566351: libgcrypt11: should not change user id as a side effect In-Reply-To: <87d40yw5ps.fsf@vigenere.g10code.de> (Werner Koch's message of "Mon, 25 Jan 2010 16:43:11 +0100") References: <20100123045523.5883.159.reportbug@marvin.43-1.org> <20100123134725.GA3309@downhill.g.la> <87aaw2y0ce.fsf@vigenere.g10code.de> <87iqaqiagn.fsf@marvin.43-1.org> <87hbqaw89u.fsf@vigenere.g10code.de> <87zl42gqtv.fsf@marvin.43-1.org> <87d40yw5ps.fsf@vigenere.g10code.de> Message-ID: <87pr4w1jvl.fsf@marvin.43-1.org> Werner Koch writes: > On Mon, 25 Jan 2010 16:13, ansgar at 43-1.org said: > >> Yes, it is even quite simple to write such an application: Just call >> getgroups(), getpwent(), ... on a system that uses LDAP. If there is no >> caching daemon like nscd running, the application will use libnss-ldap >> (via glibc's Name Service Switch) which can in turn use gnutls. > > That is a broken design. glibc should never ever allow suid processes > to run code from external services it is not 100% sure they are clean. > I guess libnss_files and the other standard ones might be fine, but LDAP > or even LDAPS are very problematic. Such code belongs into a separate > process and not into the one of an arbitrary - possible suid - > application. It can run in a separate process if nscd (glibc's name service caching daemon) is running. But if nscd is not installed or not running for some reason, there is not much to do except doing the query in the same process. gcrypt's behavior also does not only affect suid processes, but also processes started by root that change their real user id to something else, but still need to change to a different user id later. >> As the application itself does not use openldap, gnutls, or gcrypt there >> is no way it could initialize gcrypt. > > You may consider this a featue - it indicates that there is something > severly wrong with the application running on a particular system > configuration. There are enough sensible reasons for an application using gcrypt only indirectly (eg. applications using gnutls should not need to care which cryptographic library is used by it, more so for applications that only use a library like libcurl that uses gnutls, but can also use OpenSSL). Regards, Ansgar From jbb at vcn.com Wed Jan 27 01:17:22 2010 From: jbb at vcn.com (John B. Brown) Date: Tue, 26 Jan 2010 17:17:22 -0700 Subject: iMac error Message-ID: <4B5F8612.50702@vcn.com> Dear Folk, The following error message arrives continually while compiling any 1.4.x version. The symbolic links are to ./i386/ and neither that nor a hand installed set of links to ./i586/ make any difference. The machine I have is iMac running Mac OS X version 10.6.2. The compiler is the the gnu gcc bootstrapped for this machine. If I change back to the Apple compiler will that allow the compile? Should I ignore the with-gnu-ld configure option? /bin/sh ../libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I.. -I../src -I../src -g -O2 -MT mpih-add1-asm.lo -MD -MP -MF .deps/mpih-add1-asm.Tpo -c -o mpih-add1-asm.lo mpih-add1-asm.S gcc -DHAVE_CONFIG_H -I. -I.. -I../src -I../src -g -O2 -MT mpih-add1-asm.lo -MD -MP -MF .deps/mpih-add1-asm.Tpo -c mpih-add1-asm.S -fno-common -DPIC -o .libs/mpih-add1-asm.o mpih-add1-asm.S:47:suffix or operands invalid for `push' mpih-add1-asm.S:48:suffix or operands invalid for `push' mpih-add1-asm.S:78:suffix or operands invalid for `jmp' mpih-add1-asm.S:113:suffix or operands invalid for `pop' mpih-add1-asm.S:114:suffix or operands invalid for `pop' make[2]: *** [mpih-add1-asm.lo] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 Shalom, John B. Brown. [jbb at vcn.com] 358 High Street, Buffalo, Wyoming 82834 "Freedom is not worth having if it does not include the freedom to make mistakes" Mahatma Gandhi "If any question why we died, tell them, because our fathers lied." Rudyard Kipling "A man who does not know the truth is just an idiot but a man who knows the truth and calls it a lie is a crook." Bertolt Brecht "I wonder whether the world is being run by smart people who are putting us on or by imbeciles who really mean it." Mark Twain From jbb at vcn.com Wed Jan 27 01:26:53 2010 From: jbb at vcn.com (John B. Brown) Date: Tue, 26 Jan 2010 17:26:53 -0700 Subject: iMac error Message-ID: <4B5F884D.1050803@vcn.com> Dear Folk, Exactly the same error message results from using the native compiler. ======================================================================= mv -f .deps/ec.Tpo .deps/ec.Plo /bin/sh ../libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I.. -I../src -I../src -g -O2 -MT mpih-add1-asm.lo -MD -MP -MF .deps/mpih-add1-asm.Tpo -c -o mpih-add1-asm.lo mpih-add1-asm.S gcc -DHAVE_CONFIG_H -I. -I.. -I../src -I../src -g -O2 -MT mpih-add1-asm.lo -MD -MP -MF .deps/mpih-add1-asm.Tpo -c mpih-add1-asm.S -fno-common -DPIC -o .libs/mpih-add1-asm.o mpih-add1-asm.S:47:suffix or operands invalid for `push' mpih-add1-asm.S:48:suffix or operands invalid for `push' mpih-add1-asm.S:78:suffix or operands invalid for `jmp' mpih-add1-asm.S:113:suffix or operands invalid for `pop' mpih-add1-asm.S:114:suffix or operands invalid for `pop' make[2]: *** [mpih-add1-asm.lo] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 jbb at pinball:~/gnu/build/libgcrypt-1.4.0 ======================================================================= Shalom, John B. Brown. [jbb at vcn.com] 358 High Street, Buffalo, Wyoming 82834 "Freedom is not worth having if it does not include the freedom to make mistakes" Mahatma Gandhi "If any question why we died, tell them, because our fathers lied." Rudyard Kipling "A man who does not know the truth is just an idiot but a man who knows the truth and calls it a lie is a crook." Bertolt Brecht "I wonder whether the world is being run by smart people who are putting us on or by imbeciles who really mean it." Mark Twain From wk at gnupg.org Wed Jan 27 11:28:27 2010 From: wk at gnupg.org (Werner Koch) Date: Wed, 27 Jan 2010 11:28:27 +0100 Subject: Bug#566351: libgcrypt11: should not change user id as a side effect In-Reply-To: <87pr4w1jvl.fsf@marvin.43-1.org> (Ansgar Burchardt's message of "Wed, 27 Jan 2010 09:17:34 +0900") References: <20100123045523.5883.159.reportbug@marvin.43-1.org> <20100123134725.GA3309@downhill.g.la> <87aaw2y0ce.fsf@vigenere.g10code.de> <87iqaqiagn.fsf@marvin.43-1.org> <87hbqaw89u.fsf@vigenere.g10code.de> <87zl42gqtv.fsf@marvin.43-1.org> <87d40yw5ps.fsf@vigenere.g10code.de> <87pr4w1jvl.fsf@marvin.43-1.org> Message-ID: <878wbju9is.fsf@vigenere.g10code.de> On Wed, 27 Jan 2010 01:17, ansgar at 43-1.org said: > There are enough sensible reasons for an application using gcrypt only > indirectly (eg. applications using gnutls should not need to care which > cryptographic library is used by it, more so for applications that only > use a library like libcurl that uses gnutls, but can also use OpenSSL). There is an easy solution to this: Use your own memory handler. Anyway, they need to care about this; read the gcrypt manual to see why this is important. In general all these inter-library dependencies are a mess. They subvert the assumptions of carefully written software. We have seen large trees of dependencies whre severeal vesion of the same library are in use - that works only by coincidence and yields bugs which are very hard to track down. There is also a licences compliance problem with this approach: I noticed in several cases OpenSSL used along with GPL software due to dependencies the developer was not aware of (e.g. OpenLDAP). Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From ansgar at 43-1.org Wed Jan 27 12:44:28 2010 From: ansgar at 43-1.org (Ansgar Burchardt) Date: Wed, 27 Jan 2010 20:44:28 +0900 Subject: Bug#566351: libgcrypt11: should not change user id as a side effect In-Reply-To: <873a1skkco.fsf@mocca.josefsson.org> (Simon Josefsson's message of "Wed, 27 Jan 2010 09:44:39 +0100") References: <20100123045523.5883.159.reportbug@marvin.43-1.org> <20100123134725.GA3309@downhill.g.la> <87aaw2y0ce.fsf@vigenere.g10code.de> <87iqaqiagn.fsf@marvin.43-1.org> <87hbqaw89u.fsf@vigenere.g10code.de> <87zl42gqtv.fsf@marvin.43-1.org> <87d40yw5ps.fsf@vigenere.g10code.de> <87pr4w1jvl.fsf@marvin.43-1.org> <873a1skkco.fsf@mocca.josefsson.org> Message-ID: <87mxzzg4bn.fsf@marvin.43-1.org> Hi, Simon Josefsson writes: >> It can run in a separate process if nscd (glibc's name service caching >> daemon) is running. But if nscd is not installed or not running for >> some reason, there is not much to do except doing the query in the same >> process. > > Why can't the system call fail in that situation? nscd is optional and one probably does not want to make the system unusable if it crashes (no possibility to log in when you cannot access the user database). It would likely also require special handling of the entire boot process when nscd is not yet available. Regards, Ansgar From simon at josefsson.org Wed Jan 27 14:18:29 2010 From: simon at josefsson.org (Simon Josefsson) Date: Wed, 27 Jan 2010 14:18:29 +0100 Subject: Bug#566351: libgcrypt11: should not change user id as a side effect In-Reply-To: <87mxzzg4bn.fsf@marvin.43-1.org> (Ansgar Burchardt's message of "Wed, 27 Jan 2010 20:44:28 +0900") References: <20100123045523.5883.159.reportbug@marvin.43-1.org> <20100123134725.GA3309@downhill.g.la> <87aaw2y0ce.fsf@vigenere.g10code.de> <87iqaqiagn.fsf@marvin.43-1.org> <87hbqaw89u.fsf@vigenere.g10code.de> <87zl42gqtv.fsf@marvin.43-1.org> <87d40yw5ps.fsf@vigenere.g10code.de> <87pr4w1jvl.fsf@marvin.43-1.org> <873a1skkco.fsf@mocca.josefsson.org> <87mxzzg4bn.fsf@marvin.43-1.org> Message-ID: <87d40vit3u.fsf@mocca.josefsson.org> Ansgar Burchardt writes: > Hi, > > Simon Josefsson writes: > >>> It can run in a separate process if nscd (glibc's name service caching >>> daemon) is running. But if nscd is not installed or not running for >>> some reason, there is not much to do except doing the query in the same >>> process. >> >> Why can't the system call fail in that situation? > > nscd is optional and one probably does not want to make the system > unusable if it crashes (no possibility to log in when you cannot > access the user database). It would likely also require special > handling of the entire boot process when nscd is not yet available. It would be nice if it was possible to configure it to fall back on something saner than invoking a setuid-binary when nscd is not available/working. That should work during boot too. Just an idea. /Simon From wk at gnupg.org Wed Jan 27 15:04:59 2010 From: wk at gnupg.org (Werner Koch) Date: Wed, 27 Jan 2010 15:04:59 +0100 Subject: iMac error In-Reply-To: <4B5F8612.50702@vcn.com> (John B. Brown's message of "Tue, 26 Jan 2010 17:17:22 -0700") References: <4B5F8612.50702@vcn.com> Message-ID: <87sk9rskxg.fsf@vigenere.g10code.de> On Wed, 27 Jan 2010 01:17, jbb at vcn.com said: > mpih-add1-asm.S:47:suffix or operands invalid for `push' I recall that such an error has been posted a while back. I have no time to investgate this now. Maybe it is a problem between gcc and the native (non-gnu) ld. In any case the configure option --disable-asm should help. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.