From r030t1 at gmail.com Fri Dec 1 00:05:27 2017 From: r030t1 at gmail.com (R0b0t1) Date: Thu, 30 Nov 2017 17:05:27 -0600 Subject: Hi there Developer i just have a question, wld take 3 min. In-Reply-To: References: Message-ID: On Thu, Nov 30, 2017 at 8:01 AM, Steinar Kvarre wrote: > I have tried gnupg, and wonder is there somehow possible to hack the > password > with the gnupg with X also comes up with password in X windows. (i use > xfce4) > so i wonderd if between there from gnupg app to X win ask for password, is > there > a connection, Im just wondering for safety, Sicnelry Steinar Kvarra, Norway. > Any program running as your user account could potentially debug GnuPG and recover your secret key. In the case of X11, it is possible to receive keyboard events directly. There are proposals to get around this but they tend to create more problems than they solve. GnuPG is not really part of any of these proposals. Cheers, R0b0t1 From cvs at cvs.gnupg.org Fri Dec 8 08:20:54 2017 From: cvs at cvs.gnupg.org (by Werner Koch) Date: Fri, 08 Dec 2017 08:20:54 +0100 Subject: [git] GCRYPT - branch, master, updated. libgcrypt-1.8.1-26-gd2feba8 Message-ID: This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "The GNU crypto library". The branch, master has been updated via d2feba84e1727185d2a518c34fb9f6ea9dbba1e8 (commit) from 2ad912d5b7794fb32192fddab1b559c7b86303a2 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- commit d2feba84e1727185d2a518c34fb9f6ea9dbba1e8 Author: Werner Koch Date: Fri Dec 8 08:15:42 2017 +0100 tests: Add another test case to keygrip.c -- This is mainly to answer a question on the ML. diff --git a/tests/keygrip.c b/tests/keygrip.c index f775f7a..73a6f81 100644 --- a/tests/keygrip.c +++ b/tests/keygrip.c @@ -189,6 +189,26 @@ static struct " ))", "\x9D\xB6\xC6\x4A\x38\x83\x0F\x49\x60\x70" "\x17\x89\x47\x55\x20\xBE\x8C\x82\x1F\x47" + }, + { /* Random key */ + GCRY_PK_RSA, + "(shadowed-private-key" + " (rsa" + " (n #00B493C79928398DA9D99AC0E949FE6EB62F683CB974FFFBFBC01066F5C9A89B" + " D3DC48EAD7C65F36EA943C2B2C865C26C4884FF9EDFDA8C99C855B737D77EEF6" + " B85DBC0CCEC0E900C1F89A6893A2A93E8B31028469B6927CEB2F08687E547C68" + " 6B0A2F7E50A194FF7AB7637E03DE0912EF7F6E5F1EC37625BD1620CCC2E7A564" + " 31E168CDAFBD1D9E61AE47A69A6FA03EF22F844528A710B2392F262B95A3078C" + " F321DC8325F92A5691EF69F34FD0DE0B22C79D29DC87723FCADE463829E8E5F7" + " D196D73D6C9C180F6A6A0DDBF7B9D8F7FA293C36163B12199EF6A1A95CAE4051" + " E3069C522CC6C4A7110F663A5DAD20F66C13A1674D050088208FAE4F33B3AB51" + " 03#)" + " (e #00010001#)" + " (shadowed t1-v1" + " (#D2760001240102000005000123350000# OPENPGP.1)" + ")))", + "\xE5\x6E\xE6\xEE\x5A\x2F\xDC\x3E\x98\x9D" + "\xFE\x49\xDA\xF5\x67\x43\xE3\x27\x28\x33" } }; @@ -217,6 +237,9 @@ check (void) if (err) die ("scanning data %d failed: %s\n", i, gpg_strerror (err)); + if (debug) + info ("check(%d): s-exp='%s'\n", i, key_grips[i].key); + for (repn=0; repn < repetitions; repn++) { ret = gcry_pk_get_keygrip (sexp, buf); @@ -228,6 +251,8 @@ check (void) print_hex ("keygrip: ", buf, sizeof buf); die ("keygrip for %d does not match\n", i); } + else if (debug && !repn) + print_hex ("keygrip: ", buf, sizeof buf); } gcry_sexp_release (sexp); ----------------------------------------------------------------------- Summary of changes: tests/keygrip.c | 25 +++++++++++++++++++++++++ 1 file changed, 25 insertions(+) hooks/post-receive -- The GNU crypto library http://git.gnupg.org _______________________________________________ Gnupg-commits mailing list Gnupg-commits at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-commits From jan.kiszka at siemens.com Fri Dec 15 15:03:23 2017 From: jan.kiszka at siemens.com (Jan Kiszka) Date: Fri, 15 Dec 2017 15:03:23 +0100 Subject: LGPL vs. OCB license Message-ID: <0917c6bd-acee-41ce-8a9a-e80a098bca4c@siemens.com> Hi all, maybe you can help clarifying the impact of the OCB license(s) on the effective license of libgcrypt. The OCB license 1 says under the definition of "Open Source Software Implementation": "Open Source Software Implementation does not include any Software Implementation in which the software implicating the Licensed Patents is combined, so as to form a larger program, with software that is not Open Source Software." My concern is now that this restriction excludes runtime linking as the LGPL would otherwise allow. And because cipher-ocb.c is an unconditional part of libgcrypt (unless you do local package surgery...), I would interpret this as the library becoming effectively GPL this way. Am I wrong? This issue has also been brought forward to Debian earlier this year [1], but the package maintainer did not address the linking situation so far. Thanks, Jan [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=879984 -- Siemens AG, Corporate Technology, CT RDA ITP SES-DE Corporate Competence Center Embedded Linux From wk at gnupg.org Fri Dec 15 17:32:50 2017 From: wk at gnupg.org (Werner Koch) Date: Fri, 15 Dec 2017 17:32:50 +0100 Subject: LGPL vs. OCB license In-Reply-To: <0917c6bd-acee-41ce-8a9a-e80a098bca4c@siemens.com> (Jan Kiszka's message of "Fri, 15 Dec 2017 15:03:23 +0100") References: <0917c6bd-acee-41ce-8a9a-e80a098bca4c@siemens.com> Message-ID: <87wp1o54ul.fsf@wheatstone.g10code.de> On Fri, 15 Dec 2017 15:03, jan.kiszka at siemens.com said: > My concern is now that this restriction excludes runtime linking as the > LGPL would otherwise allow. And because cipher-ocb.c is an unconditional > part of libgcrypt (unless you do local package surgery...), I would > interpret this as the library becoming effectively GPL this way. Am I wrong? The mentioned patent license granted by Rogaway and the software license are two very different things and can't be compared. Thus your assumptions that you have effectively the GPL is not correct. I am not allowed to give any legal advise but I would suggest that you check out the other license options provided by Rogaway. For example license 2 which can be used for almost all kind of usages in software. In any case, if you use a certain software you better check all other conditions on whether you are able to use and distribute the software - regardless of the software license. This may include patent research, trademark issues, or whether you are eligible to execute the rights granted by the license (for example permanent termination of the license due to prior violation of it). I am pretty sure your legal department knows about all of this. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From r030t1 at gmail.com Fri Dec 15 18:04:15 2017 From: r030t1 at gmail.com (R0b0t1) Date: Fri, 15 Dec 2017 11:04:15 -0600 Subject: LGPL vs. OCB license In-Reply-To: <87wp1o54ul.fsf@wheatstone.g10code.de> References: <0917c6bd-acee-41ce-8a9a-e80a098bca4c@siemens.com> <87wp1o54ul.fsf@wheatstone.g10code.de> Message-ID: Hello friends, As for the content of the license, it doesn't actually stipulate any additional terms or in fact a particular license. I have no idea what they are talking about on the Debian bug report. Has anyone read the license? It is very short and written in plain language. The LGPL would qualify under section 1.5., and the license adds no terms. On Fri, Dec 15, 2017 at 10:32 AM, Werner Koch wrote: > On Fri, 15 Dec 2017 15:03, jan.kiszka at siemens.com said: > >> My concern is now that this restriction excludes runtime linking as the >> LGPL would otherwise allow. And because cipher-ocb.c is an unconditional >> part of libgcrypt (unless you do local package surgery...), I would >> interpret this as the library becoming effectively GPL this way. Am I wrong? > > The mentioned patent license granted by Rogaway and the software license > are two very different things and can't be compared. Thus your > assumptions that you have effectively the GPL is not correct. > http://web.cs.ucdavis.edu/~rogaway/ocb/license.htm He mentions he holds a patent, but that only means he has the right to enforce his choice of license. Per the page there are three licenses. > I am not allowed to give any legal advise but I would suggest that you > check out the other license options provided by Rogaway. For example > license 2 which can be used for almost all kind of usages in software. > Such an opinion is cowardly and reprehensible: if you can not give legal advise on friendly terms, then it is only because you do not understand the law; if you do not understand the law, which you are subject to every day, then how can you in good faith say that the law is valid and that you are its subject? Even if you want to follow the law, you have just told me that you can not, because you do not understand it. > In any case, if you use a certain software you better check all other > conditions on whether you are able to use and distribute the software - > regardless of the software license. This may include patent research, > trademark issues, or whether you are eligible to execute the rights > granted by the license (for example permanent termination of the license > due to prior violation of it). I am pretty sure your legal department > knows about all of this. > If he is not a lawyer, why should he check the licenses? Even if he thinks he understands the terms, he may not be a lawyer, and any understanding of his would then be intrinsically flawed. Cheers, R0b0t1 From jan.kiszka at siemens.com Fri Dec 15 18:09:23 2017 From: jan.kiszka at siemens.com (Jan Kiszka) Date: Fri, 15 Dec 2017 18:09:23 +0100 Subject: LGPL vs. OCB license In-Reply-To: <87wp1o54ul.fsf@wheatstone.g10code.de> References: <0917c6bd-acee-41ce-8a9a-e80a098bca4c@siemens.com> <87wp1o54ul.fsf@wheatstone.g10code.de> Message-ID: On 2017-12-15 17:32, Werner Koch wrote: > On Fri, 15 Dec 2017 15:03, jan.kiszka at siemens.com said: > >> My concern is now that this restriction excludes runtime linking as the >> LGPL would otherwise allow. And because cipher-ocb.c is an unconditional >> part of libgcrypt (unless you do local package surgery...), I would >> interpret this as the library becoming effectively GPL this way. Am I wrong? > > The mentioned patent license granted by Rogaway and the software license > are two very different things and can't be compared. Thus your > assumptions that you have effectively the GPL is not correct. Good point. But while the code will not become GPL, the combination of the OCB implementation and the usage of libgcrypt in scopes where the patent applies should make the usage conditions similar to GPL. > > I am not allowed to give any legal advise but I would suggest that you > check out the other license options provided by Rogaway. For example > license 2 which can be used for almost all kind of usages in software. This one excludes non-commercial use, hmm... too bad (with corporate hat on). > > In any case, if you use a certain software you better check all other > conditions on whether you are able to use and distribute the software - > regardless of the software license. This may include patent research, > trademark issues, or whether you are eligible to execute the rights > granted by the license (for example permanent termination of the license > due to prior violation of it). I am pretty sure your legal department > knows about all of this. Legal departments are quick with "simple" obligations like "remove that file", and then you do the aforementioned package surgery which is what I want to reduce to zero for various good reasons, in standard distros packages or ideally already in upstream. I'm not deep into the crypto design at all, but is there a way to exclude to usage of this implementation during runtime? libgcrypt will surely pop up in many license analysis tools as distros move to a version that now contains the OCB implementation with that patent reference. Having good technical answers how to deal with them is what I searching for. The legal assessment will remain to the experts, but they need input from the engineering side as well. Thanks, Jan -- Siemens AG, Corporate Technology, CT RDA ITP SES-DE Corporate Competence Center Embedded Linux From jan.kiszka at siemens.com Fri Dec 15 18:50:25 2017 From: jan.kiszka at siemens.com (Jan Kiszka) Date: Fri, 15 Dec 2017 18:50:25 +0100 Subject: LGPL vs. OCB license In-Reply-To: <76f2fccf-9b28-428c-da59-2957024de67a@sumptuouscapital.com> References: <0917c6bd-acee-41ce-8a9a-e80a098bca4c@siemens.com> <87wp1o54ul.fsf@wheatstone.g10code.de> <76f2fccf-9b28-428c-da59-2957024de67a@sumptuouscapital.com> Message-ID: On 2017-12-15 18:34, Kristian Fiskerstrand wrote: > On 12/15/2017 06:09 PM, Jan Kiszka wrote: >> I'm not deep into the crypto design at all, but is there a way to >> exclude to usage of this implementation during runtime? > > Would presumably be even better to make this a compile time switch. Didn't dare to ask this as I have no idea how relevant the algorithm might be. I suppose, from a distro POV, being able to provide it as add-on in a separate package would be most flexible so that users can choose depending on their constraints and needs. But I don't see libcrypto being structured like that already. > > In addition to the debian bug referenced I've opened a similar bug for > Gentoo at https://bugs.gentoo.org/641160 , we will need to figure out > how to handle it there as well. > Thanks for the link. Ideally, the community finds a common pattern for handling this topic, both for completely free software as well as commercial integration scenarios. Jan -- Siemens AG, Corporate Technology, CT RDA ITP SES-DE Corporate Competence Center Embedded Linux From wk at gnupg.org Fri Dec 15 19:30:25 2017 From: wk at gnupg.org (Werner Koch) Date: Fri, 15 Dec 2017 19:30:25 +0100 Subject: LGPL vs. OCB license In-Reply-To: (R0b0t1's message of "Fri, 15 Dec 2017 11:04:15 -0600") References: <0917c6bd-acee-41ce-8a9a-e80a098bca4c@siemens.com> <87wp1o54ul.fsf@wheatstone.g10code.de> Message-ID: <87lgi36dz2.fsf@wheatstone.g10code.de> On Fri, 15 Dec 2017 18:04, r030t1 at gmail.com said: > Such an opinion is cowardly and reprehensible: if you can not give > legal advise on friendly terms, then it is only because you do not > understand the law; if you do not understand the law, which you are Nope: In Germany it unlawful to give legal advice without having the required formal education or a certification. Since 2008 it seems to be a bit less strict than the old Nazi law but it is unfortunately still in effect. The English wikipedia has no entry, thus I can only point you to https://de.wikipedia.org/wiki/Rechtsdienstleistungsgesetz > If he is not a lawyer, why should he check the licenses? Even if he Because Siemens is one of the largest companies in Germany. They even have a department for education on the use of free software. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From kristian.fiskerstrand at sumptuouscapital.com Fri Dec 15 18:34:42 2017 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Fri, 15 Dec 2017 18:34:42 +0100 Subject: LGPL vs. OCB license In-Reply-To: References: <0917c6bd-acee-41ce-8a9a-e80a098bca4c@siemens.com> <87wp1o54ul.fsf@wheatstone.g10code.de> Message-ID: <76f2fccf-9b28-428c-da59-2957024de67a@sumptuouscapital.com> On 12/15/2017 06:09 PM, Jan Kiszka wrote: > I'm not deep into the crypto design at all, but is there a way to > exclude to usage of this implementation during runtime? Would presumably be even better to make this a compile time switch. In addition to the debian bug referenced I've opened a similar bug for Gentoo at https://bugs.gentoo.org/641160 , we will need to figure out how to handle it there as well. -- ---------------------------- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk ---------------------------- Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 ---------------------------- "If you cannot convince them, confuse them" (Harry S Truman) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Fri Dec 15 19:40:59 2017 From: wk at gnupg.org (Werner Koch) Date: Fri, 15 Dec 2017 19:40:59 +0100 Subject: LGPL vs. OCB license In-Reply-To: (Jan Kiszka's message of "Fri, 15 Dec 2017 18:09:23 +0100") References: <0917c6bd-acee-41ce-8a9a-e80a098bca4c@siemens.com> <87wp1o54ul.fsf@wheatstone.g10code.de> Message-ID: <87h8sr6dhg.fsf@wheatstone.g10code.de> On Fri, 15 Dec 2017 18:09, jan.kiszka at siemens.com said: > This one excludes non-commercial use, hmm... too bad (with corporate hat > on). Not in my reading. It excludes the use for military purposes. > Legal departments are quick with "simple" obligations like "remove that > file", and then you do the aforementioned package surgery which is what > I want to reduce to zero for various good reasons, in standard distros > packages or ideally already in upstream. Right, for quite some time RedHat removed ECC frokm Libgcrypt. > I'm not deep into the crypto design at all, but is there a way to > exclude to usage of this implementation during runtime? I can't see that OCB is used in Libgcrypt internally. Thus by not using it you should be fine. In theory we could add a runtime switch to disable it (using /etc/gcrypt/something) but whether this will be sufficient is a different question. I really can't decide that and in particialr not for a US-only patent. > libgcrypt will surely pop up in many license analysis tools as distros > move to a version that now contains the OCB implementation with that > patent reference. Having good technical answers how to deal with them is OpenSSL also included OCB unconditionally. Thus Libgcrypt should be the smallest problem. > what I searching for. The legal assessment will remain to the experts, > but they need input from the engineering side as well. Sure. I doubt that debian-legal or this mailing list are the best place for it. However, feel free to discuss it here. Shalom-Salam, Werner p.s I'll get you in contact with a guy whou should know more about it. -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From kristian.fiskerstrand at sumptuouscapital.com Fri Dec 15 20:05:17 2017 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Fri, 15 Dec 2017 20:05:17 +0100 Subject: LGPL vs. OCB license In-Reply-To: <87h8sr6dhg.fsf@wheatstone.g10code.de> References: <0917c6bd-acee-41ce-8a9a-e80a098bca4c@siemens.com> <87wp1o54ul.fsf@wheatstone.g10code.de> <87h8sr6dhg.fsf@wheatstone.g10code.de> Message-ID: <5ed5dc40-ef87-835a-ba07-6fb3c96cd65f@sumptuouscapital.com> On 12/15/2017 07:40 PM, Werner Koch wrote: > OpenSSL also included OCB unconditionally. Thus Libgcrypt should be the > smallest problem. As i understand it that is covered by the explicit [OpenSSL license grant], that as far as I can tell doesn't have any further restrictions of use of openssl. Snippets: 1.3 " Use in OpenSSL" means using, making, copying, modifying, distribu ting, having made, importing or having imported any program, software, or computer system containing or based upon the OpenSSL toolkit, but does not include any imp lementation of the Licensed Patents that is unrelated to the OpcnSSL toolkit. 1.4 "Licensee" means the OpenSSL Software Foundation, at 1829 Mount Ephraim Road, Adamstown , MD 21710, its affiliates, assignees. or sllccessors in interest, or anyone using, making, copying, modifying, di stributing, having made, importing, or having imported any program, software, or computer system including or based upon the OpenSSL toolkit, or their customers, suppliers, importers, manufacturers, distributors, or Insurers. and... 2.1 Licensor hereby grants to Licensee a perpetual, worldwide, non-exclusive, non-transferable, non-sublicenseable, no-charge, royalty-free, irrevocable license to Use in OpenSSL any invention claimed in the Licensed Patents. References: [OpenSSL license grant] https://wiki.openssl.org/images/6/66/OCB-patent-grant-OpenSSL.pdf -- ---------------------------- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk ---------------------------- Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 ---------------------------- "Strength lies in differences, not in similarities." (Stephen Covey) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From jan.kiszka at siemens.com Fri Dec 15 20:09:09 2017 From: jan.kiszka at siemens.com (Jan Kiszka) Date: Fri, 15 Dec 2017 20:09:09 +0100 Subject: LGPL vs. OCB license In-Reply-To: <87h8sr6dhg.fsf@wheatstone.g10code.de> References: <0917c6bd-acee-41ce-8a9a-e80a098bca4c@siemens.com> <87wp1o54ul.fsf@wheatstone.g10code.de> <87h8sr6dhg.fsf@wheatstone.g10code.de> Message-ID: <3786ade5-2cb1-6dcc-a529-b7197100a1fa@siemens.com> On 2017-12-15 19:40, Werner Koch wrote: > On Fri, 15 Dec 2017 18:09, jan.kiszka at siemens.com said: > >> This one excludes non-commercial use, hmm... too bad (with corporate hat >> on). > > Not in my reading. It excludes the use for military purposes. [Re-reading] indeed - guess that's why I'm not a lawyer. A relevant take-away of that license path for redistributors should then be 2.2.2, i.e. including the full license text. That makes it clearer to me why Debian closed their bug after doing that. > >> Legal departments are quick with "simple" obligations like "remove that >> file", and then you do the aforementioned package surgery which is what >> I want to reduce to zero for various good reasons, in standard distros >> packages or ideally already in upstream. > > Right, for quite some time RedHat removed ECC frokm Libgcrypt. > >> I'm not deep into the crypto design at all, but is there a way to >> exclude to usage of this implementation during runtime? > > I can't see that OCB is used in Libgcrypt internally. Thus by not using > it you should be fine. In theory we could add a runtime switch to > disable it (using /etc/gcrypt/something) but whether this will be > sufficient is a different question. I really can't decide that and in > particialr not for a US-only patent. > >> libgcrypt will surely pop up in many license analysis tools as distros >> move to a version that now contains the OCB implementation with that >> patent reference. Having good technical answers how to deal with them is > > OpenSSL also included OCB unconditionally. Thus Libgcrypt should be the > smallest problem. > >> what I searching for. The legal assessment will remain to the experts, >> but they need input from the engineering side as well. > > Sure. I doubt that debian-legal or this mailing list are the best place > for it. However, feel free to discuss it here. > > > Shalom-Salam, > > Werner > > > p.s > I'll get you in contact with a guy whou should know more about it. > Thanks a lot. Jan -- Siemens AG, Corporate Technology, CT RDA ITP SES-DE Corporate Competence Center Embedded Linux From ametzler at bebt.de Fri Dec 15 20:17:48 2017 From: ametzler at bebt.de (Andreas Metzler) Date: Fri, 15 Dec 2017 20:17:48 +0100 Subject: LGPL vs. OCB license In-Reply-To: <87h8sr6dhg.fsf@wheatstone.g10code.de> References: <0917c6bd-acee-41ce-8a9a-e80a098bca4c@siemens.com> <87wp1o54ul.fsf@wheatstone.g10code.de> <87h8sr6dhg.fsf@wheatstone.g10code.de> Message-ID: <20171215191748.GB1430@argenau.bebt.de> On 2017-12-15 Werner Koch wrote: > On Fri, 15 Dec 2017 18:09, jan.kiszka at siemens.com said: [...] > > libgcrypt will surely pop up in many license analysis tools as distros > > move to a version that now contains the OCB implementation with that > > patent reference. Having good technical answers how to deal with them is > OpenSSL also included OCB unconditionally. Thus Libgcrypt should be the > smallest problem. [...] OpenSSL is in a different situation than everybody else, they got a special OCB license without the additional restrictions on top of the OpenSSL license. 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 Fri Dec 15 21:26:39 2017 From: wk at gnupg.org (Werner Koch) Date: Fri, 15 Dec 2017 21:26:39 +0100 Subject: LGPL vs. OCB license In-Reply-To: <20171215191748.GB1430@argenau.bebt.de> (Andreas Metzler's message of "Fri, 15 Dec 2017 20:17:48 +0100") References: <0917c6bd-acee-41ce-8a9a-e80a098bca4c@siemens.com> <87wp1o54ul.fsf@wheatstone.g10code.de> <87h8sr6dhg.fsf@wheatstone.g10code.de> <20171215191748.GB1430@argenau.bebt.de> Message-ID: <87y3m34u0w.fsf@wheatstone.g10code.de> On Fri, 15 Dec 2017 20:17, ametzler at bebt.de said: > OpenSSL is in a different situation than everybody else, they got a > special OCB license without the additional restrictions on top of the > OpenSSL license. According to private discussions this was on their explicit request to make it really clear. It has already been suggested to the OpenPGP WG that we could ask for an explicit license for the OpenPGP protocol. Why not also ask for a similar special license for Libgcrypt? Well, that might end up with explicit licenses for all free software libraries. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From andreas.radke at mailbox.org Fri Dec 15 21:22:28 2017 From: andreas.radke at mailbox.org (Andreas Radke) Date: Fri, 15 Dec 2017 21:22:28 +0100 Subject: new test suite failure Message-ID: <20171215212228.5f469ae4@laptop64.home> While trying to build the new 1.8.2 release the test suite fails here: t-secmem: line 176: gcry_control (GCRYCTL_INIT_SECMEM, pool_size, 0) failed: General error FAIL: t-secmem PASS: mpitests t-sexp: line 1174: gcry_control (GCRYCTL_INIT_SECMEM, 16384, 0) failed: General error FAIL: t-sexp I couldn't find some test log file. Last version 1.8.1 built well here. Any idea? -Andy Arch Linux -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 488 bytes Desc: Digitale Signatur von OpenPGP URL: From gniibe at fsij.org Mon Dec 18 07:32:06 2017 From: gniibe at fsij.org (NIIBE Yutaka) Date: Mon, 18 Dec 2017 15:32:06 +0900 Subject: new test suite failure In-Reply-To: <20171215212228.5f469ae4@laptop64.home> References: <20171215212228.5f469ae4@laptop64.home> Message-ID: <873748zgux.fsf@iwagami.gniibe.org> Andreas Radke wrote: > While trying to build the new 1.8.2 release the test suite fails here: > > t-secmem: line 176: gcry_control (GCRYCTL_INIT_SECMEM, pool_size, 0) failed: General error > FAIL: t-secmem > PASS: mpitests > t-sexp: line 1174: gcry_control (GCRYCTL_INIT_SECMEM, 16384, 0) failed: General error > FAIL: t-sexp > > > I couldn't find some test log file. Last version 1.8.1 built well here. Any idea? I put some changes for secmem. For those patches of mine, it builds successfully on Debian: 1.8.1-4: https://buildd.debian.org/status/package.php?p=libgcrypt20 All good. 1.8.2-1: https://buildd.debian.org/status/package.php?p=libgcrypt20&suite=experimental All good, so far. Not yet: kfreebsd-amd64, kfreebsd-i386, powerpcspe I wonder what's your environment. -- From jan.kiszka at siemens.com Wed Dec 20 07:19:42 2017 From: jan.kiszka at siemens.com (Jan Kiszka) Date: Wed, 20 Dec 2017 07:19:42 +0100 Subject: LGPL vs. OCB license In-Reply-To: <87y3m34u0w.fsf@wheatstone.g10code.de> References: <0917c6bd-acee-41ce-8a9a-e80a098bca4c@siemens.com> <87wp1o54ul.fsf@wheatstone.g10code.de> <87h8sr6dhg.fsf@wheatstone.g10code.de> <20171215191748.GB1430@argenau.bebt.de> <87y3m34u0w.fsf@wheatstone.g10code.de> Message-ID: <5713699f-1db2-8abb-9010-01bc4fa7d294@siemens.com> On 2017-12-15 21:26, Werner Koch wrote: > On Fri, 15 Dec 2017 20:17, ametzler at bebt.de said: > >> OpenSSL is in a different situation than everybody else, they got a >> special OCB license without the additional restrictions on top of the >> OpenSSL license. > > According to private discussions this was on their explicit request to > make it really clear. It has already been suggested to the OpenPGP WG > that we could ask for an explicit license for the OpenPGP protocol. Why > not also ask for a similar special license for Libgcrypt? Well, that > might end up with explicit licenses for all free software libraries. > That would be the clearest license, of course. Are you planning to try this, or who could do this? Jan -- Siemens AG, Corporate Technology, CT RDA ITP SES-DE Corporate Competence Center Embedded Linux From ineiev at gnu.org Wed Dec 20 19:17:13 2017 From: ineiev at gnu.org (Ineiev) Date: Wed, 20 Dec 2017 13:17:13 -0500 Subject: LGPL vs. OCB license In-Reply-To: <87y3m34u0w.fsf@wheatstone.g10code.de> References: <0917c6bd-acee-41ce-8a9a-e80a098bca4c@siemens.com> <87wp1o54ul.fsf@wheatstone.g10code.de> <87h8sr6dhg.fsf@wheatstone.g10code.de> <20171215191748.GB1430@argenau.bebt.de> <87y3m34u0w.fsf@wheatstone.g10code.de> Message-ID: <20171220181713.GT14285@gnu.org> On Fri, Dec 15, 2017 at 09:26:39PM +0100, Werner Koch wrote: > On Fri, 15 Dec 2017 20:17, ametzler at bebt.de said: > > > OpenSSL is in a different situation than everybody else, they got a > > special OCB license without the additional restrictions on top of the > > OpenSSL license. > > According to private discussions this was on their explicit request to > make it really clear. It has already been suggested to the OpenPGP WG > that we could ask for an explicit license for the OpenPGP protocol. Why > not also ask for a similar special license for Libgcrypt? Well, that > might end up with explicit licenses for all free software libraries. I wonder what FSF's lawyers said about this matter... -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: Digital signature URL: