From Lord-Of-Hellfire at gmx.net Wed Oct 5 08:56:19 2005 From: Lord-Of-Hellfire at gmx.net (Lord-Of-Hellfire@gmx.net) Date: Wed Oct 5 10:55:54 2005 Subject: libgcrypt card cryptography Message-ID: <10135.1128495379@www81.gmx.net> hi, is there a way to process card cryptography operations based on libgcrypt? I know it's possible with gnupg, but i am not sure about libgcrypt. greets -- GMX DSL = Maximale Leistung zum minimalen Preis! 2000 MB nur 2,99, Flatrate ab 4,99 Euro/Monat: http://www.gmx.net/de/go/dsl From wk at gnupg.org Wed Oct 5 14:54:49 2005 From: wk at gnupg.org (Werner Koch) Date: Wed Oct 5 14:56:49 2005 Subject: Libgcrypt 1.2.2 released Message-ID: <87br24f7ja.fsf@wheatstone.g10code.de> Hello! We are pleased to announce the availability of Libgcrypt 1.2.2. Libgcrypt is a general purpose library of cryptographic building blocks. It is based on the code used in GnuPG. This is a bug fix release solving a weakness in the random number generator when used by forking servers. There are no new features. It is suggested that all users of Libgcrypt update to this version. Noteworthy changes are: * Made the RNG immune against fork without exec. * Minor changes to some function declarations. Buffer arguments are now typed as void pointer. This should not affect any compilation. * A bug in the definition of gcry_cipher_register has been fixed. Source code is hosted at the GnuPG FTP server and its mirrors as listed at http://www.gnupg.org/download/mirrors.html . On the primary server the source file and its digital signature are: ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.2.2.tar.bz2 (762k) ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.2.2.tar.bz2.sig These files are bzip2 compressed. If you can't use the bunzip2 tool, gzip compressed versions of the files are also available: ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.2.2.tar.gz (937k) ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.2.2.tar.gz.sig As an alternative a patch against version 1.2.1 is available as: ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.2.1-1.2.2.diff.bz2 (140k) SHA-1 checksums are: fc61709a9719a239cf8ebbf19b84f99622655dda libgcrypt-1.2.2.tar.bz2 fdf3638c0de619343c5f2291a3e8b9fe610425ce libgcrypt-1.2.2.tar.gz aa02d0be295586604896de44195d13a4002a53b5 libgcrypt-1.2.1-1.2.2.diff.bz2 If you used the CVS version in the past, please note that we migrated the CVS repository to Subversion. Its new location is: svn://cvs.gnupg.org/libgcrypt/branches/LIBGCRYPT-1-2-BRANCH For help on installing or developing with Libgcrypt you should send mail to the grcypt-devel mailing list. For details see http://www.gnupg.org/documentation/mailing-lists.html . Improving Libgcrypt is costly, but you can help! We are looking for organizations that find Libgcrypt useful and wish to contribute back. You can contribute by reporting bugs, improve the software, or by donating money. Commercial support contracts for Libgcrypt are available, and they help finance continued maintenance. g10 Code GmbH, a Duesseldorf based company owned and headed by gpg's principal author, is currently funding Libgcrypt development. We are always looking for interesting development projects. Happy hacking, Moritz and Werner -- The GnuPG Experts http://g10code.com Free Software Foundation Europe http://fsfeurope.org Join the Fellowship and protect your Freedom! http://www.fsfe.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 199 bytes Desc: not available Url : /pipermail/attachments/20051005/a1b18975/attachment.pgp From ian at cypherpunks.ca Fri Oct 7 19:13:42 2005 From: ian at cypherpunks.ca (Ian Goldberg) Date: Fri Oct 7 20:30:54 2005 Subject: Segfault in libgcrypt Message-ID: <20051007171342.GC847@smtp.paip.net> I've encountered a segfault in libgcrypt. If you create an mpi by doing gcry_mpi_scan with a format of GCRYMPI_FMT_USG and a length of 0, that mpi ends up having no limbs (which is technically correct, for an mpi with value 0), but then some functions (like gcry_mpi_cmp_ui) try to access them anyway, causing a segfault. For example: #include #include int main(int argc, char **argv) { gcry_mpi_t good_zero, bad_zero; unsigned char zerobuf[1] = { 0x00 }; /* Make a "good" MPI with value 0 */ gcry_mpi_scan(&good_zero, GCRYMPI_FMT_USG, zerobuf, 1, NULL); /* Compare it to a ui */ printf("Result of comparing with 2: %d\n", gcry_mpi_cmp_ui(good_zero, 2)); /* Make a "bad" MPI with value 0 */ gcry_mpi_scan(&bad_zero, GCRYMPI_FMT_USG, zerobuf, 0, NULL); /* Compare it to a ui */ printf("Result of comparing with 2: %d\n", gcry_mpi_cmp_ui(bad_zero, 2)); return 0; } Outputs: Result of comparing with 2: -1 Segmentation fault This is an issue when you're parsing messages in a protocol that look like an mpi length, followed by data. If a length of 0 gets passed, to indicate a value of 0, you end up with one of these "bad" mpis. - Ian From mo at g10code.com Sat Oct 8 11:46:29 2005 From: mo at g10code.com (Moritz Schulte) Date: Sat Oct 8 12:22:46 2005 Subject: Segfault in libgcrypt In-Reply-To: <20051007171342.GC847@smtp.paip.net> References: <20051007171342.GC847@smtp.paip.net> Message-ID: <43479575.8070200@g10code.com> Hello Ian, thanks a lot for your report, I will try to figure out where in the MPI library we have similar problems. Moritz -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature Url : /pipermail/attachments/20051008/73dc2db1/signature-0001.pgp From mo at g10code.com Sat Oct 8 11:50:45 2005 From: mo at g10code.com (Moritz Schulte) Date: Sat Oct 8 12:23:45 2005 Subject: libgcrypt card cryptography In-Reply-To: <10135.1128495379@www81.gmx.net> References: <10135.1128495379@www81.gmx.net> Message-ID: <43479675.80709@g10code.com> Hello, > is there a way to process card cryptography operations based on libgcrypt? I > know it's possible with gnupg, but i am not sure about libgcrypt. I do not really understand your question, sorry. In case this helps you: Libgcrypt is a *low-level* cryptography library. As such, it does not contain smartcard related functionality. If you are interested in such code, have a look at e.g. scdaemon. Moritz -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature Url : /pipermail/attachments/20051008/ddd05ddd/signature.pgp From gcrypt at dstoecker.de Sat Oct 8 16:21:51 2005 From: gcrypt at dstoecker.de (Dirk Stoecker) Date: Sat Oct 8 16:21:45 2005 Subject: libgcrypt and patches again In-Reply-To: References: <87vf1u2gqt.fsf@wheatstone.g10code.de> <871x435ump.fsf@wheatstone.g10code.de> Message-ID: Hello, now again a month went by and I still had no real answer if the code I sent will be applied or not and in case it will not: Why? Usually it does not help to encourage developers if they are ignored for unknown reasons. It makes a lot of work to do patches as foreigner and beeing ignored is unaccaptable. I have worked succesful for other projects as well and are very unhappy with the way the libgcrypt team handles this. Ciao -- ____ _ _ ____ _ _ _ _ ____ | | | | | | \ / | | | the cool Gremlin from Bischofswerda | __ | ____| | \/ | | | WWW: http://www.dstoecker.de/ | | | | | | | | PGP key available on www page. |____| _|_ |____| _|_ _|_ |____| I hope AMIGA never stops making fun! From mo at g10code.com Sat Oct 8 18:54:10 2005 From: mo at g10code.com (Moritz Schulte) Date: Sat Oct 8 19:56:40 2005 Subject: libgcrypt and patches again In-Reply-To: References: <87vf1u2gqt.fsf@wheatstone.g10code.de> <871x435ump.fsf@wheatstone.g10code.de> Message-ID: <4347F9B2.6080702@g10code.com> Hello Dirk, > now again a month went by and I still had no real answer if the code > I sent will be applied or not and in case it will not: Why? first of all, I would like to apologize for not taking part in this discussion and/or giving appropriate answers. I will try to do so now. In general I think what your patch tries to implement is a good thing: it tries to give the user the option to release resources, which would be lost otherwise. But this is hard to implement in Libgcrypt. One should also keep in mind that what you need to do in respect to the library resources is probably not something that a majority of users of Libgcrypt need to do. Therefore it is a special-need and one COULD argue that users with such special-needs should rip the library apart and modify it to their needs. I think, in this context one should take the amount of work necessary for modifying the library in such a way into account. Now lets become concrete. The main problem I see here is that this concept of "bringing the library back to initial state" is not something that has been thought of so far during the development of Libgcrypt; I am quite sure that it is actually more complicated than your patch tries to make it look like. :) Examples: * ath: your patch does not bring the ath code back to initial state (the callbacks would not be reset, etc) * secmem: the pool of secure memory is not touched by your patch either. * global: debug flags and handlers are not reset These things could be fixed, yes. But it would be more work then just releasing the cipher/md/pubkey modules and the PRNG pool. Let me think about the integration of your patch in the official Libgcrypt tree again; it is kind of hairy. I would like to point your attention to my personal, bleeding-edge development branch of Libgcrypt; you can check it out through: svn co svn://cvs.gnupg.org/libgcrypt/branches/LIBGCRYPT-2.0-MO libgcrypt The tree contains a file named `DESIGN', which explains the main differences between the official version and this highly-experimental (!) and entirely unofficial version. I think what you need is something that my hacked Libgcrypt branch is supposed to provide. Of course, this is branch is rather uninteresting to you in case you simply want this functionality in the official, soon-to-release branch. But it might be interesting to you, in case you want to benefit from the functionality provided by this experimental branch without seeing the lack of `official support' and/or a stable API as a fundamental disadvantage. In case something related to that code is unclear to you, do not hesitate to contact me by private mail.. Thanks & happy hacking, Moritz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature Url : /pipermail/attachments/20051008/5dd3d25a/signature.pgp From ian at cypherpunks.ca Sat Oct 8 14:00:41 2005 From: ian at cypherpunks.ca (Ian Goldberg) Date: Sun Oct 9 19:15:44 2005 Subject: Segfault in libgcrypt In-Reply-To: <43479575.8070200@g10code.com> References: <20051007171342.GC847@smtp.paip.net> <43479575.8070200@g10code.com> Message-ID: <20051008120041.GE847@smtp.paip.net> On Sat, Oct 08, 2005 at 11:46:29AM +0200, Moritz Schulte wrote: > Hello Ian, > > thanks a lot for your report, I will try to figure out where in the MPI > library we have similar problems. Great. BTW, I notice the same thing happens (for the same reasons, presumably) if you allocate a new MPI with gcry_mpi_new(0), and then try to use it in a gcry_mpi_cmp_ui(). - Ian From misc at dstoecker.de Sun Oct 9 18:45:15 2005 From: misc at dstoecker.de (Dirk Stoecker) Date: Sun Oct 9 19:15:45 2005 Subject: libgcrypt and patches again In-Reply-To: <4347F9B2.6080702@g10code.com> References: <87vf1u2gqt.fsf@wheatstone.g10code.de> <871x435ump.fsf@wheatstone.g10code.de> <4347F9B2.6080702@g10code.com> Message-ID: Hello, > In general I think what your patch tries to implement is a good thing: > it tries to give the user the option to release resources, which would > be lost otherwise. But this is hard to implement in Libgcrypt. Not as hard as you think. Ok, it would be much easier to do so, when done from the first piece of code. Nevertheless, usually every part of initialization stuff only depends one nearly singular variables. So it is not necessary to care for everything, but only relase everything and reset these singular pieces (usually a "bool initialized"). The stuff I implemented works for the methods I used the library for (and some more, as I tried to care for other possible fields as well). If it is in the main tree and there are problems in other areas they will soon be bug-reported and fixed. Also a short code review from the developers could reduce the bug-reporting stage a lot. I would also help with this, but not as long as I see no step is done in this direction. I'm doing programming for more than 15 years including more than 4 totally different operating systems and memory models, some processor types and so on. So I have a bit of experience in these fields. I sometimes heard the "This does not work" or "This is hard to do" (and also said this sometimes myself), but usually it is not that complicated as one may think. > Examples: > * ath: your patch does not bring the ath code back to initial state > (the callbacks would not be reset, etc) > * secmem: the pool of secure memory is not touched by your patch either. > * global: debug flags and handlers are not reset > > These things could be fixed, yes. But it would be more work then just > releasing the cipher/md/pubkey modules and the PRNG pool. Usually it is something like: - Release everything - Reset import global variables. I think this is easy and straightforward (Thought it would be easier without any globals :-). BTW: It is also a necessary in case someone wants the software to be ported to different operating systems. Not every operating system has an memory garbage collection. > I think what you need is something that my hacked Libgcrypt branch is > supposed to provide. Of course, this is branch is rather uninteresting > to you in case you simply want this functionality in the official, That's the problem. I need a certain functionality and libgcrypt provides it. But I also need a clean system and libgcrypt does not provide it. For me there are two possibilities. Either I get the cleanup implemented in libgcrypt or I need to switch to another solution (possibly including a private reduced link-library based on libgcrypt). A experimental development branch does not help. I can spend some work on the project, but not too much, as it is not a major part of the things I do. Ciao -- ____ _ _ ____ _ _ _ _ ____ | | | | | | \ / | | | the cool Gremlin from Bischofswerda | __ | ____| | \/ | | | WWW: http://www.dstoecker.de/ | | | | | | | | PGP key available on www page. |____| _|_ |____| _|_ _|_ |____| I hope AMIGA never stops making fun! From wk at gnupg.org Mon Oct 10 11:03:03 2005 From: wk at gnupg.org (Werner Koch) Date: Mon Oct 10 11:06:40 2005 Subject: libgcrypt and patches again In-Reply-To: (Dirk Stoecker's message of "Sun, 9 Oct 2005 18:45:15 +0200 (CEST)") References: <87vf1u2gqt.fsf@wheatstone.g10code.de> <871x435ump.fsf@wheatstone.g10code.de> <4347F9B2.6080702@g10code.com> Message-ID: <87mzlhhhh4.fsf@wheatstone.g10code.de> On Sun, 9 Oct 2005 18:45:15 +0200 (CEST), Dirk Stoecker said: > so on. So I have a bit of experience in these fields. I sometimes heard > the "This does not work" or "This is hard to do" (and also said this > sometimes myself), but usually it is not that complicated as one may > think. It is not a matter whether it is complicated or not. We care about the code complexity - each and every line adds to it. If you provide ways to make the code less complex by keeping the API, it is more likely that that this will make it into Libgcrypt. Sorry, I see no way to apply a patch for the sake of Valgrind. Salam-Shalom, Werner From gcrypt at dstoecker.de Tue Oct 11 10:26:37 2005 From: gcrypt at dstoecker.de (Dirk Stoecker) Date: Tue Oct 11 10:26:44 2005 Subject: libgcrypt and patches again In-Reply-To: <87mzlhhhh4.fsf@wheatstone.g10code.de> References: <87vf1u2gqt.fsf@wheatstone.g10code.de> <871x435ump.fsf@wheatstone.g10code.de> <4347F9B2.6080702@g10code.com> <87mzlhhhh4.fsf@wheatstone.g10code.de> Message-ID: On Mon, 10 Oct 2005, Werner Koch wrote: > > so on. So I have a bit of experience in these fields. I sometimes heard > > the "This does not work" or "This is hard to do" (and also said this > > sometimes myself), but usually it is not that complicated as one may > > think. > > It is not a matter whether it is complicated or not. We care about the > code complexity - each and every line adds to it. If you provide ways > to make the code less complex by keeping the API, it is more likely > that that this will make it into Libgcrypt. Caring for totally abstract coding styles more then for actual implementation errors is a strange way to build security relevant software. Securely freeing and cleaning resources is usually an important part of cryptographic software solutions. > Sorry, I see no way to apply a patch for the sake of Valgrind. Well then, that's a word. I will extract the parts of libgcrypt I need and build a reduced LGPL-link-library from this. I will not bother this group any more with such strange ideas like clean software design. Ciao -- ____ _ _ ____ _ _ _ _ ____ | | | | | | \ / | | | the cool Gremlin from Bischofswerda | __ | ____| | \/ | | | WWW: http://www.dstoecker.de/ | | | | | | | | PGP key available on www page. |____| _|_ |____| _|_ _|_ |____| I hope AMIGA never stops making fun! From wk at gnupg.org Tue Oct 11 12:06:01 2005 From: wk at gnupg.org (Werner Koch) Date: Tue Oct 11 12:11:41 2005 Subject: libgcrypt and patches again In-Reply-To: (Dirk Stoecker's message of "Tue, 11 Oct 2005 10:26:37 +0200 (CEST)") References: <87vf1u2gqt.fsf@wheatstone.g10code.de> <871x435ump.fsf@wheatstone.g10code.de> <4347F9B2.6080702@g10code.com> <87mzlhhhh4.fsf@wheatstone.g10code.de> Message-ID: <874q7oe5bq.fsf@wheatstone.g10code.de> On Tue, 11 Oct 2005 10:26:37 +0200 (CEST), Dirk Stoecker said: > implementation errors is a strange way to build security relevant > software. Securely freeing and cleaning resources is usually an important > part of cryptographic software solutions. Please understand that these are one time allocations. Consider them part of the DSO loading process. Salam-Shalom, Werner From n.mavrogiannopoulos at gmail.com Tue Oct 11 12:25:26 2005 From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos) Date: Tue Oct 11 15:51:16 2005 Subject: libgcrypt and patches again In-Reply-To: <874q7oe5bq.fsf@wheatstone.g10code.de> References: <874q7oe5bq.fsf@wheatstone.g10code.de> Message-ID: <200510111225.26648.n.mavrogiannopoulos@gmail.com> On Tuesday 11 October 2005 12:06, Werner Koch wrote: > > implementation errors is a strange way to build security relevant > > software. Securely freeing and cleaning resources is usually an important > > part of cryptographic software solutions. > Please understand that these are one time allocations. Consider them > part of the DSO loading process. I tend to agree with Dirk on that matter. If a program uses 10 shared libraries that do not deallocate their resources, checking for memory leaks in the program is a disaster. -- Nikos Mavrogiannopoulos From christian at grothoff.org Tue Oct 11 16:00:24 2005 From: christian at grothoff.org (Christian Grothoff) Date: Tue Oct 11 17:26:45 2005 Subject: libgcrypt and patches again In-Reply-To: <200510111225.26648.n.mavrogiannopoulos@gmail.com> References: <874q7oe5bq.fsf@wheatstone.g10code.de> <200510111225.26648.n.mavrogiannopoulos@gmail.com> Message-ID: <200510110700.24138.christian@grothoff.org> On Tuesday 11 October 2005 03:25, Nikos Mavrogiannopoulos wrote: > On Tuesday 11 October 2005 12:06, Werner Koch wrote: > > > implementation errors is a strange way to build security relevant > > > software. Securely freeing and cleaning resources is usually an > > > important part of cryptographic software solutions. > > > > Please understand that these are one time allocations. Consider them > > part of the DSO loading process. > > I tend to agree with Dirk on that matter. If a program uses 10 shared > libraries that do not deallocate their resources, checking for memory leaks > in the program is a disaster. I also agree with Dirk. In particular I an thinking of problems that would occur if the library is loaded and unloaded repeatedly (dlopen/dlclose), causing the malloc'ed memory to live-on. Now, Dirk's explicit shutdown-call might not be the best choice in this context, maybe a destructor / _fini_ / whatever that is automatically triggered by the linker (ideally paired with a matching constructor that does the allocation) would be the perfect solution in my opinion. my 2 cents Christian From wk at gnupg.org Tue Oct 11 18:46:44 2005 From: wk at gnupg.org (Werner Koch) Date: Tue Oct 11 18:51:40 2005 Subject: libgcrypt and patches again In-Reply-To: <200510111225.26648.n.mavrogiannopoulos@gmail.com> (Nikos Mavrogiannopoulos's message of "Tue, 11 Oct 2005 12:25:26 +0200") References: <874q7oe5bq.fsf@wheatstone.g10code.de> <200510111225.26648.n.mavrogiannopoulos@gmail.com> Message-ID: <87wtkkf1cb.fsf@wheatstone.g10code.de> On Tue, 11 Oct 2005 12:25:26 +0200, Nikos Mavrogiannopoulos said: > I tend to agree with Dirk on that matter. If a program uses 10 shared > libraries that do not deallocate their resources, checking for memory leaks > in the program is a disaster. That depends on your definition of a memory leak. A one time allocation can't be a memory leak. Shalom-Salam, Werner From wk at gnupg.org Tue Oct 11 18:57:05 2005 From: wk at gnupg.org (Werner Koch) Date: Tue Oct 11 19:01:40 2005 Subject: libgcrypt and patches again In-Reply-To: <200510110700.24138.christian@grothoff.org> (Christian Grothoff's message of "Tue, 11 Oct 2005 07:00:24 -0700") References: <874q7oe5bq.fsf@wheatstone.g10code.de> <200510111225.26648.n.mavrogiannopoulos@gmail.com> <200510110700.24138.christian@grothoff.org> Message-ID: <87slv8f0v2.fsf@wheatstone.g10code.de> On Tue, 11 Oct 2005 07:00:24 -0700, Christian Grothoff said: > I also agree with Dirk. In particular I an thinking of problems that would > occur if the library is loaded and unloaded repeatedly (dlopen/dlclose), > causing the malloc'ed memory to live-on. Now, Dirk's explicit shutdown-call You simply can't do that with libgcrypt; it has not been designed to be runtime loaded. It is impossible for liibgcrypt to shut itself properly down. There is no reference counting or similar to detect resources in use by other objects. With the same justification one could ask for libc to shut itself down on demand. Well, of course, there is such a feature: exit(3). Valgrind is a great tool, but it does not exempt the developer to analyze the results. Look only on the suppress files distributed along with vg. Salam-Shalom, Werner From n.mavrogiannopoulos at gmail.com Thu Oct 27 11:31:24 2005 From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos) Date: Thu Oct 27 12:37:33 2005 Subject: Fwd: Re: [Help-gnutls] Why delay generating second and other keys? Message-ID: <200510271131.24736.n.mavrogiannopoulos@gmail.com> Hello, I forward this bug report. It seems like a bug to exit()... I don't know if there are possible alternatives there though. ---------- Forwarded Message ---------- Subject: Re: [Help-gnutls] Why delay generating second and other keys? Date: Wednesday 26 October 2005 22:51 From: Fran To: help-gnutls@gnu.org [...] Another question: Libcrypt use exit() in functions. The function > gnutls_x509_privkey_generate (key, key_type, bits, 0) does not return any value because libcrypt function use exit(). For this reason a program that have this function can not known which is the problem. For example if > gnutls_global_init(); is not called before. > static void * > _gcry_secmem_malloc_internal (size_t size) > { > memblock_t *mb; > > if (!pool_okay) > { > log_info (_ > ("operation is not possible without initialized secure memory\n")); > exit (2); > <<<<<<<-------------------------------------------------------------------- >---------------------------------------------------------------- } > if (show_warning && !suspend_warning) > { > show_warning = 0; > print_warn (); > } > > /* Blocks are always a multiple of 32. */ > size = ((size + 31) / 32) * 32; > > mb = mb_get_new ((memblock_t *) pool, size); > if (mb) > stats_update (size, 0); > > return mb ? &mb->aligned.c : NULL; > } _______________________________________________ Help-gnutls mailing list Help-gnutls@gnu.org http://lists.gnu.org/mailman/listinfo/help-gnutls ------------------------------------------------------- -- Nikos Mavrogiannopoulos From mr.s0rr0w at gmail.com Thu Oct 27 12:55:45 2005 From: mr.s0rr0w at gmail.com (s0rr0w) Date: Thu Oct 27 14:56:01 2005 Subject: libgcrypt visual studio workspaces Message-ID: <4360B231.8090802@gmail.com> hi all, I did a little project involved in libgcrypt (1.2.2) compilation using visual studio 6 (vs.net are easily derived from v6 workspaces), that's a part of other visual studio workspaces. you can find it on http://sourceforge.net/projects/gpgvs I did not change any code line, but I had some problems with tiger and rndegd, and with a lot of signed/unsigned warnings, but nothing that prevented me from building the library. I ported the tests too, but I was unable to compile two of them: - testapi.c I think the three "gcry_mpi_scan" calls are wrong - random.c too *nix oriented :p For tiger and these two tests I think one should change the code, if interested in working with lybgcrypt under vstudio. If anyone is interested, please try it and try the tests too. Thank you, keep on with this great effort! Francesco "s0rr0w" Picasso From wk at gnupg.org Thu Oct 27 19:41:28 2005 From: wk at gnupg.org (Werner Koch) Date: Thu Oct 27 19:46:44 2005 Subject: Fwd: Re: [Help-gnutls] Why delay generating second and other keys? In-Reply-To: <200510271131.24736.n.mavrogiannopoulos@gmail.com> (Nikos Mavrogiannopoulos's message of "Thu, 27 Oct 2005 11:31:24 +0200") References: <200510271131.24736.n.mavrogiannopoulos@gmail.com> Message-ID: <8764ri26yf.fsf@wheatstone.g10code.de> On Thu, 27 Oct 2005 11:31:24 +0200, Nikos Mavrogiannopoulos said: > I forward this bug report. It seems like a bug to exit()... I don't know if > there are possible alternatives there though. There is no point in continuing at that point. Yes, we could use abort() but than you may not get the error message. Salam-Shalom, Werner From wk at gnupg.org Thu Oct 27 19:44:21 2005 From: wk at gnupg.org (Werner Koch) Date: Thu Oct 27 19:46:51 2005 Subject: libgcrypt visual studio workspaces In-Reply-To: <4360B231.8090802@gmail.com> (mr.s0rr0w@gmail.com's message of "Thu, 27 Oct 2005 12:55:45 +0200") References: <4360B231.8090802@gmail.com> Message-ID: <871x2626tm.fsf@wheatstone.g10code.de> On Thu, 27 Oct 2005 12:55:45 +0200, s0rr0w said: > - random.c > too *nix oriented :p Nope, random builds on any patform. The platform specific code is in rnd{egd,unix,w32}.c. Make sure that the build system is fine; the code assumes that certain macros are set properly. > For tiger and these two tests I think one should change the code, Remove timer; it is useless. Shalom-Salam, Werner From mr.s0rr0w at gmail.com Fri Oct 28 10:21:57 2005 From: mr.s0rr0w at gmail.com (s0rr0w) Date: Fri Oct 28 11:16:05 2005 Subject: libgcrypt visual studio workspaces In-Reply-To: <871x2626tm.fsf@wheatstone.g10code.de> References: <4360B231.8090802@gmail.com> <871x2626tm.fsf@wheatstone.g10code.de> Message-ID: <4361DFA5.2060301@gmail.com> Werner Koch wrote: > On Thu, 27 Oct 2005 12:55:45 +0200, s0rr0w said: >>- random.c >> too *nix oriented :p > Nope, random builds on any patform. The platform specific code is in > rnd{egd,unix,w32}.c. Make sure that the build system is fine; the > code assumes that certain macros are set properly. this week end I'll try to make all things work :p > Shalom-Salam, > Werner cya, francesco