severity 628383 important
thanks
We now know that this test failure only happens on kfreebsd-9.
kfreebsd-10, which will be released with Jessie, allows unprivileged
users to mlock() memory, and libgnome-keyring will work fine there.
Christoph was able to binNMU the package from a kfreebsd-10 mach
Maye I misunderstood something but i think there's a reason the
memory is mlocked; to avoid leaking sensitive information into swap.
As far as I know, there is no gurantee, that mlocked memory
will not go into swap when whole PC is suspended, even under Linux.
man mlock (from Linux Programmer's
Hi,
On 18/05/14 20:38, Jeff Epler wrote:
> Apparently freebsd kernels 9.2 and later have
> security.bsd.unprivileged_mlock, which appears to default to permitted.
Ah, that is good to know.
The buildds are wheezy systems with a 9.0 kernel. I'm not sure of the
timetable for them to be upgraded
Apparently freebsd kernels 9.2 and later have
security.bsd.unprivileged_mlock, which appears to default to permitted.
http://www.freebsd.org/cgi/man.cgi?query=mlock&sektion=2&manpath=FreeBSD+9.2-RELEASE
http://marc.info/?l=freebsd-arch&m=134617193210756
Is this test failure happening with kernel
retitle 628383 [kfreebsd-*] test failure: test-secmem
found 628383 3.4.1-1
thanks
Hi,
I've just reviewed/tested that this issue was still present in the
latest build, but libgnome-keyring no longer FTBFS since it ignores the
test failure (adjusting bug title accordingly).
Regards,
--
Steven Cha
5 matches
Mail list logo
