Date: Thu, 10 Apr 2008 02:11:55 -0400 From: Joe Marcus Clarke <marcus@marcuscom.com> To: cokane@freebsd.org Cc: gnome@freebsd.org Subject: Re: Seahorse issues Message-ID: <1207807915.61729.40.camel@shumai.marcuscom.com> In-Reply-To: <47FD34E8.2000005@FreeBSD.org> References: <47FD09AC.2020907@FreeBSD.org> <1207776230.61729.28.camel@shumai.marcuscom.com> <47FD34E8.2000005@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--=-4iCDTsi2nQAeluyiy5KG Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2008-04-09 at 17:28 -0400, Coleman Kane wrote: > Joe Marcus Clarke wrote: > > On Wed, 2008-04-09 at 14:23 -0400, Coleman Kane wrote: > > =20 > >> I recently updated to GNOME 2.22, and ever since I have not been able = to=20 > >> have seahorse work, breaking application integration with GPG, etc.... > >> > >> I filed a bug with the GNOME project, but perhaps someone else is=20 > >> running into this: > >> http://bugzilla.gnome.org/show_bug.cgi?id=3D527193 > >> =20 > > > > They will most likely come back and tell you to get a backtrace with > > symbols. It looks like a problem with either missing headers or a > > missing cast, though. If I'm right, this would only affect 64-bit > > platforms. > > > > Joe > > =20 > Thanks, I pre-empted that by rigging the seahorse build so that it built=20 > with -g -O0, and copied the non-stripped seahorse-agent binary into=20 > /usr/local/bin for my submitted backtrace. Amazingly enough, it turns=20 > out that even if you specify --enable-debug on the configure line, the=20 > installation step still decided to strip the binaries after=20 > installation. nice. >=20 > Anyhow, there is hopefully enough info in there for them to figure out=20 > what's up (my guess is that the missing cast is the likely culprit, as=20 > it caused similar misbehavior in evolution some time back). The problem is the fact that FreeBSD's mlock() requires setuid privileges, and thus seahorse cannot allocate secure memory. The standard malloc functions are overridden in libseahorse/seahorse-secure-memory.c. Because they fail to allocate secure memory, everything fails, and the agent aborts. If you comment out the guts of seahorse_secure_memory_init(), things should work. That said, it should not be fatal that the gnome-keyring secure memory functions don't work. That should just result in a warning, and a fallback to insecure memory. Perhaps the bug needs to be moved to gnome-keyring. Joe --=20 PGP Key : http://www.marcuscom.com/pgp.asc --=-4iCDTsi2nQAeluyiy5KG Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (FreeBSD) iEYEABECAAYFAkf9r6sACgkQb2iPiv4Uz4eDdACcDl1lleUJC8tRaorBDoQFfJlX F7IAnjaWOgecI9gmxRuf7tyfnZxv0pcg =WulB -----END PGP SIGNATURE----- --=-4iCDTsi2nQAeluyiy5KG--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1207807915.61729.40.camel>