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
On Sat, 26 Apr 2014 11:39:02 +0200 Andreas Henriksson wrote:
> Control: tag -1 - patch
>
> While I appreciate the feedback on how mlock works on kfreebsd
> and including a patch along with discussions of technical details
> is nice, I'm going to remove the patch tag.
> Maye I misunderstood somethi
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
6 matches
Mail list logo
