Bug#1063170: nettle: NMU diff for 64-bit time_t transition
Graham Inggs writes: > we have identified nettle as a source package shipping runtime > libraries whose ABI either is affected by the change in size of > time_t, or could not be analyzed via abi-compliance-checker (and > therefore to be on the safe side we assume is affected). It looks like these are the uses of time_t in nettle: $ git grep time_t pgp-encode.c: time_t timestamp) pgp.h: time_t timestamp); rsa2openpgp.c: time_t now = time(NULL); This is a bit unfortunate. This code was added in 2003 in an effort to provide support for public keys and signatures in openpgp format, but that code is neither in a good shape or at all documented. But the code *is* exposed by the shared library ABI, so I'm afraid the ABI technically depends on the size of time_t. However, this code is in the *libhogweed* so-file, so transitioning *libnettle* is probably not needed. In debian code search, I find exactly one match outside of nettle for the nettle/pgp.h header file declaring the affected functions: https://sources.debian.org/src/rust-nettle-sys/2.2.0-2/bindgen-wrapper.h/?hl=40#L40. I don't find any calls to the problematic functions themselves, which are rsa_keypair_to_openpgp and pgp_put_public_rsa_key. (The code in question wants to write the timestamp into an openpgp public key packet, and uses a 32-bit wire format for that. See https://sources.debian.org/src/nettle/3.9.1-2/pgp-encode.c/#L235. I have not been following openpgp developments, but I would hope there's some protocol update to support a larger time stamp?) Regards, /Niels -- Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677. Internet email is subject to wholesale government surveillance.
Bug#884403: Patch for nettle-3.4
The below seems to be the minimal patch to enable compilation with
nettle-3.4 (and breaking support for earlier nettle versions in the
process). Something more elaborate based on NETTLE_VERSION_MAJOR,
NETTLE_VERSION_MINOR is possible, but I'm not sure it's needed.
Regards,
/Niels
diff --git a/src/dummy.c b/src/dummy.c
index c33c8869..72fd5185 100644
--- a/src/dummy.c
+++ b/src/dummy.c
@@ -113,14 +113,14 @@ base64_encode_init(struct base64_encode_ctx *ctx UNUSED)
size_t
base64_encode_update(struct base64_encode_ctx *ctx UNUSED,
-uint8_t *dst UNUSED,
+char *dst UNUSED,
size_t length UNUSED,
const uint8_t *src UNUSED)
{ abort(); }
size_t
base64_encode_final(struct base64_encode_ctx *ctx UNUSED,
- uint8_t *dst UNUSED)
+ char *dst UNUSED)
{ abort(); }
void
@@ -132,7 +132,7 @@ base64_decode_update(struct base64_decode_ctx *ctx UNUSED,
size_t *dst_length UNUSED,
uint8_t *dst UNUSED,
size_t src_length UNUSED,
-const uint8_t *src UNUSED)
+const char *src UNUSED)
{ abort(); }
int
--
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.
Bug#810112: libhogweed.so.4: undefined symbol: __gmpn_cnd_add_n
Nathael Pajani <nathael.paj...@ed3l.fr> writes: > I'm trying to download an archive from a build script on a remote server with > https, but encounter the following error : > > curl: symbol lookup error: /usr/lib/x86_64-linux-gnu/libhogweed.so.4: > undefined > symbol: __gmpn_cnd_add_n > wget: symbol lookup error: /usr/lib/x86_64-linux-gnu/libhogweed.so.4: > undefined > symbol: __gmpn_cnd_add_n This usually means that, for some unknown reason, you are linking to a too old version of gmp at runtime. The gmp-6.1 pcakage you have installed ought to be new enough, but check with ldd on the failing programs which library .so files really are picked up. Regards, /Niels (nettle/hogweed "upstream") > Tried both curl and wget, with the same error. > Of course manual download using a web browser succeeds. > > $ wget --no-check-certificate > https://gforge.inria.fr/frs/download.php/file/33524/CGAL-4.4.tar.bz2 > $ curl --insecure -O > https://gforge.inria.fr/frs/download.php/file/33524/CGAL-4.4.tar.bz2 > > Both fail with the symbol lookup error. > > > Thanks for your work on the Debian project and Free software :) > +++ > > > > -- System Information: > Debian Release: stretch/sid > APT prefers unstable > APT policy: (500, 'unstable') > Architecture: amd64 (x86_64) > > Kernel: Linux 4.4.0-rc4-nath-64+ (SMP w/4 CPU cores) > Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > Init: sysvinit (via /sbin/init) > > Versions of packages libhogweed4 depends on: > ii libc6 2.21-6 > ii libgmp102:6.1.0+dfsg-2 > ii libnettle6 3.1.1-4 > > libhogweed4 recommends no packages. > > libhogweed4 suggests no packages. > > -- no debconf information -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.
Bug#784009: Segmentation fault
Andreas Metzler ametz...@bebt.de writes: No, that does not work. wget would be looking for unversioned references to nettle-symbols, and given the choice ot two differently versioned ones it will not prefer either over the other. I see. So for a really smooth transition from jessie and up, including partial upgrades, one would need an update with nettle-2.7.x with versioned symbols, and all packages linking explicitly with nettle rebuilt against that version (about 30 packages, if apt-cache rdepends libnettle4 is a good way to list them). And try to ensure all of these packages are upgraded *before* the packages with nettle-3.1 and current gnutls are installed. Maybe too complicated to be worth the effort? Are there any shortcuts, which improve the situation over the status quo? For clarity, I'm the upstream here. I'm a also debian user, but not very familiar with debian packaging. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#784009: Segmentation fault
Magnus Holmgren holmg...@debian.org writes: Not sure how this situation is normally handled, but when Nettle 3.1 is uploaded to sid, new versions of GnuTLS and other packages linking against it should follow soon after [1], so the problem is temporary. As I understand it, the problem is applications like wget which link explicitly with both gnutls and nettle (and this is the usecase I had in mind when I at last decided to do symbol versioning in nettle). To be able to install new nettle and gnutls without crashing wget, either wget has to be relinked first, or we need some magic packaging dance. [1] That is, Nettle 3.1 will be uploaded to sid when the current upload to experimental has been cleared by the FTP masters and GnuTLS is ready to follow, The question is, when will an updated version of wget (and other applications) follow? I don't fully understand debian transitions either, but to be able to get a smooth upgrade to nettle-3.x in the next release (and for users that mix wget from jessie and nettle from testing), I suspect one has to do something like: 1. Package a new libnettle4 package which is a nettle-2.7.x with versioned symbols. For now, let's call it nettle-2.7.2. 2. Get this package into jessie as an update. 3. Package nettle-3.x (x = 1) as libnettle5, and declare some kind of package conflict with libnettle4 versions earlier than the one prepared in (1). Now, it's still a bit unclear to me how versioned symbols really work. Is it still necessary to relink the wget executable? Or will the combination of * Current wget package, linking to gnutls and libnettle4.so, * a new gnutls package, linking to a libnettle5-package containing nettle-3.1 * libnettle4.so from the nettle-2.7.2 release under consideration, i.e., with versioned symbols, work and resolve all symbols correctly? I.e., all direct references to nettle symbols in wget should get definitions in libnettle4.so, and all references via gnutls should get definitions in libnettle5.so. BTW, Magnus, are you subscribed to the nettle-bugs list? Some of this discussion belongs there. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#784009: Segmentation fault
Andreas Metzler ametz...@bebt.de writes: Looks like we need a two-step transition: nettle 2.7 - nettle 2.7+versioned_symbols , nettle 2.7+versioned_symbols - nettle 3.1. I'm considering making a nettle-2.7.2 release with version symbols. The version string would simply be derived from the version in the soname, NETTLE_4 and HOGWEED_2. Would that help? Also see http://lists.lysator.liu.se/pipermail/nettle-bugs/2015/003383.html (not sure crossposting between the nettle list and debbugs is a good idea). Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#763494: squeak-vm: Please change build dependency to libjpeg-dev (libjpeg-turbo transition)
Ondřej Surý ond...@debian.org writes: I have no idea if it fixes the #744289, but if the bundled library is the original libjpeg6b then it might. I've now tested (after upgrading squeak-vm to version 1:4.10.2.2614-1.1+b1). jpeg files still don't work in scratch, and I get no error messages. To reproduce (with an English locale): Start scratch. For me, this displays a message Executing: /usr/lib/squeak/4.10.2-2614/squeakvm -encoding UTF-8 -vm-display-x11 -plugins /usr/lib/scratch/plugins/:/usr/lib/squeak/4.10.2-2614/ /usr/share/scratch/Scratch.image and then the scratch window appears. Click Stage on the right. In the middle, we get three tabs, including a Backgrounds tab. Select the Backgrounds tab. Click the Import button. A file selector appears. Select the Indoors folder and the file party-room (in the file system, that's /usr/share/scratch/Media/Backgrounds/Indoors/party-room.jpg), and click Ok. We get a new entry in the list of backgrounds, but the thumbnail is an empty image. Interestingly, I do get a correct thumbnail for the party-room image in the file selector, but I guess the thumbnails are stored separately in scratchthumbs.db. For contrast, click the Import button again, and select Indoors/bedroom1 (corresponding to the file bedroom1.gif). We get a new entry in the list, with a correct thumbnail image, and since it is selected, we also get a larger version on the right as the stage background. So something is still broken with jpg support in squeak-vm and/or scratch. And I think backgrounds are a quite important feature in scratch. Maybe someone more familiar with smalltalk and squeak can cook up a simpler jpeg test case. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#763494: squeak-vm: Please change build dependency to libjpeg-dev (libjpeg-turbo transition)
Ondřej Surý ond...@debian.org writes: I am in process of testing each package in question to compile against libjpeg-turbo and I will provide a suitable patch for each package when I will succeed. Does the move to libjpeg-turbo also address the problem described in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=744289, i.e., that the scratch package is unable to load any jpeg files, e.g., scene backgrounds? (And maybe that bug ought to be reassigned to the squeak-vm package?) Best regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#745233: libhogweed2: should have versioned depend on newer libgmp10
Magnus Holmgren holmg...@debian.org writes: Oh well, I went ahead and did it for you. However, as you can see, some symbols went missing in both 5.1 and 6.0. Are those the ones in the #MISSING: lines in your file? They are all undocumented internal functions in GMP. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#743087: nettle: FTBFS: missing symbols
David Suárez david.sephi...@gmail.com writes: Source: nettle Version: 2.7.1-1 Severity: serious Tags: jessie sid User: debian...@lists.debian.org Usertags: qa-ftbfs-20140329 qa-ftbfs Justification: FTBFS on amd64 Hi, During a rebuild of all packages in sid, your package failed to build on amd64. --- debian/libhogweed2.symbols (libhogweed2_2.7.1-1_amd64) +++ dpkg-gensymbolsi_VY4I2014-03-30 00:28:48.397249583 + @@ -26,12 +26,12 @@ _nettle_mpn_set_base256@Base 2.7 _nettle_mpz_limbs_cmp@Base 2.7 _nettle_mpz_limbs_copy@Base 2.7 - _nettle_mpz_limbs_finish@Base 2.7 - _nettle_mpz_limbs_modify@Base 2.7 - _nettle_mpz_limbs_read@Base 2.7 +#MISSING: 2.7.1-1# _nettle_mpz_limbs_finish@Base 2.7 +#MISSING: 2.7.1-1# _nettle_mpz_limbs_modify@Base 2.7 +#MISSING: 2.7.1-1# _nettle_mpz_limbs_read@Base 2.7 Are you by any chance linking with gmp-6.0.0, released a few days ago? _nettle_mpz_limbs_finish, _nettle_mpz_limbs_modify, and _nettle_mpz_limbs_read are internal functions in nettle, which aren't needed with gmp-6.0.0. Then, Nettle-2.7.1 has not been tested with gmp-6.0.0. I hope there should be no real problems. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#301968: lsh-server fails to create the hostkey
Stefan Pfetzing [EMAIL PROTECTED] writes: lsh-server fails to create the hostkey, possibly because the lsh-keygen options are changed. --nist-level now is the length in bit of the rsa key. I think it's because lsh-keygen defaults to RSA keys now; in earlier versions DSA keys were the default (and before that, DSA was the only supported type). The DSA specific long option --nist-level seemed like a good idea at the time, but I'm sorry it's poor user interface now. Anyway, if you don't want to use the default key size, I think it's best to use *both* type and length options, e.g. lsh-keygen --server -a rsa -l 2048 or lsh-keygen --server -a dsa --nist-level 8 Regards, /Niels
Bug#300874: lsh-utils_2.0.1-1_sparc: FTBFS: m4: command not found
Steve Langasek [EMAIL PROTECTED] writes: The most recent attempt to build lsh-utils on sparc has failed with the following error: m4 /build/buildd/lsh-utils-2.0.1/src/nettle/asm.m4 machine.m4 config.m4 \ aes.asm aes.s /bin/sh: m4: command not found make[6]: *** [aes.o] Error 127 [...] Other architectures seem to build the package just fine, because this m4 command is not executed there -- it seems to be some sparc-specific assembly? Nettle contains assembler for sparc and for x86 (or really ia32, there's no assembler for any of the 64-bit variants of x86). So m4 ought to be executed also on the common x86 architecture. Regards, /Niels
